Kids on Brooms is a ruleslite tabletop roleplaying game (TTRPG) where you’re definitely not playing Harry Potter. I mean, sure, your characters are students at a magical school kept secret from the world of normies, and you have classes like Charms and Potions and Herbology, but for legal reasons please don’t call it a Harry Potter Game.
My DnD group was taking a break to give Kids on Brooms a spin. In one scene my character Chunk was cornered by a pair of school bullies who wanted to copy his homework. I decided Chunk panicked, nervously shoved a magical toffee in his mouth, and was transformed into a liger in the middle of the school. Chaos ensued as Chunk in liger form, eager for revenge, tore through the school in pursuit of the terrified bullies.
When my group sat down to play that night, no one could have predicted something like this would happen. There was no reason to assume I wouldn’t have used any of my character’s abilities to get myself out of the situation, that instead I would use a rare single-use item in a low stakes situation, and after all that there was only a 1-in-8 chance that Chunk would turn into a liger.
Ultimately, you play TTRPGs for these moments where mechanics and player imagination collide to create completely unique and novel story beats. The magic is in the players’ ability to do anything they can imagine. The systems are elastic—they stretch and bend around what players want to do and give a framework to make quick-and-dirty mechanics for any hypothetical action. The quick-and-dirty resolutions systems available work just fine for one-off encounters, but if it’s something you’re going to be stuck with you’ll want something more fleshed out and developed. This means the dungeon master or storyteller is doomed to dip into game design to support where the players choose to go.
For me, it was when my group of 16-year-old murderhobo friends commandeered a ship and decided to take to the high seas. None of my books described mechanics for ship-to-ship combat, just a barebones table about relative speeds and crew sizes for longboats and galleys and galleons. I was expecting players to stick to the ship and need to have a consistent way for them to do battle on a ship. So I set about coming up with a system for turn speeds and hull damage and ram attacks.
I never used that naval combat system I devised, because my players predictably got off the ship at the beginning of the very next session. Which is probably for the best, because I’m pretty sure it wasn’t very good. But it was my first real attempt at game design and I’m proud of it for that.
Designing for TTRPGS games is forgiving. Did you forget to specify how quickly players can change their weapons? No big deal, that’s what the DM is for! Do you not have enough page count to clarify how much a character can say on their turn using a “quick” action? Again, that’s why you have a DM. No one expects the TTRPG designer to anticipate every possible rules conflict—a big part of a DM’s job is to act as a stand-in for the designer and fill in the gaps. Rules are just guidelines, the books often say, and the story should always rule the day. In practice, the rules are like swiss cheese that players often slip through, forcing the DM to fill in the gaps. As long as there’s enough of an engine built for a DM to drive a story, it doesn’t really matter. The game design feels successful because individual games are successful.
I had a rude awakening when I started designing board games with The Misplay. I assumed boardgame design would be easier than TTRPG design, mostly because the rulebooks are so much smaller. That was… a naive assumption. Board game design has to be airtight. Every action a player can take has to be defined. If players can board a ship and sail it away, there sure as hell better be a system defining ship speed and cargo capacity ready to go. Board games are like mechanical clocks, full of independent cogs and springs and pins that have to work together in sync to move the hands. If something’s not tuned properly, it just won’t work.
The Dating Game and Nightmare Smashers worked… kind of. Both games lurched forward in fits and starts, and I was constantly having to clarify rules on the fly that I didn’t realize I needed to clarify. I couldn’t rely on narrative to gloss over my design failures the way I could when I’d developed TTRPG systems.
I created Depths to be playtested, not played. I was desperate to figure out how to make something that worked, and so I needed to be able to playtest it completely on my own. There were no player hands, no secret ambitions or victory conditions. Unfortunately, neither was there surprise or anticipation or excitement. But I didn’t really care at that point. Did I mention I wanted to make something that worked? I was willing to sacrifice a fun player experience in exchange for a functional player experience. If that meant I played a boring game against myself, then I was going to make a boring game against myself.
Depths is as close to working as anything I’ve made yet. Making a game based entirely on information simultaneously available to all players made it possible to feel what the player experience is like and find those friction points. I could make changes, iterate, test again, and find more problems all by myself. I’ve scrapped and rewritten every card multiple times by now. Are there still friction points? Absolutely. Is it a game that I want to play yet? Not quite.
I know what makes games feel fun to me. I want players to be as surprised as I was when Chunk ate that toffee and turned into a liger. Now that I have something that’s starting to work, I feel like I can now think about what I might add to make Depths fun. Maybe someday, I’ll learn to do both at the same time.
— Peter