Go to Part 1

Consider, for a moment, the explicit game structure presented in the original Traveller.

(1)   Create a subsector. For this, the game gives guidelines for creating a starmap; populating that starmap with planets; determining the population, law level, and technological level of those planets; determining travel zones and trade routes; and so forth.

(2)   Own a starship. The game offers several options by which the PCs can own, lease, or otherwise operate a starship.

(3)   Interstellar movement. Providing mechanics for determining how far and how fast PCs can move between planetary systems.

(4)   Trade and revenue. Finally, explicit guidelines on how revenue can be earned by carrying cargo, passengers, and the like.

When you boil it down, this is Firefly: The Roleplaying Game.

But what this scenario structure notably lacks is any support for play below the interplanetary level. Traveller recognizes this lack and works to patch the hole with the concept of the Patron:

The key to adventure in Traveller is the patron. When a band of adventurers meets an appropriate patron, they have a person who can give them direction in their activities, and who can reward them for success. The patron is the single most important NPC there can be. (Book 3: Worlds and Adventure)

Basically, the patron serves as a default method for delivering adventure seeds to the PCs. And Traveller integrates the patron into its larger game structure by triggering patrons through its random encounter system. (So, basically, every time the PCs fly into a starport there’s a chance they’ll be contacted by someone with a special job.)

Of course, this still leaves the vast gulf of what the game structure for the actual mission itself is. But it’s not as if Traveller is alone in having such gaps in its scenario structure. In fact, virtually all RPGs have such gaps. (And, at a micro-level, virtually all RPG mechanics constitute incomplete game structures, as our example of the Duchess of Canterlocke demonstrated.)

MECHANICS WITHOUT STRUCTURE

I’ve long maintained that RPGs naturally gravitate towards their mechanics. For example, when I added counter-intelligence mechanics to D&D, counter-intelligence suddenly became a significant part of my campaign. When I added usable encumbrance mechanics to my OD&D campaign, encumbrance-based gameplay immediately followed.

What’s even more true, however, is that RPG gameplay naturally gravitates towards structure. Because they’re open-ended, of course, RPGs are not bound to their structure (like a boardgame is) and good game structures in RPGs won’t act as straitjackets, but clear game structures nevertheless attract players and GMs alike.

Or, to put it another way: If you’re in a dungeon, at some point you’re almost certainly going to start dungeoncrawling.

An interesting corollary of this is that mechanics which aren’t (a) required by a well-defined game structure or (b) enhancing a well-defined game structure are often ignored.

As a result of this corollary, you’ll often find popular game systems ringed with a large number of rules which nobody uses. Many of these rules seem to accumulate from a vestigial urge for simulationism.

This is particularly true with specialized supplements. For example, the D20 market is crammed full with supplements that aimed to provide the “Definitive Guide to Ships”. The little simulationist urge says: “There are ships in fantasyland. So we must need rules for ships.”

But once you have them, what do you do with them?

A typical seafaring supplement, for example, usually included all kinds of rules for varying the speed at which a group traveled: The ship they’re using, wind speed, crew experience, navigation checks, weather conditions, tidal drifts, and so forth. But unless you’re using a scenario structure in which travel time matters – and in a modern era of railroaded scenarios, it generally doesn’t – all of these rules are pretty much irrelevant. Oh, having some guidelines for how long it takes to get from Point A to Point B is nice, but anything involving a lot of calculation which varies from one day to the next is basically useless chaff.

That’s how you get books full of feats that nobody takes, spells that are rarely cast, rules for ramming that nobody bothers with, and so forth. Without a supporting scenario structure, this stuff just flounders: It occasionally gets toyed with, but it rarely gets used.

But imagine for a moment that someone took the time to design a fully-integrated scenario structure for sea-based play that, for example, made playing a pirate or a privateer just as much fun as dungeoncrawling or solving mysteries. You could build entire campaigns around this structure, or just slot it in as appropriate. Maybe you could even go ahead and publish a full campaign that people can just pick up and play. Suddenly all those rules for handling crew morale and ship-to-ship combat are being used.

And if your new scenario structure were really successful, suddenly you’d have opened up a whole new market for support products.

THE VALUE OF PARTIAL STRUCTURES

