Pecking Order is a social deduction game, so we are developing it in a highly collaborative way. I had some core ideas nailed down, but was struggling to realize those ideas in a prototype. I brought in a group of friends who are a mix of experienced designers/testers, and game fans who have zero design experience.
Read MoreWe have spent 3+ years developing our first board game Beast Master. Part of the reason it has taken so long is that we fumbled around in the dark for the first couple years designing without any constraints or any particular goal in mind. A cool, divergent idea would come up and we had no grounds to say, “no, that’s too far fetched,” or, “that’s simply not what we’re aiming for here.” We ended up accidentally re-designing it into a completely different game more than once. We eventually landed on a game that both of us are proud of, but we spent lots of unnecessary time banging our heads against the wall.
Since then, we’ve started explicitly writing up two things that shape the development of our games: Spine and Constraints. These crucially important concepts provide a huge amount of clarity and focus for us, and give shape projects before we even start prototyping them.
Read MoreWe’ve been trying out different ways to prototype cards for years, and I wanted to quickly share the best thing we’ve found. When we prototype and test, we need to create and print components in a way that is:
Fast
Cheap
Presentable (if not beautiful)
Easy to update
There are obvious tradeoffs between these four requirements. Scribbling on note cards is fast and cheap, but it looks terrible and updating cards is tedious and time-consuming. Printing text on printer paper and taping it to old business cards looks slightly better, but it’s still amateurish and takes too long to update. The key to a great process is that we need to be able to make small changes to existing cards, and create wholly new cards very rapidly without sacrificing presentation or spending a lot of money.
Read MoreIn the first half of 2018, we went from index card cutouts to a fully fledged v1 of Odra (a working title that we quickly dismissed as wannabe sci-fi). We knew that there were problems with the game, but we lacked a systematic way to diagnose those problems. One big issue we ran into was that we were fine tuning every part of the game simultaneously. Games are finicky systems. Each part of it is hydraulically linked to all the other parts of it. Small adjustments to the rules can result in huge changes in player experience. On a few occasions we changed 3 or 4 little things at once and managed to completely break the game.
This blog post is about the syntax we used to audit our game systematically, evaluate each part of the game independently, identify what needed work, and ultimately allow us to rebuild the game around its best parts.
Read MoreWalter and I have been “designing games” in our mind palace for years. We thought up a puzzle-based competitive iOS game, a Jackbox-esque multi-screen heist game, and an epic superhero role-based strategy board game. We talked on Skype and imagined exciting, novel games that had beginnings, middles, and ends. They were sort of like un-playable, puffed up thought experiments. And because they weren’t real yet, they sounded elegant, fair, and perfectly balanced.
We had misplaced confidence in the quality of our ideas, because no player had yet given us that blank stare that says, “this rule makes no sense and there’s a typo on the card… and by the way this isn’t fun.” They needed rigorous editing and brutal feedback and fresh eyes. They needed to be tested.
Read More
