Part 1 of a discussion of game design decisions made for BuildDown. Part 2 is here.
One of the first projects I wanted to tackle on the road was to revisit BuildDown, the first game I ever released. I thought it would be relatively easy to rewrite in Unity and have access to the broader mobile market. But there was another reason I wanted to revisit it. The original was something I was proud of, but I always felt like I had left something on the table. Rebuilding it on a new platform was an opportunity to reinvent it, both in game design and software architecture, and to exercise and refine those muscles for future projects.
The basic premise of the game is to merge blocks of the same color into new blocks, which can in turn be merged until they reach an inert state and cannot be merged any further.
Those inert blocks must be lined up along the bottom row to make them disappear.
There’s something I find really compelling about this core mechanic. It combines the pleasure of addictive and soothing actions (like popping bubble wrap) with the basic desire for organizing or tidying up. Creating order from chaos, satisfaction with a job well-done, and things fitting perfectly into things.
But these simple actions are not challenging on their own. As the pace of the game quickens over time, keeping up with them can be a skillful endeavor, but not really a strategic one. It needs to be balanced by an opposing force – something for the player to make decisions about – or the whole thing becomes uninteresting very quickly.
For the previous iteration of the game, that opposing force was pause time. Players would earn pause time by merging blocks and, when when activated, earned a multiplier for every merge performed while time was stopped. That did indeed introduce an element of decision-making. Do I merge this now or later? And strategy as well, in arranging the board for maximum payoff while paused.
Unfortunately, it was too easy to min-max. The incentives rewarded one winning strategy: building up pause time while tediously arranging a board full of merge opportunities, then “springing the trap” and manically collapsing everything to rake in huge point scores.
Pretty satisfying to pull off the first time, pretty boring after the first hundred. Like the base ruleset, there is opportunity to improve on execution, but not necessarily method. The fact that there was really only one viable strategy made the illusion of choice short-lived.
After getting the game running in Unity, my “first 100 days” trajectory was clear: I had to repeal and replace pause time.
Enter powerups. Yup, I invented those! Okay, not really. But I added them to BuildDown in a way that requires the player to make a tradeoff. Tapping a pair of blocks merges them, but to activate a powerup, the players presses and holds it. Everything about the game is geared toward moving forward as rapidly as possible; powerups ask, “what if we don’t?” Would we risk everything not tapping for a few nail-biting seconds, if it meant some greater reward?
Additionally, merging a powerup block into a white or gray state lowers its activation time. These fast-activating powerups become more critical in the late game, which means the player might have to plot ways to keep them around. And what’s more, powerups can activate one another, which allows for combos to be arranged by lining them up in opportune ways.
Finally, there are the diamonds. Merge a powerup all the way and it becomes a diamond block. Diamond blocks cannot be activated; at this point, they’re inert. When diamond blocks are removed as part of a row though, they’re added to a tally. Collecting three drops the difficulty level by one. In this way, unused powerups can be “spent” on a reprieve. This, finally, gives the player some long-sought-after breathing room.
That wasn’t the end of the overhaul, though. BuildDown still needed a business model. I’ll get into the monetization strategy, and the higher-order reward loop that feeds into it, in the next post.
BuildDown is available now for iOS and Android.