BuildDown, Redesigned

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; 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 micro-tasks (“mindless” repetitive actions, like popping bubble wrap), with the basic human propensity for organizing or tidying up: creating order from chaos, satisfaction with a job well-done, and things fitting perfectly into things.

But repetition breeds familiarity, and familiarity breeds contempt.

These simplistic actions are not in themselves challenging. As the pace of the game quickens over time, keeping up with them can be a skillful endeavor, but not really a strategic one. They need to be balanced by an opposing force – something for the player to make decisions about – or they become 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. With little new to learn, the game was easy to master and forget.

I’d also like to digress for a moment to talk about the game’s difficulty curve. Constantly-increasing difficulty is almost as core to BuildDown as merging blocks. It provides both a necessary element of challenge, as well as the impetus to draw an otherwise endless game to a close. But on the other hand, it’s incredibly stressful, which can be off-putting. Nobody likes to be overwhelmed and defeated. This stress can be mitigated, but it requires a periodic reprieve – an ebb to the game’s flow. Pause time provided this to a limited extent, however imperfectly. First, pause time provided its own stressor with the rapid-fire challenge in maximizing score production. Second, as soon as it ended, the player was right back in the weeds, fighting for their life. The only break came with a side of unproductive guilt; not an ideal solution! I knew even at the time that I wanted a way to make the difficulty curve more sinusoidal, perhaps by providing a mechanism to go back a level in difficulty, instead of exclusively and relentlessly forward. The idea didn’t fit well into the limited set of interactions possible in the game at the time, but it’s one I would revisit in time.

After getting the game running on this new platform, my “first 100 days” trajectory was clear: I had to repeal and replace pause time.

Enter powerups. Now, I don’t take credit for inventing the idea of powerups. Rather, the epiphany in BuildDown is in how the player interacts with them. Tapping a pair of blocks merges them, but to activate a powerup, it must be held. Everything about the game is geared toward moving forward as rapidly as possible; powerups ask, what if we don’t? Suddenly, the moment-to-moment choice becomes much more meaningful. Would we trade a moment of that progress, perhaps risking calamity, for some greater reward?

To add another layer of consideration, merging a powerup block into a white or gray state lowers its activation time. These fast-activating powerups become incredibly valuable in the late game, which means the player might end up spending energy plotting ways not to merge them. Additionally, powerups can activate one another, which allows for combos to be arranged by lining up powerups in opportune ways. With powerups, a desert of decisions has become a fertile field.

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 level by one. In this way, unused powerups can be “spent” on a reprieve in difficulty. This mechanism allows the player to forgo short-term points for breathing room and potential future progress. It’s a relatively minor spin that ends up making a big difference in the pace of the game and putting even more weight on every decision of how to interact with powerups.

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.