Reflections on Making “City Roots,” a Systems Game

Although I’d heard about the 70/20/10 rule (keep 70% the same, make some modifications to 20%, and try something crazy with 10%), many of the struggles our team had while making City Roots likely would have, in hindsight, been much more manageable had we respected the principle from the onset of the project. There were a number of times we changed far too much about our game without directly addressing the root of certain issues (pun intended).

Through these challenges I’ve learned a lot more about how to iterate more effectively, though I’m by no means an expert yet. Here are some of my biggest takeaways:

• Focus on one thing at a time. Even if there are 5 different threads of potential changes you can make to your game, pick the most important one (or two) and playtest a little. I’m guessing that this is successful for similar reasons that A/B testing is so popular — the fewer new things to be tested, the easier it is to attribute improvements (or declines) to them.
• Know when to pick your battles. This becomes even more helpful as the game’s development picks up the pace and gets more exciting — and that’s understandable! Once the game is better established, it’s only natural for you to want to add the next “best thing” to it. At least, that was true in my case. However, trying too hard to get your ideas into the next iteration of the game is not always great for teamwork, nor development efficiency. Instead, I recommend my next tip.
• Keep your ideas flexible. From the start of our project, my brain was firing off “What if…?”s with very little prompting required. While that kind of energy can be helpful when a team is in a slump and not sure what to do next, it is not so helpful when everyone wants to contribute. By keeping your ideas flexible, it makes them more likely to be potential solutions to later issues the game runs into. For example, when we first began designing the board to City Roots, it reminded me of some of those “escape the blocks” games, like Rush Hour (example below). I wanted to slide the pieces around as part of my strategy, though at that early stage of development, tiles could only be replaced; not moved. To introduce a change like that would’ve derailed our train of thought (also pun intended). However, later in the project’s lifetime, we were searching for a mechanic to change the state of the board without directly changing the contents of the city, so moving tiles seemed like a more natural change. Because I was already thinking about moving tiles and saw a time that sort of change would be helpful, we implemented a fix quickly to our problem.

Rush Hour - ThinkFun's Play Online Game Library