Innovate,
Iterate,
Repeat:
Finding Your Game Through
Iterative Design
This next chapter in our blog series takes a look at iterative design and how it was applied to turn Hexopolis from an early prototype into the game you know and love today. We hope you enjoy it.
What’s iterative design?
Making games is an iterative process. Rather than a static concept where the end product is identical to the original idea, games are fluid and subject to change over the course of their development. The process of bringing a game from start to finish is full of unexpected twists and bends, and iterative design embraces this axiom of development by allowing for prototypes to be created and then altered or scrapped just as quickly on a journey to find the game’s true nature. By creating more opportunities for failure and success and allowing them to happen earlier in the development process, you allow your creation to become the game it was meant to be rather than the game you wanted to make.
This blog article walks through the development of Hexopolis to break down how it was conceived, how it evolved, and the role that iterative design played in making it the game it is today.
PROTOTYPE, SCRAP, REPEAT
The most effective way to start iteratively designing your game is to come up with a short list of simple ideas for you to branch from. Before Hexopolis’ first prototype was made, it was just one out of a handful of ideas, including one where players excavated and mounted dinosaur fossils and another in which they constructed and optimized a transportation system for a growing city over the course of a round. The dinosaur concept actually made it into the paper prototyping phase, but this revealed it to be rigid, boring, and not worth pursuing when compared to the other ideas. Being honest with yourself in this early phase of iteration will save you loads of time and headaches in the future, so don’t be afraid to start over from scratch until you have something you’re confident about and find promising. If you don’t feel an urge to engage with your own idea, it’s unlikely players will either.
After the previous prototype was scrapped in its earliest phase, attention was shifted to other ideas on the list and development entered another stage of brainstorming. For a while I’d been interested in designing a game in which players would build in the same space in a struggle for domination of that space and be left at the end of the round with something elegant and aesthetically intriguing that they could display on their shelf afterwards. I therefore shifted my attention to integrating the building concept within a math context, where players would draw numbers and operators and attempt to form the longest formulas possible. This would create a grid that both players would continue building and adding to over the course of the round. This idea was more abstract, malleable, easier to iterate upon, and the seed that would eventually grow to become Hexopolis. One of the first rules of iterative design is to have a first playable prototype as soon as possible, so I took out my barely used writing notebook, a pair of scissors, and got to work.
Image: A raw, unfiltered image of the earliest prototype of Hexopolis.
OBSERVE
Iterative design hinges on a feedback loop of using observations from play-testing to determine what adjustments must be made to the game. Once I had a playable prototype that intrigued both play-testers and myself enough to play a few rounds, I was able to begin drawing those observations and responding accordingly. This is one area where the abstract and minimalist aspects of the prototype were a big help, because they allowed for a free-flowing design process without too many rules or limitations to prevent easily making necessary changes. There was more room for misinterpretation from players, and some of those mistakes made for the most intriguing bits of gameplay that would hook players into playing one last round, and then another and another.
For example, the ambiguity of the orientation of the tiles often created confusion over which ones were 6s and which ones were 9s. So a player holding the tiles 3, 3, and 6 could use them to form the expression 3 + 3 = 6, but rotating the 6 upside-down into a 9 also allowed them to make the expression 3 x 3 = 9. These occurrences could have been easily removed by adding lines under the numbers to make their orientation explicit, but having large parts of the first prototype be open to interpretation and leaving opportunities for ambiguous scenarios revealed intriguing threads such as this one, and I was interested in pulling them to see how far they’d unravel. Reflecting on the observations made from the play-tests inspired theories concerning what made these elements so intriguing in the first place and how they could be explored more fully. In the case of this particular example, I became aware that I wanted a game that was open-ended and gave players room to experiment, so I directed my efforts towards prioritizing these qualities in the next phase of iteration. The game had asked for it, and my job as the designer was to follow it where it wanted to go.
iTERATion of an Iteration of an Iteration
A key part of iterative design is not only knowing which direction you want to move your game towards, but also being able to quickly determine what you want to move it away from. It’s easier to remove unwanted design elements earlier in the process rather than later, because the longer you wait, the more different mechanics become interlocked and hold more implications over one another.
The description in this blog of Hexopolis’ first iteration as “math scrabble” is ironic, because it’s a term that players gave it and one that I pushed back against early on. I rejected it because I felt that the game, while similar to Scrabble in appearance, had a distinct feeling and pacing to it. I wanted to distance the game from this comparison as quickly as possible, and I realized that I wasn’t particularly attached to the math aspect, since what made the game captivating wasn’t the creation of simple formulas, but rather the building of a structure through an array of flexible means.
If you’re enjoying this article so far, sign up for our newsletter to get notified of new content, or even better, share it with a friend who you think might be interested!
I therefore decided to change the look of the game and move the spotlight away from the math component and shine it on the building mechanics instead. I thought that open-endedness could be obtained by abstracting the game one step further, and I decided to do so by representing the numbers as units of some sort that players could group however they wanted. For a couple of days, I played around with a few ideas in my head which included first representing the numbers as marbles, then as individual tiles placed adjacently along an axis. I went with the idea of individual tiles and decided to flip that axis upwards so as to accommodate for space on the board and provide a more intriguing and unique look to the structure that players were building, all with the little voice in my head saying “Let’s see Scrabble do that ” as my driving motivation. This vertical structure incidentally merged with an obsession I’d had with the overhead bridges typically found in various representations of cyberpunk cities. I realized that with the right shape, the mathematical operators could be placed not just on the ground level of the board, but also suspended in between the vertical tower-like structures, and I made an internal note to explore this in future iterations.
It was all function-over-form from this point on. Because the game was taking a 3D shape, notebook paper was no longer a suitable medium. After sketching a few designs, I took the one that made the most sense, threw it into Adobe Illustrator, and cut the shape out of a piece of wood with a laser. The decision to go with a hexagon for the shape of the game pieces was the result of striking a balance between two options. On one side, there was a square, 4-sided piece that would bring the game aesthetic a lot closer to chess, checkers, and other games that players were already familiar with. On the other side was a piece with 8 or more sides that would risk yielding a cluttered and suffocated-looking board. 6 sides would satisfy my objectives to open up more options for players to experiment with as well as making them stop visualizing the board as a “grid” and instead encouraging them to think of it as something else entirely. The result was an iteration that probably looks a lot more familiar to most Hexopolis players today:
Image: An iteration of Hexopolis when it had moved into the third dimension but still used arithmetic logic.
Extreme Ways
The game was finally taking shape. It was becoming something unique, engaging, and intriguing. This last iteration presented new challenges, however, especially in the game’s pacing. Because the game was still taking place within a math context and its architecture was determined by arithmetic logic, it became increasingly difficult over the course of a round to make new placements and still have the expressions hold true as they became increasingly intersected with one another. As a result, players would resort to reliable but bland strategies, such as taking the expression 2 + 1 = 3 and expanding it to 2 + 1 = 3 x 1. Furthermore, I still hadn’t decided on the rules for the endgame, and I wasn’t satisfied with having players compete on the basis of who was able to form the longest expressions. The math component had run its course, and I felt that it was time to transplant the building mechanics into a new iteration.
After getting nowhere with the problem for a few days, I decided one night to do a one-off play-test with a friend which ditched the math context altogether. The vertical component of the board added intrigue by giving the game a cityscape aesthetic, and it felt like the purpose of such a board was to have players move across it. The minus signs were lines that looked like paths for traversing, and multiplication and addition crosses looked like obstacles in the way of that traversal. So for this play-test I picked up a bottle-cap and a coin that were lying around the table to use them as player chips and created the current-day rules for winning and losing a game on the spot. By the end of the round I’d decided to abandon all math mechanics and call the game Hexopolis.
Tying It All Together
With most of the game’s elements having fallen into place, it was time to lock things in and bring the aesthetic home. Continuing to follow the function-over-form approach, a few changes were made to the shape and look of the game so as to support its logic. In order to fully divorce Hexopolis from its math roots, the arithmetic operators were abstracted into symbols that were intuitive and unique to the game. In addition to this, wooden chips were made that fit the dimensions and look of the rest of the game pieces. Finally, the shape of the cells was slightly modified so that they would have a cavity on top into which the new player chips would fall into place.
The current version of the game could now be play-tested more aggressively, followed by a slight fine-tuning and modification of the rules. For instance, the walls required to surround a player for one of the endgame conditions was changed from 3 to 4 in order to make gameplay more strategic and less volatile. I also experimented with adapting the game to support up to 4 players but ultimately scrapped this when it became clear that this would be detrimental to the game’s strategy.
The End
Reaching a stable set of rules is hardly the end of the iterative process for most games. Hexopolis later underwent several iterations for its box design and presentation. Nonetheless, an important part of the iterative process is knowing when to end it. Iteration is driven by problems that need rectifying, but no game is perfect, and finding a balance between perfectionism and practicality is one of the greatest skills you can have if you ever want to bring your creation into the hands of players.
Your design process starts off with a seed of an idea for the experience you want your game to provide. While iterative design can alter this objective by revealing intriguing paths to explore along the way, the driving force of development consists of regularly evaluating whether your current version gives players the experience that you intend for them to have. Once it does, you know you’ve got something worthwhile on your hands. Until then, iterate, iterate, and iterate again.
Thanks for reading our blog article! We hope you enjoyed it and look forward to catching up with you on our next blog post a month from now.
Sincerely,
The Hexopolis Team