Reply to thread

Message: <blockquote data-quote="Edgar Ironpelt" data-source="post: 9182254" data-attributes="member: 32075">No, but it was written down in the saved file:Newsgroups: rec.games.frp.miscFrom: <a href="mailto:morrow@gandalf.rutgers.edu">morrow@gandalf.rutgers.edu</a> (John Morrow)Subject: Re: Human factors in game designDate: 1 Mar 1995 19:52:42 -0500EDIT: 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...<a href="mailto:lea@hestia.demon.co.uk">lea@hestia.demon.co.uk</a> (Lea Crowe) writes:My current motto in design is, "Speed, the other realism."  To make asystem "fast", you need to make it easy to use -- intuitive.  Beloware some of my thoughts on that subject.  They are all based on dicedsystems although some of the comments should be portable to dicelesssystems.[Shadowrun vs. Storyteller mechanics deleted]One thing to consider when installing a mechanic is whether or not theoverhead of a detail provides a critical bit of information that makesthe mechanic more useful or fun.  For instance, Hero divides damageinto stunning and killing damage which requires you to keep track oftwo sets of numbers.  But doing so produces comic-book like combateffects quite well.  A more common example is combat modifiers whichexist in most games.  They let players provide a certain level oftactical input into a combat situation, even though there is a lot of"overhead" involved.  Do the added bits of overhead in the Shadowrunsystem add anything necessary for simulating the genre?  (I'm not allthat familiar with either game beyond the basics)The first thing you need to do for any mechanic is divide it intomental talks needed to get the result.  Types of tasks include:o  identifying the appropriate mechanico  referencing the character sheeto  simply reading the dice o  mathematical operations and modifierso  table or chart look-upso  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.  Takingeach one separately...o  identifying the appropriate mechanicThe first thing the GM and/or players need to do is map a PC's orNPC's action to a game mechanic that will resolve it.  Clearly, thefewer types of mechanics a game has, the easier it is to figure outwhich one to use in any given situation.  If the final choice is touse a single mechanic, then that single mechanic must work reasonablyacross all types of actions.  But there will certainly be no questionof which mechanic to use.  Since this is often difficult (it is easierin some genres than others), a secondary or tertiary mechanic mightcome into play or a set of specialized combat mechanics different fromthe basic resolution mechanic.  I would personally say that more thanthree different types of resolution are excessive and you should tryto get by with one of you can.A side issue here is what type of die or dice each mechanic uses.  Ifeach mechanic uses a different type of die (e.g. D&D uses D20 andpercentile as well as other dice), then players must think about this(and maybe ask if they are unsure), pick out the dice, and thenremember how to read them in this instance (more on that below).o  referencing the character sheetMost mechanics will generally require a player to pluck a bit ofinformation off of their character sheet to factor into theresolution, be it an attribute, skill, or some other piece ofinformation.  That information might be a word (ala FUDGE) or anumber.  It may be one piece of information or a couple.  The morepieces of information a player must pull off of their character sheet,the longer it will take.  Whenever possible, character creation shouldencompass all the math needed to generate skill and attribute numbersup front so that players don't need to do math (see below) in order toget the information they need to start resolving the mechanic.  Theultimate result should generally be once piece of information toretrieve.Actually finding the information on the character sheet anotherconsideration.  People naturally order things in rows or columns sosome variation of that is probably good.  Shaded bars, darkenedborders, and large, easy-to-read type always help.  Things that gotogether should be together on the sheet and they are best if orderedfor retrieval, not for generation (e.g. One might put experiencepoints 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 whatthe players will reference at game time).  Ample space should also begiven to make player written details (e.g. skill names) legible.It also helps a lot of the information is simple enough that playerscan remember it.The final bit I'll mention here is the quantity of information on acharacter sheet.  It is easier to find a skill name in a list of 5skills 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 aplayer have his character beaten up for two round because he forgot hewas a master at unarmed combat.  He had lost all his weapons andmissed the unarmed skill on his sheet.).  Character sheets shouldprobably focus on the things that are unique to that character andthose things should be represented as minimally as possible.o  simply reading the dice There are several things at play here -- the number of dice, thenumber of faces on the dice (and how the numbers on the face arerepresented), and how they interact with one another to produce a roll(e.g. a straight read, percentile, add, sames cancel out, etc.).  Somegeneral 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 thenext step... <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":-)" title="Smile    :-)"  data-smilie="1"data-shortname=":-)" />o mathematical operations and modifiers Many systems "modify" die rolls in some way.  This can be a significantstep.  First, you need to identify the appropriate modifier which putsus back up at the "identifying the mechanic" step, here modified to be "identifying the modifier".  If modifiers are fixed, this requiresa rule book look-up and/or a reference sheet look-up.  If the modifiers aremore flexible or subjective, the GM has to pause to think about it (generally faster than a look up).  The time spent on these add upso the more you have, the longer it takes.With respect to math, addition is the fastest.  Subtraction and smallmultiplications are the next best.  Division is, by far, the worst.Do some assembly language programming if you don't know why <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":-)" title="Smile    :-)"  data-smilie="1"data-shortname=":-)" />.  Avoiddivision at all costs unless it something done outside of game play(e.g. at character generation time).  Multiplication are subtractioncan be OK if done once.  In generally, you should try to stick withaddition only if you can.The other major mathematical consideration is the size of the numbersyou are dealing with.  Most people can quickly add numbers below tenand fairly easily add numbers up to 20 or 30.  Double digits, ofcourse, take more time.  Subtraction and multiplication become more ofa problem in double digits and should be avoided.  Division, as statedabove, should be avoided at all costs except, perhaps, division by 2,3, 4, or 5.  Any higher math (powers beyond squared or cubed, algebraplug-ins, differentials, etc.) shouldn't even be considered.  Inshort, the smaller the numbers are and the less you do with them, thefaster it goes.  If players need a calculator to resolve things, I'dsay 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 verysimply mechanic (a look-up).  They also let you do thingsmathematically that you can't do easily on the fly (e.g. charts basedon exponential curves).  The problem is that they are quite slow.  Usethem only if you absolutely have to.  The problem with tables is that they require you to look in yet another place for yet anotherpiece 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 chartwhen you need one (this is sometimes a problem in my group).  Betterto avoid them if you can.  If you can't, put it on the characterand 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 damagerolls, criticals, fumbles, hit locations, etc.  Any time you need toroll 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 tofigure out how to roll most of this into a single roll or chartlook-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 apencil and write it down.  This step can take a significant amountof time if you keep track of a lot of things.  They key here is tokeep record-keeping to a minimum.For all of the above, the idea is to use the simplest and fastestsystem you can while still getting the detail you need to simulatea genre.  It is often in adding the details that a system fallsapart.  Why add details?  Because players want do differentiatethings. I've come to the cynical conclusion that most details are thinlyveiled attempts at giving the players cookies--er--positive modifiersfor clever thinking.  Note the amount of time spent on positive modifiers in most systems and by most players.  Then note theamount of space given to negative things like fatigue and encumbrance and factor in the percentage of players who actuallypay attention to such things.  I can go into this more if you really want to hear me ramble... <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":-)" title="Smile    :-)"  data-smilie="1"data-shortname=":-)" />Gee, can you start a useful discussion like this on the game designmailing list... <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":-)" title="Smile    :-)"  data-smilie="1"data-shortname=":-)" />John Morrow--- end quoted repost ---</blockquote>

Verification