Full disclosure before I write this article:
- I don’t believe I’m done with the game by any means, so calling this a retro isn’t completely accurate.
- Doing this is tantamount to explaining just how bad a game designer I am and is ultimately rather difficult to do.
3 months ago I took a break working on the airplane (board) game I had developed about managing airplanes at an airport. What led me to start the game, and why did I ultimately fail the project?
For those of you who are curious, the tl;dr is:
- Unclear definition around the project goals, i.e. what the central goals and mechanics of the projects would be?
- Poor testing structure, unclear goals around each test run and unstructured feedback from testers.
Going into the project, I had two opposing goals. One was a mechanical idea of using dice and movement as the main mechanic. The other main goal was to make this a game about airplanes.
Sub-Problem #1: I didn’t define what “using dice as the main mechanic” means.
When I started prototyping the game I had two mechanics that I was trying to mash together. The first was dice as game piece which was inspired by Quantum. In Quantum each ship was represented by a die with a number of pips. I found the mechanic of relating pips to strength inversely. So I copied it and made each of the planes represented by dice. But I made a small twist, making planes collection of dice. And I immediately made a jump to dice pips represent both plane “fuel” and the planes representative value.
The second game that I used for inspiration was Castles of Burgundy. Castles of Burgundy had a really awesome mechanism for shaping player actions. Players would role two dice, and select and place tiles based on the number of pips on their dice. I found it really exciting because it shaped the player’s turns in a broad way (they were limited by the types of actions they could do) but without making it too luck determined.
So what did I do? I gave players dice and had them role them to determine what planes the could grab. This confirmed my underlying assumption that the basic mechanics of Castles of Burgundy are fun. (Shocking that a game on Board Game Geek’s top 100 has a fun underlying mechanic.)
Mashing these two mechanics together basically resulted in a game where players who rolled higher won the game faster. What mistake did I make and how can I learn from it? I made an amateur mistake and combined two interesting mechanics instead of focusing on the underlying goals of the game. Games are basically series of puzzles where each turn (or interaction), presents an interesting set of choices for the players to overcome.
If my goal was to create a game based on an interesting mechanic I should have started with the choices that a player is presented on every turn and how they use those mechanics to further their goals. But my initial goal with the game wasn’t to combine a couple of interesting mechanics, my goal was to explore the idea of landing airplanes in an interesting way and I was sidetracked by the shiny object of cool game mechanics I could replicate.
Sub-Problem #2: I had a theme that I wanted to use, but I couldn’t commit to it.
The other option, would have been to focus on the core challenges of landing planes (at least as I observe them):
- Making sure planes don’t collide.
- Making sure planes don’t run out of fuel.
- Making sure planes land on time.
Each of these (or all of them) would have presented an interesting challenge for me as a designer to grapple with. But I didn’t, instead I attempted to use the mechanics that I had become smitten with, and slap the theme on them, meeting somewhere in the middle. This doesn’t work.
Pick a starting point, commit to it, and relentlessly prune everything else
Starting with an interesting mechanic and adding a theme that grows from it, or starting with an interesting theme and developing mechanics to handle the challenges of that theme. Trying to both of those things at once, however, simply will not work.
Poor Testing Structure
I ran somewhere between four and eight playtests on the game, and each time I had new ideas which led in a new direction that fundamentally changed what I wanted to accomplish with the game. The game started out as a weird amalgamation of Quantum and Castles of Burgundy and ended up as multiplayer Candy Crush. While the Candy Crush mechanic was actually incredibly interesting but did not end up at that the place I wanted. The airplane theme was almost entirely lost (or stapled on).
Each time we playtested I would get a lot of honest, well meaning feedback about how the game could be improved and what could could make it better. Each time I would go into a playtest trying to understand what was “fun” in the game. But the term fun was too generic. I shouldn’t have been trying to ask players what they found fun. Fun is a generic squishy term which is helpful in a broader context but not all that helpful when trying to develop a very specific board game. Fun on any given night might mean different things to the same person.
Define fun at the start, and work towards a better understanding of what it means
Instead, I should have defined what was fun about the game at the start, and then worked towards improving the definition and making the game match that definition more closely. Those definitions are things that I can measure the game against (or work towards measuring).
Onward and Upward
Moving forward to my next project, definitions and structure become the focal points. Instead of trying to “make a game” my goal is to create a functional design document that can help me progress from a concept or an idea to a final project, whether that’s a completed/published game or further exploration of a smaller concept. I’m quite positive that this is just the next step in my understanding of how games can be designed, developed and refined.