As someone who began his role playing career quite late in the game I missed out on the whole hexrawl phenomena of older generations of D&D. It just wasn’t on the radar for anyone in the 3e circles I gamed in. So what I now know about hexcrawls does not come from first hand experience but rather from reconstructing the mechanics of this device from older source material and from tapping the collective wisdom of the blogosphere.
Fortunately there is a bounty of information on this topic available to anyone looking for it. I discovered that the basic structure of hexcrawl looksd something this:1
- Draw a Hex Map – the scale of the map ought to be numbered for easy reference, ought to have an appropriately sized hex scale, and ought to simply and clearly represent geographic details.
- Key the Hexmap – fill the numbered hexes with interesting and engaging content. Depending on one’s design philosophy, this may include filling each of the hexes or only some of them; the content may be restricted to physical locations only or it may more broadly include a variety of different role playing encounters.
- Employ Encounter Tables – design or utilize random encounter tables that answers questions like: “what sorts of creatures does the party run into?” and “what is their attitude toward the party?” and “what is the chance of such an encounter occurring?” and “how often is an encounter check made?”
- Employ Travel Mechanics – design or utilize mechanics that determine how far a party can travel given factors like terrain type, mode of travel, weather and whether or not the party is traveling along a road or track or is blazing their own trail.
- Employ Survival Mechanics – design or utilize mechanics detailing how navigation works and what happens if the party gets lost, how hunting, fishing an foraging work and how resources like food and water are tracked, and how environmental factors such as extreme heat or cold affect the party.
- Employ Weather Mechanics – design or utilize mechanics to determine what sort of weather the party encounters each day and what sort of affect it has on them.
- Employ Exploration Mechanics – design or utilize mechanics that indicate the likelihood that the party will automatically encounter a keyed hex entry, and how active exploration might improve the chances of finding non-apparent keyed items.
Further, there are ample examples of the the various mechanics glossed above available in published materials and blogs, so there is no need to create these whole cloth. Of course, there is predictable variance among the various mechanics on offer (e.g. suggested hex size) but one can easily cherry-pick and adapt these as needed to one’s own campaign.
That said one thing I haven’t really seen talked about all that much is a set of orderly procedures for determining how and when to employ these mechanics at the table, as in: “First do A, then B, then C and if D happens then do E” etc (although one notable exception is Justin Alexander’s checklist).
Perhaps this is because most people writing on the topic have been doing this long enough to have developed their own internalized hex procedures and no longer think about it. Or maybe it’s the case that the mechanics are thought to be clear enough not to require any further explanation. In any event, from an outside perspective looking in I was left with unanswered questions about how the actual crawl should proceed.
“How often do you check to see if the weather has changed?”
“Which happens first, the random encounter or the pre-keyed hex encounter?”
“If the party becomes lost, when and how do they discover this fact?”
So I decided that I’d develop my own simple procedure for hex crawling. One thing that I borrowed from Alexander’s method was the idea of breaking up the day into 4 hour increments called watches. A party can travel up to two watches per day without penalty. After that weariness sets in. Each new watch I proceed, in logical (though in some cases not necessarily chronological) order, with the following steps:
- Determine Weather – I’ll be using Pathfinder’s Weather Generator for this.
- Roll for Random Encounter – This will occur in two stages. First roll on the appropriate table to determine whether or not an encounter occurs. Second, roll 1d4 to determine which hour of the watch the encounter occurs in.
- Determine Navigation – If the party does not move during this watch (e.g. because they are camping) this step is skipped. Otherwise the party tells me what direction they would like to go. If they are following a road, a clear trail, a river or are using clear landmarks then no check is needed. Otherwise I’ll ask the party which direction they want to go and will then make a hidden navigation check (using the highest relevant ability in the group) to see whether or not the party moves in the correct direction or veers slightly to the left or right. If the party fails this roll they become lost. If a party was lost during the previous watch then during this step I will make a secret navigation roll to determine if they recognize that they are lost.
- Determine Movement – If the party is traveling they must select a mode of movement. They may move normally, they may forage or they may explore. If the party is foraging they move at half speed but are allowed to make a single survival check to attempt to find food and water. If the party is exploring they move at half speed and they get a +5 to the d20 roll to determine if they locate any hidden or hard to find keyed locations. I then apply any conditional modifiers to determine how many miles the party travels during the watch.
- Determine if Keyed Encounter is Triggered – This step only occurs if the party is traveling. First I determine if the encounter is triggered. If the encounter involves a clearly visible terrain feature then the encounter is automatic. Otherwise I roll a d20 against a DC of 15 (or 20 for difficult to locate encounters) to determine if the encounter occurs. If the encounter does occur, I roll a 1d4 to determine which hour of the watch it occurs in. It is possible that a keyed encounter occurs simultaneously with a random encounter.
And that’s basically it. I tried to keep this procedure fairly simple and straight forward. We’ll see how well it actually works when it’s play-tested in my campaign. I’m open to constructive criticism if anyone has any advice to offer.
1 This is a slightly expanded version of Justin Alexander’s proposed structure.