What Went Right

We believed in ourselves. During development, we always send the game to a couple of external reviewers, and also for evaluation inside the company. At this point, we usually get some good reviews and useful feedback that we use to improve the games. However, with Tower Bloxx, we got a very mixed response. But we had a great gut feeling about this, so we decided to march on nonetheless and trust our own design views.

Prototyping. As we discussed earlier, the original idea came from a mock-up image which was later turned into a prototype, which led to our core mechanics. After production started, we also needed something to fill the long-term gameplay demand, so we had several ideas of how the rules of the city mode could work, and we prototyped those using both pen-and-paper and Excel. In this way, we could test and tweak our ideas without the need for programming time, which helped us getting the game done faster.

Iterations with core game mechanics. Even though we had a working prototype which was fun to play, we weren’t fully satisfied with the overall gameplay, because it wasn’t deep enough. After about ten minutes playing it, people started asking what else is there to do. At this point, one could think that the addtional city puzzle mode was the answer for this problem, but the fact is that if we’d have gone that way, it would only have dealt with the side effects of the underlying problem, which in this case was that the block dropping and tower hovering part should be more appealing. Our goal was to make the core game mechanics super-fun so that it alone could have kept players playing the game over and over again.

To make this happen, we put a senior designer and a senior programmer to work together on the core game physics. They were sitting next to each other and having constant communication during the whole iteration time. The total iteration of the core mechanics took three weeks, with one iteration cycle taking something from half an hour to three hours. When a new version was built, the designer would play it and give instant feedback on the physics: what was not right and how the next iteration should feel. If the game mechanics needed any additional graphics or change to the existing ones to make it more fun, this was always put on the fast-track, getting in front of all the other tasks the art team would have had on its table.

The lead designer also took part in testing the core mechanics a couple of times a week. This is always important, since many times people working very closely to the things they love can get blinded to errors, or end up trying to tune and tweak something which will never work. This working method allowed us to get the core game mechanics to the point where we wanted it to be, and enabled us to more easily drop some features from the core which were loved by team members but that in the end wouldn’t have worked so nicely together. However effective, this approach requires some extra attention when planning the project; we will discuss more of this in the “What went wrong” section.

Gameplay value. Even though the action mode at its core is pretty simple, we managed to make it fun and more varied by adding some details, like stronger winds as you go up, roofs and some visual easter eggs. This, coupled with the long-term challenge of the city mode, gave the game a great span of gameplay. Building a tower is satisfying and challenging on its own, which is good for a quick session on the subway, but the city mode adds an extra layer of complexity that players can solve and experience over longer periods of time.

Porting the fun to the low-end phones. Usually it’s a huge challenge to make a game that is fun both in high- and low-end phones. Tiny screens and slow performance usually force developers to compromise on the gameplay experience, especially in action games. In Tower Bloxx, we took lots of care with the physics and the collision detection of the action mode to ensure that it would run well in limited environments, and we also made many graphical elements using code (such as the city background), which not only saves precious space but also makes it very easy to scale to different screen sizes. We also planned the puzzle element with this in mind as well. As a result, it was an easy game to port, and the game runs as well on a low-end phone as it does on a top-of-the-line one.