Great read. Do you remember what group it came from?
No, but it was written down in the saved file:
Newsgroups: rec.games.frp.misc
From:
morrow@gandalf.rutgers.edu (John Morrow)
Subject: Re: Human factors in game design
Date: 1 Mar 1995 19:52:42 -0500
EDIT: I'm going to go ahead and repost the entire thing here:
--- begin quoted repost ---
I mailed this to Lea Crowe but maybe I should post it for comment...
lea@hestia.demon.co.uk (Lea Crowe) writes:
I'm trying to gather information for a possible article about human factors
in roleplaying game design, and I thought I'd try raising the issue here.
The sort of thing I mean by "human factors" is what in computing is
called "usability". It means making information easy to locate, and
making mechanisms convenient and intuitive to use.
My current motto in design is, "Speed, the other realism." To make a
system "fast", you need to make it easy to use -- intuitive. Below
are some of my thoughts on that subject. They are all based on diced
systems although some of the comments should be portable to diceless
systems.
[Shadowrun vs. Storyteller mechanics deleted]
One thing to consider when installing a mechanic is whether or not the
overhead of a detail provides a critical bit of information that makes
the mechanic more useful or fun. For instance, Hero divides damage
into stunning and killing damage which requires you to keep track of
two sets of numbers. But doing so produces comic-book like combat
effects quite well. A more common example is combat modifiers which
exist in most games. They let players provide a certain level of
tactical input into a combat situation, even though there is a lot of
"overhead" involved. Do the added bits of overhead in the Shadowrun
system add anything necessary for simulating the genre? (I'm not all
that familiar with either game beyond the basics)
Now, other people may have different experiences of this, or may have
come across different bugbears. I'm looking for examples of design
so elegant it is utterly non-intrusive, or more importantly design which
looks elegant from a theoretical point of view but is ruined because
it fails to take into account that we only have two hands, that most
people can't process more than seven bits of information at once, that
pips are easier to read than numbers, etc.: the purely human factors
that get in the way of the theory.
Obviously different people find different things usable or convenient,
but that's why I'm asking. I'm trying to find out if there are any
significant common factors.
The first thing you need to do for any mechanic is divide it into
mental talks needed to get the result. Types of tasks include:
o identifying the appropriate mechanic
o referencing the character sheet
o simply reading the dice
o mathematical operations and modifiers
o table or chart look-ups
o additional mechanics requiring further resolution (e.g. damage rolls)
o record-keeping (e.g. points, damage, etc.)
Any of these, in excess or handled badly, can bog a game down. Taking
each one separately...
o identifying the appropriate mechanic
The first thing the GM and/or players need to do is map a PC's or
NPC's action to a game mechanic that will resolve it. Clearly, the
fewer types of mechanics a game has, the easier it is to figure out
which one to use in any given situation. If the final choice is to
use a single mechanic, then that single mechanic must work reasonably
across all types of actions. But there will certainly be no question
of which mechanic to use. Since this is often difficult (it is easier
in some genres than others), a secondary or tertiary mechanic might
come into play or a set of specialized combat mechanics different from
the basic resolution mechanic. I would personally say that more than
three different types of resolution are excessive and you should try
to get by with one of you can.
A side issue here is what type of die or dice each mechanic uses. If
each mechanic uses a different type of die (e.g. D&D uses D20 and
percentile as well as other dice), then players must think about this
(and maybe ask if they are unsure), pick out the dice, and then
remember how to read them in this instance (more on that below).
o referencing the character sheet
Most mechanics will generally require a player to pluck a bit of
information off of their character sheet to factor into the
resolution, be it an attribute, skill, or some other piece of
information. That information might be a word (ala FUDGE) or a
number. It may be one piece of information or a couple. The more
pieces of information a player must pull off of their character sheet,
the longer it will take. Whenever possible, character creation should
encompass all the math needed to generate skill and attribute numbers
up front so that players don't need to do math (see below) in order to
get the information they need to start resolving the mechanic. The
ultimate result should generally be once piece of information to
retrieve.
Actually finding the information on the character sheet another
consideration. People naturally order things in rows or columns so
some variation of that is probably good. Shaded bars, darkened
borders, and large, easy-to-read type always help. Things that go
together should be together on the sheet and they are best if ordered
for retrieval, not for generation (e.g. One might put experience
points into a skill to achieve a level. It is best to put the level,
not the experience points, next to the skill name since that is what
the players will reference at game time). Ample space should also be
given to make player written details (e.g. skill names) legible.
It also helps a lot of the information is simple enough that players
can remember it.
The final bit I'll mention here is the quantity of information on a
character sheet. It is easier to find a skill name in a list of 5
skills than it is in a list of 50. After about a dozen skill names,
it actually becomes possible to overlook skills (e.g. I once saw a
player have his character beaten up for two round because he forgot he
was a master at unarmed combat. He had lost all his weapons and
missed the unarmed skill on his sheet.). Character sheets should
probably focus on the things that are unique to that character and
those things should be represented as minimally as possible.
o simply reading the dice
There are several things at play here -- the number of dice, the
number of faces on the dice (and how the numbers on the face are
represented), and how they interact with one another to produce a roll
(e.g. a straight read, percentile, add, sames cancel out, etc.). Some
general rules in my experience:
- It is easier to read one die than many because you don't have to
visually track them all down to find all the numbers. More than
two or three dice can often cause significant delays as a player
must visually track with them all.
- It is easier to read larger number than smaller ones. This is
one side effect of large numbers of faces -- the numbers are
generally visually smaller the more faces you have.
- I'm not sure if it is easier to read pips than numbers. I
personally feel they are about equal.
- Remember that some roll types require a conversion (e.g. "0 = 10" on
some D10 rolls) which is a minor step and not always intuitive.
- It is generally fastest to simply read a single number off of a
single die.
- Percentile rolls are generally very quick so long as the "10s die"
is clearly marked. There is some potential for "cheating" here
(I've seen it, personally). The D1000 is possible but slower.
- Adding two dice together is generally pretty quick, provided the
numbers involved don't exceed 20 or 30 and don't generally go negative
(e.g. 2D6 or even 2D10 are pretty easy to do for most people while
2D20 or 2D30 would slow most people down -- see my math comments
below).
- Adding three dice together is OK so long as they are 3D6 or similar
small numbers. Most people are conditioned to read 3D6 from their
D&D days or GURPS so it generally goes pretty quickly.
- Adding more than 3 small dice together should be avoided.
- Other "strange" mechanics vary in speed but often have a steep
learning curve. People are used to adding dice and reading
percentiles. They are generally not used to, say, cancelling
out doubles. Testing is the best way to be sure. Blind test
if possible (as Steffan O'Sullivan does with FUDGE).
All this gets you to a basic die result number. Now we move on to the
next step...
o mathematical operations and modifiers
Many systems "modify" die rolls in some way. This can be a significant
step. First, you need to identify the appropriate modifier which puts
us back up at the "identifying the mechanic" step, here modified to
be "identifying the modifier". If modifiers are fixed, this requires
a rule book look-up and/or a reference sheet look-up. If the modifiers are
more flexible or subjective, the GM has to pause to think about it
(generally faster than a look up). The time spent on these add up
so the more you have, the longer it takes.
With respect to math, addition is the fastest. Subtraction and small
multiplications are the next best. Division is, by far, the worst.
Do some assembly language programming if you don't know why
. Avoid
division at all costs unless it something done outside of game play
(e.g. at character generation time). Multiplication are subtraction
can be OK if done
once. In generally, you should try to stick with
addition only if you can.
The other major mathematical consideration is the size of the numbers
you are dealing with. Most people can quickly add numbers below ten
and fairly easily add numbers up to 20 or 30. Double digits, of
course, take more time. Subtraction and multiplication become more of
a problem in double digits and should be avoided. Division, as stated
above, should be avoided at all costs except, perhaps, division by 2,
3, 4, or 5. Any higher math (powers beyond squared or cubed, algebra
plug-ins, differentials, etc.) shouldn't even be considered. In
short, the smaller the numbers are and the less you do with them, the
faster it goes. If players need a calculator to resolve things, I'd
say that you've failed to produce a reasonable play-time mechanic.
o table or chart look-ups
Tables and charts allow you to roll a great deal of detail into a very
simply mechanic (a look-up). They also let you do things
mathematically that you can't do easily on the fly (e.g. charts based
on exponential curves). The problem is that they are quite slow. Use
them only if you absolutely have to. The problem with tables is
that they require you to look in yet another place for yet another
piece to the puzzle. If the chart isn't on the character sheets,
then you have the added problem of making sure you can find a chart
when you need one (this is sometimes a problem in my group). Better
to avoid them if you can. If you can't, put it on the character
and don't have more than one or two of them.
o additional mechanics requiring further resolution (e.g. damage rolls)
Certain mechanics require additional die rolls. They include damage
rolls, criticals, fumbles, hit locations, etc. Any time you need to
roll again, you go back up a few more steps and start over again
(e.g. find the needed info, fiddle with the dice, etc.). It is
best to do this only when absolutely necessary. Better yet is to
figure out how to roll most of this into a single roll or chart
look-up.
o record-keeping (e.g. points, damage, etc.)
Keeping track of numbers on a character sheet takes time. You
need to figure out the modification and then actually pick up a
pencil and write it down. This step can take a significant amount
of time if you keep track of a lot of things. They key here is to
keep record-keeping to a minimum.
For all of the above, the idea is to use the simplest and fastest
system you can while still getting the detail you need to simulate
a genre. It is often in adding the details that a system falls
apart. Why add details? Because players want do differentiate
things.
I've come to the cynical conclusion that most details are thinly
veiled attempts at giving the players cookies--er--positive modifiers
for clever thinking. Note the amount of time spent on positive
modifiers in most systems and by most players. Then note the
amount of space given to negative things like fatigue and
encumbrance and factor in the percentage of players who actually
pay attention to such things. I can go into this more if you
really want to hear me ramble...
By the way, I'm NOT looking for instances of plain bad design (Murphy's
rules and so on). I don't care whether the mechanism produces sensible
or stupid results -- I'm only interested in how it feels to use it.
Gee, can you start a useful discussion like this on the game design
mailing list...
John Morrow
--- end quoted repost ---