The “gravitational effects” of clearly defined game structures may also help to explain why even partial scenario structures have often proved monstrously successful in the RPG industry.

For example, consider Shadowrun and Paranoia. Neither game features a comprehensive scenario structure, but they both have default methods for delivering scenario hooks which also tend to lend a common shape to their scenario concepts. And you can see evidence for the efficacy of these techniques in the number of “traitorous Mr. Johnson” stories you see from Shadowrun and the number of “briefing room horror stories” you see from Paranoia.

In fact, even partial scenario structures seem to be very effective at providing a commonality of experience which can draw a player base together into more meaningful communities. (This is particularly true for default scenario hooks.) Such communities provide a strong network effect which further strengthens the game.

This commonality of experience also makes it possible to produce supplements which target that common ground. 76 Patrons for Traveller or Mr. Johnson’s Little Black Book for Shadowrun are obvious examples given the context of our current discussion, but it’s particularly true when it comes to adventure modules: You can trivially produce an adventure module for D&D which could theoretically be plugged into 90% or more of the current campaigns being run in the system. On the other hand, it would be essentially impossible to produce a Heavy Gear module for which that would be true.

Of course, having a viable market for those kinds of adventure products makes it easier for a publisher to produce adventure products. And having adventure products available makes it easier for new GMs to start playing the game. Which further enhances the network externality of the game.

Go to Part 11: Complete Game Structures

Go to Part 1

As we wrap up our discussion of the hexcrawl game structure, I thought it might be interesting to take a few moments to revisit a few archaic game structures that have been abandoned by the hobby.

Until recently, of course, the hexcrawl itself could be described as an archaic structure. By 1989 there were a few vestigial hex maps cropping up in products, but none of them were actually designed for hexcrawl play. The 2^nd Edition of AD&D removed hexcrawling procedures from the rulebooks entirely. It wasn’t until Necromancer Games brought the Wilderlands back into print and Ben Robbins’ West Marches campaign went viral that people started to rediscover the lost art of the hexcrawl.

The original game structure for hexcrawls described in OD&D is actually quite distinct from the hexcrawl procedures I described earlier (which were largely innovated by Judges Guild and than adapted into AD&D). The bulk of wilderness adventures in OD&D focused on castles:

Castles: As stated, the ponds [on the Outdoor Survival gameboard] indicate Castles. The inhabitants of these strongholds are determined at random. Occupants of these castles will venture out if a party of adventurers passes nearby. If passing over the castle hex there is a 50% chance (die 1-3) that they will come out, if one hex away there is a 33-1/3% chance (die 1-2), and if two hexes away there is only a 16-2/3% chance (die 1). If the party is on the castle hex and hails the castle, the occupants will come forth if the party is not obviously very strong and warlike. Patriarchs are always Lawful, and Evil High Priests are always Chaotic. All other castle inhabitants will be either hostile to the adventurers (die 1-3) or neutral (4-6).

This is followed by a random table for determining the occupant of a castle and their guards/retainers. Then specific procedures for each type of inhabitant are provided: Fighters will “demand a jousting match with all passersby of like class”, Magic-Users will “send passerby after treasure by Geas if they are not hostile, with the Magic-User taking at least half of all treasure so gained”, Clerics will “require passersby to give a tithe (10%) of all their money and jewels” and so forth.

A vestigial remnant of this structure survived all the way into the Rule Cyclopedia (where tables were still being presented to randomly determine the attitude of castle occupants), but I’m guessing it’s been essentially nonexistent in actual play since 1980 at the latest. And, unlike JG-style hexcrawling, I doubt these “castle occupant rides forth” game structures are likely to enjoy a significant renaissance any time soon.

(Although, on the other hand, there are some potentially interesting things lurking in there: First, the implied setting – in which civilization is so sparsely populated that feudal lords will ride out to meet travelers who pass anywhere within a dozen leagues of their walls – is a fascinating one. Second, note how the structure provides default scenario hooks: Like the treasure maps seeded randomly into OD&D hordes, the quests proffered by feudal lords can spontaneously transform the aimless exploration of the hexcrawl into specific direction. But I digress.)

The other major procedure for wilderness play in OD&D was the idea of “clearing” a hex of monsters (which was a prerequisite for establishing a barony or stronghold):

