Building Stories, Telling Games

Building Stories, Telling Games #52:

Thinking Mechanically, Part 10: Systems

by Travis S. Casey
January 31, 2003

Over the last several columns, we've looked at some issues of rating characters, and of using those ratings in action resolution. But a game is much more than just resolving individual actions — some things are larger than a single action, and that's where systems come in.

The most typical example of a system, in both paper and computer RPGs, is a combat system. There are some games in which an entire combat is resolved in one step, but not many. It's more common for combat to involve multiple actions sequenced over time, from at least two characters and quite often more.

So let's look at combat systems, and how they use action resolution to form a larger whole. We'll start off by considering classical D&D-style combat — both because it's a game which pretty much anyone who's had contact with paper RPGs is familiar with, and because many — I'd dare say even most — computer RPG combat systems are based on it.

Action resolution in D&D combat resolves around the "to-hit" roll, which determines whether or not one character manages to deal out damage to another. The amount of damage is decided by a separate damage roll. Factors involved in determining whether or not one "hits" include the character's skill (determined mainly by class and level), the opponent's armor and dodging ability, and sometimes situational modifiers.

(A quick note — I'm using scare-quotes on "to-hit" and "hits" because D&D's combat system is quite abstracted, especially in some of the older versions. With a combat round a minute long, a single "to-hit" roll represents multiple attack attempts, and a "hit" may actually be multiple blows that landed. And, for that matter, a "miss" may be a blow that landed, but did not penetrate the opponent's armor.)

In terms of my "three R's", the "to-hit" roll is the Resolution phase, and the damage roll could be either part of Resolution (determining how well a successful attempt did) or part of Representation (determining the effects of success). The damage points generated then come off of the character's hit points — and here's where things start to get woven into a system.

In game design terms, hit points are what I like to call a "counter" (the term isn't original with me, but I'm afraid I don't know who to credit it to) — a value which changes in the normal course of a game and is used to track the status of some aspect or resource of a character. Hit points are a common example, but others from various games would include magic points and luck points. Harkening back to my piece on unusual mechanics a couple of columns back, there are counters associated with skill levels in The Dying Earth RPG — one has to keep a count of the number of rerolls one has remaining.

To lapse into computer science lingo, a counter adds memory to the system, so we can track the state of something over multiple iterated resolution steps. In the case of combat, the iterated steps are the opponents making attacks on each other, and whoever runs out of hit points first loses.

It should be noted that while D&D doesn't use hit points as an active value in resolution (you never factor hit points into a roll), there's no reason why counters can't be used in a roll. An example would be the recent Mutants & Masterminds system, in which damage is treated using a "damage saving throw" where failure can have results varying from being momentarily stunned up to death. Some results generate lasting damage (a counter!) which is then added to the difficulty of later damage saving throws.

Counters that Don't Count

It should also be noted that counters don't necessarily have to be linear; the simplest examples are, but conceptually, anything which tracks "state" can be considered a counter. An example of a more complex system is the wound system used in Pacesetter's RPGs — Time Master, Star Ace, and the first edition of Chill.

In this system, each wound a character takes is given a level of seriousness: Scratch, Light, Serious, Critical, or Mortal. For each of these levels except Mortal, a character has two "wound boxes". When a wound is taken, a wound box on the appropriate level is filled in. If there are no more wound boxes empty on that level (i.e., you've already taken two wounds on that level), then the wound "bumps up" and is filled in on the lowest level where there's an available box.

The highest level wound that a character has determines what penalties he/she gets for actions — if you've already taken a serious wound under this system, taking a scratch generally isn't going to impair you any more than you're already impaired.

This differs from a standard hit point system in that things don't add up linearly. One could try to convert it to a hit point system, saying that a Scratch is one hit point of damage, a Light Wound three (since three scratches will make one Light Wound), a Serious Wound five hit points, and so on — but the system wouldn't work the same way. Someone who takes two serious wounds is still only seriously wounded... but a single scratch can take that second serious wound box if everything lower is filled in.

And Another Way...

Lest I leave the impression that counters are the only way to track state, one can also do it in other ways — e.g., by adding "traits" or "tags" to things. An example of this is Universalis, in which which damage can be represented either by reducing the level of existing traits on something in the game, or by adding new traits to it. An example of the latter would be adding a "has a broken leg" trait to a character.

This sort of method can be very flexible, and can be combined with a more standard counter system. One example would be standard "critical hit" systems, which allow characters to have broken bones, sprains, strained muscles, bleeding wounds, and other such things. One could also look at a modified counter system such as the one described above as combining counters with traits.

More To Come

Next time, I'll be continuing the look at building resolution up into systems by stepping — that is, by having multiple steps that do different things in a system, instead of just iterating resolution through a counter. See you in fourteen!