Go to Part 1

As we begin to add these kinds of complexity to a game structure, it becomes crucial that we develop efficient procedures for managing that game structure.

Let me explain that by way of example. Over the past year, I’ve been using my OD&D open table campaign as a testbed for developing an enhanced system for hexcrawling. As part of that development work, I trawled my way through multiple editions, supplements, adventures, and games looking for interesting material and then worked to recombine all of that disparate material into a handful of unified mechanics.

When I was done, I had a handful of “core systems” into which I had boiled down a lot of ancillary details. The quick highlights include:

• Encounter Tables: Which unified the chance of encountering the keyed encounter for a hex, random encounters, monster lairs, and monster tracks into a single encounter check mechanic.
• Spot Distances: Bringing together all the information on when PCs spot encounters, creatures, and/or terrain features.
• Timekeeping System: Breaking the day down into six watches (each four hours long), including a system for randomly determining time within a watch. (Why? Because it provides a cleaner structure for “mid-day course corrections”, which it turns out people want to do a lot during a hexcrawl. It also provides a convenient structure for making multiple encounter checks per day, which I found useful for a number of reasons.)
• Speed and Distance: Mostly based on the 3^rd Edition system for determining how far a group travels based on their base speed and the terrain they’re traveling through.
• Navigating the Wilderness: A system for determining whether PCs become lost and, if so, how they get lost. (And also how they can get back on track.)

When it came time to put this into actual playtesting, I had gone over these systems multiple times with a fine-toothed comb. And most of it was based on “existing tech”. I was pretty confident that the system was basically rock solid.

But when it came time for the actual playtesting, this is roughly what it looked like: “Okay, check for an encounter. There is an encounter, so let’s determine what the encounter is. A group of 1d12 goblins. Roll the number of goblins, mark that down. Okay, where does the encounter take place? First, determine time of day. Okay, where would they be at that time? Ask them which direction they’re going, then calculate their speed, figure out where they’ll be. Now, determine if they got lost. They did, so go back and determine where they actually ended up… Hmm. So that means they’re in this hex over here. But the terrain type has shifted… Oh, and the encounter table changed. So that means they didn’t encounter goblins, they would have encountered… Wait, what did I roll? Umm… Must have been an 83 since it was goblins, so on the new encounter table that would be vampire wombats. Roll those up. Now, since the terrain type changed I need to re-determine how far they actually got…”

And so forth. It was a train wreck. Lots of painfully long pauses while I fidgeted with my notes.

(This, by the way, is why you do playtesting.)

RESOLUTION SEQUENCES

Playtesting did result in my tweaking a few of the rules. (For example, I was running into a lot of headaches with groups who wanted to change direction in the middle of a hex. So I introduced a generic system for tracking progress through a hex and an abstract mechanic for groups that wanted to just cross and re-cross a given patch of terrain looking for stuff.)

But what I eventually figured out was that my biggest problem was the lack of a clear resolution sequence. I had three or four little sub-systems that were interdependent on each other, and, as a result, I would frequently end up backtracking and needing to redo calculations that I had already performed in light of new information that had been thrown up.

It took a couple more sessions of playtesting after that to really nail it down, but I eventually came up with a clean resolution sequence:

1. Determine direction and mode of travel.
2. Are They Lost?
3. Encounter Check
4. Determine Actual Distance Traveled
5. Generate Encounter

And with the addition of a brief resolution sequence used when a group leaves a hex, this basically solved the problem and made the Thracian Hexcrawl campaign possible.

In the dozens of sessions since then, I’ve learned a few additional tricks to make play more efficient (like putting landmarks visible from a distance on the hexmap and pre-rolling encounter checks so that I know which watches encounters are going to take place in and can skip straight to generating the encounter), but it all rests on the firm foundation of a clean resolution sequence.

(My next experiment is a keying system for trails: Players in hexcrawls will often follow roads, rivers, or other trails. I think there’s a way to create separate “trail maps” which will massively simplify and streamline travel along known routes. I think this should also make it possible to add a trailblazing system that will allow players to create their own trails through the wilderness. But I digress.)

REFERENCES, WORKSHEETS, AND NOTE-TAKING

My point with all this, of course, is that a game structure is not just a mass of mechanics: It is also the way in which you use those mechanics. If we return to the similar structures of board games and card games, for example, it is relatively trivial to note how the rules for those games are almost always presented in a clear sequence of steps: Do this, then do this, then do that…

The flexible and open nature of roleplaying games obviously complicates this rigid sequencing. But, once again, we can see the value of having a default structure to serve as a backbone from which flights of greater fancy can be launched.

On a similar note, I want to briefly mention the value of reference sheets, worksheets, and efficient note-taking.

A common reference sheet is the GM’s screen. And it’s usually amazing to me how often the design of these screens seem to evidence no understanding of how a particular game is actually played. So, my general tip: As a GM, pay attention to the rules and tables you, personally, are looking up during play. Particularly note anything that you’re referencing frequently or which you find yourself wanting to reference quickly (during combat, for example). That’s the stuff you want to put on your GM screen.

Structured worksheets for the GM used to be common place in the hobby, but they became very scarce in the late ‘80s and ‘90s. I suspect this is because this was a period in which the hobby was abandoning clear game structures, which meant that there was no way to design worksheets that would actually be widely applicable. But one of the first things I developed for running my Thracian Hexcrawl was a worksheet for tracking travel progress through hexes.

On a less formal level, spend some time thinking about how you take notes. What type of stuff – like retainer morale or AC – are you frequently asking your players to look for? Is there a better way you could be keeping track of hit points for your monsters? And so forth.

Go to Part 9: Archaic Game Structures

Game Structures – Part 7: Playing With Hexcrawls Thought of the Day: Blue Doors of Ptolus Game Structures – Addendum: System Matters