One of the big advantages of using a rules-light RPG system like Oe/1e D&D is simplicity of information tracking. The record sheet for an Oe character can easily fit on two sides of a 3x5 index card, though we usually use larger paper because index cards don't fit in laser printers and copiers all that well. 1e character sheets are a little more complex, since the rule set is a little larger, but still models of concision compared to the multi-sheet booklets needed to track all the various skill levels and other arcana associated with characters in later rule sets (3.5e being the most heinous example).
In an earlier post, I briefly mentioned my experience with the Ringworld game produced by Chaosium and based on their well-conceived Basic Role Playing (BRP) system. It works, it's comprehensive, and there's much to admire in Chaosium's system, but keeping track of a character's skills and various other possessions and abilities is laborious. The 4-page character sheets that come with the game are pretty, but complicated: a warning of tedium to come.
In-game accounting is a big deal.
I've just started the process of outlining my proposed mana-based magic overlay for the Oe/1e D&D rules, and now there are a bunch of additional numbers the GM and any spell-casting player will have to track during the course of play: especially basal mana and base cost to cast a spell at each level. This requires an accounting system that is simple, intuitive, and easy to use. If I simply rely on players to jot down numbers and try and keep track of them, this whole exercise isn’t going to work.
As an architect by trade, I am strongly inclined by professional training and personal disposition to prefer graphic communication as a means for condensing large amounts of information into a compact, easy-to-understand package. A list of numbers on a page isn't going to do any of us any favors here. We should defer to the wisdom of Edward Tufte. Here are some of his rules for communicating graphic information:
- Enforce Visual Comparisons - information shown should maintain a proportional scale illustrating comparative magnitude through space and time.
- Show Causality - if there are causal relationships in the information beings shown, they should be graphically represented.
- Try to Show Multivariate Data - more than two dimensions of inter-related information can be represented in a two-dimensional diagram.
- Completely Integrate Words, Numbers, and Images - Don't make the user work to learn your system (avoid codes and other obscure reference systems)
- Design Should be Content-Driven - the point of the diagram is the information, not the graphic itself.
Now, it's not practical for us to integrate
sparklines into a table-top RPG. However, there are some examples that could be adapted to our purposes without too much trouble.
The first of these comes from computer interface design: the
progress bar. A progress bar is a simple representation of a proportional relationship in percentage terms. When the bar is completely full, its value is 100%. Anything less than that gives a fast and accurate representation of the current
scale-independent comparative level being measured versus its potential maximum. You see these everywhere in computer GUIs because they are easy and quick to understand. They're ubiquitous in computer games for good reason. In the heat of combat while running a level in a first-person shooter, you can't take your eyes off the action long enough to read your hit points as a number and calculate damage in your head. A health progress bar gives a fast, accurate, proportional read of damage and hit points.
Again, it's not practical to have continuously updating progress bars for a table-top RPG like we see in video games. It's trivial to implement when a computer is doing the work, but on paper it can become tiresome.
Which leads us to my second example. Back in my early gaming days, I was an avid player of
Star Fleet Battles (originally by Task Force Games): a table-top war game involving ship-to-ship combat in space between Star Trek inspired fleets.
SFB is actually a somewhat complicated game to play, especially when compared to OD&D. Each player controls a fleet of starships with varying attributes and weapons systems, many of which have limited supplies of ammunition and the ability to carry varying payloads. Most of these ships are capable of covering vast distances in very short periods of time. You might even have "legendary officers" on board (scrupulously avoiding reference to beloved TV characters for licensing reasons), who give performance bonuses but can be killed in battle. Prior to each turn, the player has to allocate each ship's limited energy resources to ship systems (propulsion, shields, weapons, &c). Available energy resources are only rarely enough to power everything at once, so hard choices have to be made with limited resources ("All power to shields!"). Each turn is then divided into 32 "impulses" as fractional periods of time elapse during the action.
All of which sounds frighteningly complicated. It is, except that SFB uses a highly-graphical abstract accounting system to condense all of this information into a form that is easily understood and used in a free-flowing game session. Every ship in the game is controlled and tracked using a single-sided record sheet called a Ship Systems Display (SSD). Here's an example for a fan-created Federation Destroyer SSD:
Federation DXI Bullet Destroyer SSD for Star Fleet Battles
That's it. An entire starship with a crew of dozens and all of its core systems represented on one side of one letter-sized sheet of paper with lots of white space left over. In fact, the information is so simplified and condensed that there's room for several handy "to-hit" and damage tables for the player to reference without having to crack a rule-book. The SSDs that came with the original game were actually condensed to fit two on a page (cut the sheet in half or fold to use) without any loss of clarity or information.
The grid squares you see each represent one unit of system capability and damage capacity. How many energy points are available? Count the engine squares. How many hit points of damage can the shields take? Count the shield squares (which are also conveniently oriented by hex face). Handy reference numbers in the last square of each large block save the trouble of having to count lots of squares. On taking a hit, the damage is totaled up and hit locations determined on a simple chart. Then the appropriate number of boxes is crossed out to represent the damage. When repaired, the boxes are cleared.
For ease of use, we always put plastic covers on the SSDs and colored in boxes with china markers, but pencil on paper with a handy eraser works just as well if you don't mind a little mess. When all the shield boxes on a side are colored in, the shield is down and any further damage from attacks in that direction go straight to the hull and ship systems.
Thus, a very complicated game mechanic which requires detailed accounting is rendered simple and easy to understand through graphic representation. It's a model of concision, and this method for representation was used in Task Force Games' wet-navy simulation game,
Battlewagon, as well.* Here’s an entire fleet on one 5 1/2” x 8 1/2” half-sheet of paper:
Battlewagon Generic Fleet SCSs
Tracking all of this spell-casting and mana stuff is adding complexity to my rule-set. To help both players and GM track it simply and easily, I’m going to revise the basic character sheet to include some graphic tracking elements. In my next post, we take a look at the results.
* My favorite way to play Battlewagon was with 1:2400 miniature ship models (from GHQ) on the floor of my parents’ breakfast room/kitchen, finished with 2” blue hexagonal tiles. It’s a great way to spend a rainy afternoon. Incidentally, with some rule modifications for earlier technology, the Battlewagon rules are also a great way to quickly and easily simulate both small- and large-scale naval warfare in D&D campaigns.
