[Reviews of classic hexcrawls in Part 1 and newer hexcrawls in Part 2]
In part 1 of this series, I posited that procedure influences hexcrawl maps and hexcrawl maps should influence procedure. Largely, this is I also posited a some core questions the hexcrawl should answer. Let's look at those more in depth.
1. Is the crawl a "mini-game" to get to one location or meant to sustain multiple sessions?
Some adventures have a hexcrawl to fill space between the town and the dungeon where the real meat of the adventure is. The GM might handwave the return trip to town, skipping a repeat hexcrawl. This is a perfectly fine way to use a hexcrawl, but this means the hexcrawl procedure should be light; essentially a question of "which way do you go next?" similar to how you handle moving between rooms in a dungeon crawl.
If you're planning on using this type of approach, the core design constraint is pacing: How can players get from point A to point B without it being a slog?
You can calculate pacing pretty easily - if each hex has a 1-in-6 encounter chance, and you typically get through 3-4 encounters in a given session, if you put your dungeon ~15 hexes away from the town, you should be able to get there in a single session (maybe a little closer to let players explore more).[1] Don't let players aimlessly wander, searching for the dungeon. Give them vantage points, a treasure map, monster tracks, etc.
Most hexcrawls I've discussed thus far are meant to sustain multiple sessions of play. For these, you need to consider navigable paths, vantage points, and key location placement more specifically.
2. Are hexes being used to solely measure distance or is there play to travel?
Sprawling, world-sized hexmaps would be impossible to fully key unless you're a psychopath. For extremely large maps, such as Middle Earth, it's more helpful to use hexes as measures of distance. Procedure-wise, have the players draw a route on the map they wish to take. Calculate time required and resolve encounters as appropriate. At a large enough map, this is functionally a point crawl with added steps. [2]
Smaller maps allow for more options for travel. While players move from hex to hex, can they Search a hex? Can they hunt? Can they get lost? If so, it's important for there to be visible landmarks to orientate direction. Can these landmarks help travelers see other locales? Here, you have to consider if hex information is automatically discovered or only if time is spent via Landmark, Hidden, Secret doctrine.
3. How many hexes should a group get through in a session of play?
My main complaint about Isle of Dread and Tomb of Annihilation was those adventures had rules that made traveling a single hex arduous (multiple encounter checks per day) and expected players to travel dozens of hexes to reach points of interest. These two design goals are at complete odds with each other. If you want players to traverse dozens of hexes, make resolving travel at the table fast in IRL time.
On the other end of the spectra, you can slow down hex completion by either using crunchier rules or by creating dense hexes. More travel options (crunchier rules) takes longer to resolve at the table and should feel meaningful. If players can search hexes, there should probably be something in every hex, even if it's minor. If players can hunt, food must be important. In short:
The more compact a hexcrawl, the more crunchier your rules can be.
What about making really dense hexes? Well...
4. How much time should they spend in 1 hex?
Again, this is a pacing question and directly relates to the previous one but relates more to what you put in a hex rather than the procedure around it. If you put interesting, interactive things in a hex, the players will spend more time there. If all hexes are the same endless jungle, then players should be able to move quickly through all of them.
I've already complained about these two modules, but if Isle of Dread or Tomb of Annihilation had every hex fully stocked, I think those adventures would still be a slog because they would take forever because the ultimate goal or "plot" is getting from Dungeon A to Dungeon B. The stuff in between is just slowing you down.[3]
Conversely, with a compact hexcrawl, you can have every hex stocked. Your players can spend ~30 min poking around a random hex and still feel like they accomplished a lot during a session. Of course, not all hexes are created equally. Dungeons, towns, and faction headquarters will eat up more playtime than the hexes between them. But it might feel less satisfying if the journey wasn't interesting either.
---
I believe the core problem with hexcrawls is the interface between Backend and Runtime as described here. Hexcrawls largely struggle because the map & procedure (backend) do not support good pacing (runtime). I'm an advocate for each hexmap having slightly different rules, size of hexes, etc. because that encourages slightly different styles of play, even if it is annoying to mentally switch from 6-mile hexes to 3-mile hexes. Hopefully thinking through these questions and understanding how map design and procedure influence actual play at the table will better support hexcrawl design.
---
[1] This is actually pretty similar design to a 5-room dungeon, though with more freedom of exploration.
[2] An aside. Really large hexmaps require random generation to stock or absurd amounts of prep time. Random generation can be done in play with good random tables, but removes intentional map-design. I'm an advocate of Blorb principles and lean on the maximal prep side of things.
[3] Especially in 5e where resource management isn't a huge issue. If resting overnight completely restores you, then combat encounters with no stakes are an IRL time waste.
No comments:
Post a Comment