The player/character moves a force to the hex, the referee rolls a die to determine if there is a monster encountered, and if there is one the player/character’s force must remove it. If no monster is encountered the hex is already cleared. Territory up to 20 miles distant from a stronghold may be kept clear of monsters once cleared – the inhabitation of the stronghold being considered as sufficient to maintain the monster-free status.

This basic structure was greatly expanded in AD&D. (For example, it added a precise system for determining when and how monsters return to an area, along with all kinds of modifiers – like placing skulls and carcasses as warning signs.) And then it, too, faded away.

In fact, if you look back at the early history of gaming you’ll find these kinds of explicit game structures all over the place: The system for artifact use in Gamma World, the mercantile models of Traveller, the posse and tracking system for Boot Hill (which, in the 2^nd Edition, could be tied into a larger competitive structure of lawmen vs. outlaws), the status points of En Garde, and so forth.

What you had, in short, were a bunch of wargamers who were very familiar with creating specific game structures heavily laden with the details of world simulation: After all, they’d been using precisely defined game structures to model historical battlefields for years. Roleplaying games, however, cracked open the game world, and the game designers were applying game structures to a much wider “world simulation”.

Over time, for a variety of reasons, these explicit game structures became more and more simulationist in nature. As the focus shifted from structures that were fun to play to structures that were accurate “models of the game world”, however, the structures became rather boring and (as the details of the simulation became fetishized) often too complicated to use in actual play to any great effect.

What followed next (and this all happened over the course of only a few short years) was almost inevitable: The explicit game structures became vestigial and then, with the advent of universal systems, disappeared from rulebooks entirely. (With the notable exception, of course, of highly structured combat systems.)

But — and this is important to understand! — the game structures didn’t actually disappear from gaming! They are, after all, essential for play. Instead, a handful of the most popular structures became treated as a sort of common knowledge: Everybody “knew them”, so game designers didn’t bother explaining them. (Although, in truth, very few people really thought about them at all.)

In short, the general sense that playing an RPG consisted of nothing more than “the players tell me what they want to do and then we resolve it” settled over the industry. But, as we’ve seen, this is completely false. What happened in actual practice was that GMs would use a random grab-bag of unexamined techniques that they had collected from people they played with, published adventures, and the occasional unique insight. And this, of course, resulted in a lot of frustrating play.

The lack of explicit game structures in the rulebooks – particularly explicit scenario structures – also helped to make roleplaying games a lot less accessible to people who hadn’t played them before.

Imagine that you took the rules for the boardgame Arkham Horror and you stripped out all the rules about explicit turn sequencing (i.e., the scenario structure of the game): Instead, you’re left with some rules about how to make skill checks; how far you can move around the board each turn; how to fight monsters; how you can move through gates and close them behind you; how you can fight Ancient Ones if they wake up; and so forth. But… what do you do with all those rules?

And that, in short, is what virtually every RPG for the past thirty years except for D&D has looked like to newcomers. (And it is somewhat worrisome to note that every iteration of Dungeons & Dragons since 1983 has reduced the amount of explicit game structure in the core rulebooks until, finally, 4^th Edition eliminated dungeoncrawling procedures almost entirely.)

But as we look back at the archaic era of explicit game structures, I think there is something else of import to note that may help to explain why they went way: With the exception of the ‘crawls and a few others, almost all of these game structures were fundamentally incomplete.

Go to Part 10: Incomplete Game Structures

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

Go to Part 1

Once an experienced GM has learned how to use a particular game structure, it’s usually trivial for them to “bling it out” with additional game structures that add flavor, complexity, or detail to a scenario.

If we take the basic structure of a hexcrawl, for example, what could we add (or tweak) to change (and hopefully improve) our game?

Random Encounters: A simple example. Just as random encounters add life and activity to a dungeon complex, they can also make a wilderness setting come alive. And it’s pretty easy to add periodic encounter checks to our hexcrawl procedures. Of course there are still questions to be answered about our exact methodology: Do we check once per hex? Once per day? Several times per day?

Hexes Are Big: Does it make sense for PCs to automatically find a hex’s keyed encounter as soon as they enter the hex? Probably not. A typical 30-mile hex (like those used in the original Darlene map of Greyhawk) is larger than New York City and two-thirds the size of Rhode Island. That’s a lot of territory for a couple dozen orcs or a lonely cave entrance to get lost in.

