Part 2 of a discussion of game design decisions made for BuildDown. Part 1 is here.
BuildDown is a simple, action-oriented game, which made it somewhat challenging to figure out how to monetize. There are no levels, so I can’t exactly sell more content. The mechanics are not friendly to puzzles to force such a content model, either. Instead, I had to weigh the various popular approaches to see which played best to the strengths of the game.
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.