Putting the Cycle in Development
This week I'll be talking about one of the most important parts of developing a game - iterating your design.
There's a quote that I've heard frequently, and many of you may recognize it from playing the Civilization games:
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
- Antoine de Saint-Exupery
This saying was especially important during my time as an engineer. Adding features to a design was the easy part. Figuring out how few features you needed to still get the job done safely was the challenge. Designing games ends up being very similar - it's very easy to keep adding ideas and layers to your game, but it is frustrating removing them and keeping a balanced and fun game.
We designed Shipload o'Gold initially with no consideration of the manufacturing aspects of the game. In other words, we weren't fixing ourselves to a set limit on the number of cards in the game. In the initial iterations, we took the easy route and continued to add to the number of different Weather and Action cards in their respective decks. While with each iteration the total number of cards continued to grow, we were eliminating ideas that weren't fitting well in the game.
There were also some little "tricks" that we decided to move away from - things like there being one less "cancel" card than the thing it would cancel, in favor of equal amounts. We also moved away from a more complicated concept that we borrowed from Magic - the idea of the "stack." We initially wanted to set up the game thinking that multiple people would be playing multiple Action cards per turn, and we wanted to write the rules for how to resolve them in the "last in-first out" order. Over the course of multiple playtest sessions, we were finding that those issues never came up, so we just removed that from the rules in order to simplify the language.
In the end, we came up with a design we felt could still be added to and remain balanced, but couldn't have anything removed without upsetting the balance of the game flow.
With Marshall's design of Stir Fry 18, and the design constraint of being only 18 cards, the iterations on design weren't really to trim things down as there was a fixed amount of cards in the game. In this case, the iteration was done to determine which point values led to the ideal game time we were looking for, along with things like how you could draw additional cards on your turn, or how the intricacies of the bluffing mechanic worked. Everything ended up being tied into how quickly you could accumulate points which directly affected the length of the game. In that case, there wasn't really any removal, but there was still iteration.
In general, when designing a game, you'll want to make sure you play it a lot, with a lot of different people. You'll know what needs to be fixed, and hopefully you'll get honest feedback as well. Always keep track of your changes. You may find that one thing fixed means another thing is broken, but you could use a previous idea to keep things balanced. You never know when an old idea may help you out of a tough situation.