Michael here, back with another weekly dose of Earthdawn. It’s been nearly a month since GenCon, so I wanted to first take this opportunity to thank everyone who made it out to our tables. A fair amount of effort goes into adventure development and having fans show up to play them makes every bit of it worthwhile. I ran three different Legends of Barsaive adventures, each of which went extremely well.
The most rewarding session for me was Part 8, “Brain Scratch”, which has gone through several iterations over the past year. The tweaks and balances I’ve incorporated into this adventure from past play-throughs resulted in the session running smoother than ever.
One of the major components of Part 8 is what I’d like to discuss today: puzzles.
Crafting puzzles that fit into a tabletop RPG setting can be tricky. As the puzzle maker, you want the players to think about what to do and keep trying different things until they understand what the clues were telling them. You want to present something that is not immediately obvious, but at the same time not so cryptic nobody else can figure it out. If the puzzle is too easy, the player doesn’t get as great of a sense of accomplishment as they would have if they struggled to solve it. The other extreme is creating something too difficult, which can frustrate a player to the point they are no longer having fun. Finding the balance between these extremes takes time, but once you do it’s one of the most fun things to run at a table.
For Part 8 of the Legends of Barsaive series, I created a set of six different puzzles the players could encounter. Only one of these, the simplest one, remained unchanged throughout the playtesting process. Four of the others required one or two major adjustments to the information presented, in order to put players on the correct path in a reasonable amount of time. The final puzzle was more or less a complete redo. Since the original version of this puzzle no longer appears in the adventure, I thought I would explain how it was supposed to work and discuss what issues were encountered when it hit the first table.
The puzzle’s original premise was to direct three streams of colored smoke from one end of a room to the other. These streams would activate color coded panels, opening a magical lock the players needed to get past. The room contained fans that could be positioned around the room, allowing the players to direct the smoke in different directions. The trick was that, if the streams ever combined, they would mix into a different color and could no longer activate the panels. To make the solution more complicated, the panels were in a different order from the smoke sources. Crossover ducts found in the room could be used to prevent the streams from mixing.
While this sounds like an interesting idea, in practice it was far too complicated to fill its intended purpose. To sufficiently obscure the solution, I used roughly twelve direction changes and four crossovers. This made configuring the solution too difficult for a group of six people to collaborate on. Scaling back the complexity, however, made it a bit too easy to solve (at least in my opinion). In either case, only one or two people would participate in this half-hour long section of the module, which just seemed too boring to keep.
The next issue was tracing out the direction of smoke when players positioned the fans. Writing and erasing three differently colored lines was cumbersome to keep track of. I don’t remember how I intended to convey the information, but I ended up laying down pencils to indicate which direction each stream was flowing and a marker cap to indicate the color. This caused problems because it obscured the slots shown on my handout of where the fans were able to be positioned. The central premise of the puzzle was pathing the smoke correctly, so the fact I was struggling to communicate this to the players pointed out a huge flaw.
After the first run through, it was clear most of the players did not have fun during this section, conveying information to them was difficult, and the puzzle took way more time to complete than I wanted. While it is possible the solution could have been refined into a usable state, I believe my decision to redesign this puzzle was the correct one. I ended up scaling back the concept to its simplest form. I won’t spoil the new puzzle for anyone who hasn’t played the adventure, but I was able to turn a cumbersome and frustrating puzzle into a more streamlined and consistent challenge.
I’d like to leave you with a bit of advice on utilizing puzzles in your games. The number one most important thing is to include a method of positive reinforcement for when players are on the right track. A simple click or ding (or other bit of obvious feedback) can let them know they’re making progress, and is the best way I’ve found to keep a group focused in the intended direction.
Second, try to give in-character hints or pushes if it seems like they’re way off the mark. Using a Perception test to direct a character towards an object or area needed to solve the puzzle is a good way to help without giving away the entire solution.
Finally, don’t be afraid to go with something that is simple. Just because it seems simple to you does not mean it will be easy for people without the solution to solve.
That’s all for now. Until next time, thanks for reading!