To model this, we could make the chance of experiencing a hex’s keyed encounter variable. We could even vary the probability of this (making it less likely to encounter hidden locations and more likely to encounter highly visible locations).

Navigating the Wilderness: Once you’ve left roads and well-beaten trails behind you, it’s relatively easy to become lost in the wilderness (particularly if you’re not properly trained). So rather than just letting players determine precisely the direction they want to go, we could add a skill check to determine whether or not they become lost (and, if they do, determine their true direction of travel randomly). To spice things up, we could set the difficulty of this check based on the terrain type they’re currently traveling through. We could even have weather conditions modify this check (so that, for example, it would be more difficult to find your way on stormy, overcast nights than when the stars were visible).

Mode of Travel: Are the PCs traveling at a normal pace, racing at high speeds, covering their tracks, spending time foraging, or crisscrossing their own path in order to thoroughly explore the local area? Based on these decisions, we could vary the speed at which they travel; the difficulty of navigation; the odds of finding local points of interest; and so forth.

Other Game Structures: Tulan of the Isles, a lesser known product written by Raymond E. Feist and Stephen Abrams in 1981, includes a full game structure for prospecting gems. The Ready Ref Sheets from Judges Guild included a similar system for prospecting, detailing the amount of time it takes to prospect a hex, the percentile chances of finding a vein of precious metal, and a methodology for randomly determining the type of vein and its value.

I offer this up not as something that every hexcrawl campaign requires, but rather as an example of how we often don’t think about the game structures that we use. If your players decided they wanted to go prospecting, how would you adjudicate that at the table? Would the method you use remain balanced over time if the players decided to make prospecting a major part of their characters? Could you make it as much as fun as dungeoncrawling? (If not, why not? Think about it.)

Consider, too, how the availability of game structures subconsciously shapes the way we play the game. Would you, as a GM, be more likely to design a scenario hook in which the PCs are hired by a dwarven king to prospect potential gold mines in the Frostbite Peaks if you had a fun little mechanic for prospecting to build a larger situation involving goblin reavers, icingdeath undead, and rogue frostmancers around? Would your cash-strapped players be more likely to spontaneously consider prospecting in the wilderness a viable alternative for cash if the rulebook included a chapter of rules for it?

Go to Part 8: The Importance of Clean Procedures

Go to Part 1

The basic, traditional design of a hexcrawl looks something like this:

(1)   Draw a hexmap. In general, the terrain of each hex is given as a visual reference and the hex is numbered (either directly or by a gridded cross-reference). Additional features like settlements, dungeons, rivers, roads, and polities are also typically shown on the map.

(2)   Key the hexmap. Using the numbered references, key each hex with an encounter or location. (It is not necessary to key all of the hexes on the map.)

(3)   Use (or design) mechanics which will let you determine how far the PCs can move while traveling overland. Determine the hex the PCs start in and track their movement.

(4)   Whenever the PCs enter a new hex, the GM tells them the terrain type of the hex and triggers the encounter or location keyed to that hex: The PCs experience the event, encounter the monsters, or see the location.

In the traditional structure, it’s also expected that the PCs will be mapping the hexes as they explore.

And that’s pretty much it.

ANALYZING THE CRAWL

As we look at this basic structure for the hexcrawl, we can begin to see some common features of the ‘crawl structure in general.

Default Goal: The default goal of a hexcrawl is exploration. This notably lacks a strong, specific motivator. In a dungeoncrawl, as we discussed, the default goal is to “find all the treasure”, “kill all the monsters”, or some other variant of “clear the dungeon”. Exploring and mapping the dungeon is usually a part of this experience, but the exploration is primarily a means to an end.

Thus, over the years, various goals have been grafted onto the hexcrawl structure to provide a strong motivation for the exploration. (For example, the hexcrawl campaign I’m currently designing takes place on the edge of civilization and there are bounties paid for those who first make interesting discoveries in the wilderness.) But I suspect one of the reasons hexcrawling faded away in the early days of the hobby is because, unlike dungeoncrawling, it lacked a clear, default goal to provide strong motivation and a reward structure.

Default Action: Just like a dungeoncrawl, the default action of a hexcrawl is “pick a direction and go”.

