-- Download post as PDF --
I’ve written before about those moments where a solution to a problem presents itself almost fully formed, leaving you saying “why didn’t I think of this before? It’s so obvious!” I had another one of those moments with this project last week. That’s what I want to talk about today.
I’m sure you remember (because I mention it a lot) that I initially laid out a set of design principles that I wanted to use to guide me as I build this setting. One of those principles – and, arguably, the most important one – is that I don’t want to build anything that won’t see play at the table. Then, of course, I started building a hex crawl. Hex crawls tend to do the opposite of what I wanted; the GM details each hex, and the party may or may not encounter them.
I haven’t written about it a huge amount, but this has been an ongoing issue for me in figuring out how to build this setting and design the campaign. Now, though, I think I have a solution, and I’d like to run it past you.
As often happens with this things, the idea arrived when I was actively not working on the project. I’d decided I was going to relax, and started watching the latest NoClip documentary about The Witcher. (As an aside, if you’re a video gamer and you don’t know about NoClip, stop what you’re doing and go watch some of the videos. They’re excellently produced documentary series about video games; I think of them as the spiritual successor to All Your History Are Belong To Us).
The video in question was the third in this series, about The Witcher 3’s world design. The developers spend some time talking about how they spaced out content across the map so that it isn’t either too crowded or too bare, and so that players always have aspirational views – i.e. something on the horizon that they can see and aim to get to.
Of particular interest to me was the distinction the developers drew between Points of Interest and Points of Encounters. I honestly can’t explain why this was such a revelation to me, but something about the way they discussed working with those two systems made everything click together in my head, and suddenly I had a solution.
It’s not a novel solution, really. It’s certainly not something that I’ve “invented” myself, or whatever. In fact, it’s going to draw on both video games and board games – specifically, Legacy-style board games like Pandemic Legacy and Seafall.
I’ve said all along that I intend to give the players a partial hex map of the island, showing the areas they know about when they arrive and leaving them to fill in the rest as they explore. That’s pretty standard hex crawl stuff. The idea – and the problem – was that the GM was going to be given a fully filled-in hex map, and that required me to fully populate the island with a ton of things that might not ever see play.
So, here’s my idea. What if the GM also has a hex map that isn’t complete? It will certainly have more on it than the initial player map – sites like the turtlekin village, for example, and the ruined city that I want to include – but the rest will essentially be blank.
Then, rather than using random encounter tables (which I want to avoid as much as possible), I’ll instead give the GM a list of PoIs and PoEs that are to be encountered in a certain order. No matter where the party explores, they will always find these things. They’ll fill them in on the map, and the GM will fill them in on her map, and nobody need ever know that these things weren’t always where the party discovered them.
Essentially, what I’m talking about is building a giant railroad and hiding it beneath the trappings of a hex crawl. I’ll have to think much harder about how it works mechanically, of course, because I’m obviously wary of the connotations of railroading players. But in theory I’m really excited about this idea. I like the idea that every group that plays this campaign will end up with a different map at the end of the campaign, a unique log of the adventure that they have been on.
Now, there will be things I need to work out – things like accounting for different types of terrain, for example. I can’t exactly put a swamp temple on a table for the players to find, and then have it turn up halfway up a mountain. But that’s where the idea of having certain sites keyed to specific places – like a traditional hex crawl – comes into play.
I’m actually wondering if I can learn something from the way that procedurally generated video games work to populate their levels, but that will take a lot more research on my part. I’m not entirely sure how procedural generation would work in a player-driven, narrative tabletop RPG, but if I can make it work I will. And if I can’t, I still think I’m sitting on a potentially solid system that will enable the party to explore while still allowing me to unravel a narrative for them.
This also solves the problem of the ruined city. I really, really want to include it, but I didn’t want to end up building a ruinscrawl on top of a hex crawl. That would be yet more content to build that may never see play. But now I can use the same system in the ruinscrawl, to; the GM will have a map that shows a couple of hard-coded points of interest (like the entrance to the flooded mines at the base of the mountains), but the rest will be blank and will be filled out as the party explores, with the GM placing locations as they discover them.
One thing that this system is going to need to do is to provide guidance for how to prepare each session. Expecting a GM to track where the party are on a blank map, while simultaneously populating that map, on the fly, is a big ask, so I’m going to have to ensure that it’s as easy to run as possible. I’m really excited about the possibilities here, though, and I’m feeling as enthusiastic about this project as I was when I started it. That’s always a good thing.
Finally, I just wanted to thank those of you who took the time to write such in depth comments on last week’s post. I haven’t had a chance to respond to them yet, but I will. In the meantime, let me know what you think of this, and if you foresee any pitfalls that I might have overlooked in my eagerness to get these ideas out of my head.
I think my next step is to build a very small proof of concept hex crawl for this system, just to see if it can work before I try to apply it to this big campaign. I’ll try and get some work done on that for next week.