DESIGNER DIARY
How I Designed a Pirate Treasure Hunt Board Game (And Why It Sucked)
What I Learned Making a Treasure Hunt Roll & Write Game — Chapter #1
I’m obsessed with Roll & Writes. If you follow me, you already know that I wrote about this new genre here and listed my favourites here. If you don’t, please do, and accept this quick recap as a thank you gift: Roll & Writes games are fun puzzles that are quick to play and have satisfying sheets to fill.
As a professional game designer who admires a new genre, I had to try making my own. In this series of articles, I want to invite you to discover the process of creating a board game from the initial idea to the commercial release (hopefully).
Part 1 — The Birth of an Idea
My first intention was to design a coherent product, to start with a concept where the theme, the mechanic and the paper format fit well together. It’s not my favourite Roll & Write, but I admire how Cartographers’ immerses players in the shoes of map makers by having them literally draw a map.
I just needed an idea.
There is this other rather unique game called Cryptid, where players try to identify the spot where a legendary creature is hidden. I love the magic feeling when you finally narrow down the possibilities to just one place which fits all the clues (before your opponents if possible).
Eureka!
I made the right first step, but making a game is like running a marathon; you can’t stop to congratulate yourself for not tripping in the first meters.
It’s time to work on the prototype.
Part 2 — Prototyping With Unreal Engine 4
Like Cryptid, my first challenge is to prove I can generate the ‘scenarios’: a combination of clues that lead to exactly one spot. For this duty, I’ve used the tool I know best, Unreal Engine 4, which is convenient when you don’t want to code.
In this part, I’ll give a quick overview of this program. Going digital saves a lot of time; I advise it to all board games designers. It might not be technologically impressive compared to video games, but it’s a giant leap forward compared to paper only prototypes.
So, the main screen shows a square-tile map with the three different terrains (grass, sand, rocks) & three ‘landmarks’ as I call them. I have a bunch of information on the left to help me with the balancing, and on the right, I have several buttons to toggle ‘conditions’ (the future clues).
Using these buttons, I can quickly see how many possible spots remain when you combine certain clues. For example, in the gif below, I filter all the tiles ‘Terrain: Grass’ & ‘4 steps from the Dead Trunk’ & ‘Adjacent to Sand’.
The “Search solution” button gives me a set of four clues that have precisely one tile in common. I don’t have an elegant algorithm, my approach is brute-force: I randomly toggle clues on & off until it works.
Behind the scenes, here are the Blueprints I use. If you’re not familiar with UE4, Blueprint is the visual scripting tool that you can use as an alternative to code. It has everything you need to implement simple logic made of loops, variables & conditions.
Using UE4 helped tremendously kickstart the project and generate puzzles faster than I ever could manually. In addition, the tidbits of data allowed me to quickly iterate on the map layout & the clues I should use, which would have taken tedious hours of playtesting to figure out otherwise.
We’ve got a map, clues and hidden treasure(s), yet still far from the finish line because I had no idea how to approach the design of the rest.
Part 3 — Building a game around it
Like most Roll & Writes, the core game loop has players choosing among few movement possibilities each turn. In order to randomly generate the options, dice rolls could work, but I prefer cards for two reasons. First, cards can have information printed directly on it (faster to learn) and second, do not repeat until you shuffle (more predictable & more evenly distributed randomness).
For the rest of the mechanics? I admit I didn’t know what to do, and at this point, it felt more important to test it fast than to wait for ideas to come. So I put up some arbitrary rules & mechanics that I won’t describe in detail since they ended up cut anyway.
I printed the prototype, and we playtested it the same evening.
It wasn’t laughably bad, but it would still have got the very last spot on my Roll & Write ranking to give you an idea.
The game had three main issues:
- Firstly, the goal to reach the central ‘cavern’ was too easy, which I knew, but my fix was worse. The scoring encouraged to chain as many pirates as possible before going to the ‘cavern’, an arbitrary constraint that forced players to make weirdly convoluted moves in the tight space.
- Secondly, the strategic aspect was far from ideal: the choices were simple to make, and there was little tension since you knew from the start you’d reach the goal (the cavern) and collect the clues easily. So it didn’t feel like any of your actions mattered.
- And finally, the initial promise felt disappointing. You were indeed drawing a map & finding a hidden treasure, but this aspect was cluttered with many more elements that stole the spotlight away and distracted the players.
Still, this first playtest was a success. It did prove the game potential and highlighted the areas that needed improvement.
There is nothing worse than a game in the making that leaves players with such a ‘meh’ feeling that they don’t even know what feedback to give to improve it. I have a direction to continue improving, but the road to iteration is still full of twists & turns, which I continue describing in the next devlog.
If you found this article interesting, please follow me to help me grow. At the time of writing, I had 88 followers.