Easy to Prep: In terms of robust design, hexcrawls are very easy to prep. If it’s difficult for the GM of a dungeoncrawl to forget to include a door, it’s even more difficult for a GM to prep a hexcrawl in which the players can’t pick a direction to go. (If the GM isn’t keying every hex, there is a slight danger that they won’t include a sufficient density of content to make play interesting. This is a minimal risk, but consider something like X1 Isle of Dread: Presented as the introductory hexcrawl wilderness scenario for BECMI, the content of the module is actually too sparse to be effectively run as such.)

In terms of prep load, however, hexcrawls can be a little more difficult. Partly this is because there’s no natural “end point” for prepping a hexcrawl: Trying to key an entire world (or even just a full sheet of hexes) can look pretty daunting, and early game manuals weren’t very instructive in terms of explaining how prep load could be managed.

But hexcrawls can also represent a heavy prep load because any given hex can literally require just as much prep as an entire dungeon (if it, for example, has a dungeon in it).

Easy to Run: Once given a proper game structure, I find hexcrawls very easy to run. Even moreso than dungeoncrawls the content of the hexcrawl is naturally firewalled into discrete sections.

One thing that makes hexcrawls a little more difficult to run, however, is the transition between “levels” of material. In a dungeoncrawl, everything is handled at roughly the same level of abstraction: Whether you’re moving between keyed areas or interacting with the content in a keyed area, the actions are described in a consistent (and very specific) way. In a hexcrawl, however, the GM needs to find the effective transition point between “you spend most of the afternoon traveling over the rolling hills east of Maernath” and “you’re fighting orcs; where are you moving in the next ten seconds?”

This is not a massive difficulty, of course, but it does require the GM to develop an additional skill set. Thus it is easy to see the hexcrawl as a natural progression from the dungeoncrawl for the GM: A robust structure using many of the same skills, but also requiring the development of a few new tricks.

Structure, Not Straitjacket: As with the dungeoncrawl, players are given a default action (“pick a direction and go”), but within the hexcrawl scenario structure they’re still free to do pretty much anything their imaginations can concoct.

Flexibility Within the Form: Even moreso than the dungeoncrawl, a GM can put just about anything they want into a hexcrawl scenario structure. (It is, after all, a method for keying an entire world.)

SUMMARIZING THE ‘CRAWL

Looking at the dungeoncrawl and hexcrawl side-by-side, I think we can begin to draw some general conclusions about the ‘crawl structure in general:

(1)   It uses a map with keyed locations. (This provides a straight-forward prep structure.)

(2)   Characters transition between keyed locations through simple, geographic movement. (This provides a default action and makes it easy to prep robust scenarios.)

(3)   The structure includes an exploration-based default goal. (This motivates player engagement with the material and also synchronizes with the geographic-based navigation through the scenario structure.)

In practice, I’ve also found that these ‘crawl structures make it very easy for groups to engage, disengage, and re-engage with the scenario. (You can go into a dungeon, fight stuff for awhile, leave, and when you come back the dungeon will still be there.) This, it turns out, makes them ideal structures for casual play (because players can feel as if they’ve accomplished something even if the dungeon is only half-explored) and open tables (because the disengagement/re-engagement process allows completely different groups of players to interact with the same material).

After considerable thought, I’ve concluded that these latter properties come from:

(A)  Material within the scenario structure is firewalled. (In general, area 20 of a dungeon isn’t dependent on area 5.)

(B)   The default goal is holographic. (You can explore some of the wilderness or get some of the treasure and still feel like you’ve accomplished something. You can’t half-solve a mystery or execute half a heist and feel the same way.)

(C)   The default goal is non-specific. (You can get a bunch of treasure from Dungeon A; then get more treasure from Dungeon B and still be accomplishing your goal of Getting Lots of Treasure.)

(D)  The default goal isn’t interdependent. (You can clear the first half of a dungeon and somebody else can clear the second half. In general, you can’t solve the second half of a mystery unless you’ve got the clues from the first half.)

We’ll be coming back to see what we can do with these general principles of the ‘crawl structure, but first I want to turn back to the hexcrawl scenario structure and see what we can build on top of a basic structure.

Go to Part 7: Playing with Hexcrawls