|
Thinking Mechanically, Part 7: Resolution Mechanicsby Travis S. Casey A few columns back, I talked about the "three R's" of mechanics: Reduction, Resolution, and Representation. I've been talking about scaling in the last couple of columns -- which ties into the Reduction phase, as it deals with how we come up with the numbers that will be used in Resolution. The central question in designing the Resolution aspect is "what do we do with the numbers?" So let's look at some different things that can be done with them. Roll vs. ThresholdThe simplest, oldest method is to simply add together the numerical factors that are involved, then roll some sort of die against them, trying to roll either higher or lower. A concrete example is combat rolls in second edition AD&D: the attacking character's THAC0 value is added to the defender's armor class, and that produces a value which a d20 roll must equal or exceed for a successful strike. (A note here -- games often distinguish between what values are added to the target value, and what values are added to the die roll. In a system of this sort, both methods are mathematically equivalent except for a change of sign:
That change in sign may be psychologically significant, though -- many people find it "more natural" to have things that make a task easier expressed as positive numbers, and those that make it harder expressed as negative numbers. For a paper system, such a change in where the modifiers are placed in the equation can make a system feel easier to use.) There are also systems where one wants to "roll low", rolling under the target value; for example, most percentile-based systems, including Runequest and the systems based on its "Basic Roleplaying" mechanics (Call of Cthulhu, Stormbringer, etc.). This is basically equivalent to the above, the only mathematical changes being the substitution of "<" for ">" in the above equations and a change of sign for the modifiers. A central question for this sort of method is what the roll should be -- in particular, whether it should involve only one die or the sum of multiple dice. A single die gives a linear probability curve -- each point of a modifier therefore adds or subtracts the same amount from the probability of success, within the limits of the range of the mechanic. Multiple dice, however, give a sort of "bell curve", where results in the middle of the distribution being more likely than those results at either extreme. As a side effect, the change in the probability of success caused by a +1 or -1 modifier depends on the point of the curve one is at -- at the very extremes and in the very middle, the change is small, but on the "sides" of the bell, the change can be very large. Whether or not a bell curve is desirable is a subject of some argument among RPG designers, at times bordering on a religious issue. To avoid the inevitable flamewar, I'd like to simply say that each has its merits, and that it behooves any game designer to spend some time thinking about the goals of their system, and what sort of mechanic would better serve those goals. Dice PoolsAnother fairly common method is what's sometimes called a "dice pool". In this sort of system, multiple dice are rolled and checked independently against a target value. The number of dice to roll is variable, dependent on factors considered in the Reduction phase. The classic example here is White Wolf's Storyteller system. In it, the number of dice to roll is typically the sum of the applicable attribute and skill. Each die that equals or exceeds the target number is counted as a "success". Most tasks can be accomplished with a single success, but some tasks may require multiple successes. A good quality that dice pools can have is that there are two ways to vary the difficulty of a task -- by varying the target value, and by varying the number of successes needed. Each has somewhat different effects, though, so a game designer needs to carefully consider which way is appropriate for what sort of tasks, and give good guidelines to scenario designers about this. One common complaint about dice pools is that it is harder to figure probabilities of success with a dice pool system than with a roll vs. threshold system. This is true, but in the context of systems for a computer RPG, it really doesn't matter that much. In a paper RPG, the gamemaster often has to make up difficulty values on the fly, and may wish to have a fair idea what chance of success the characters involved would have. In a computer RPG, however, difficulty values are almost exclusively being assigned well in advance. Thus, there's more leisure to consult a table or computer program to check on chances of success. These two systems, between them, dominate the paper RPG landscape. At a rough estimate, I'd say that 95% or more of paper RPGs use systems of these two types. Why? Well, one reason is that they're fairly simple and easy to understand. That's added to by the fact that they are in such extensive use -- they're familiar to the existing fan base of paper RPGs, and therefore using one of them doesn't create an extra obstacle to players learning and using the game. For a computer game system, however, those factors are less important. Players don't have to use or understand the underlying resolution system -- scenario designers do need to, but as mentioned above, they're not under the same sort of "decide now" time pressure that paper RPG gamemasters are, so a more complex system can be used, or a tool can be used to help with calculating and/or estimating probabilities of success. The overwhelming majority of computer RPGs, nonetheless, are still based on one of these two systems -- in particular, on a "roll vs. threshold" system. I'd encourage computer RPG designers to think about what other sorts of systems are possible -- and towards that end, the next column will be devoted to "oddball" resolution systems. Most of them will be drawn from paper RPGs, since I am primarily a paper RPG guy, but I'll have a few thoughts on what sorts of things might be possible in a computer RPG as well.
|
