What Went Wrong

Prototyping graphical UI elements. Even though we did prototype the core game play and the rules of the city mode, we didn’t pay too much attention on how the actions like placing the building into the city would work graphically. Our artists made many of animation frames and sprites but we didn’t test them before (for example, using Flash) nor did we do any GIF-animations to see how they would work together on top of the cityscape.

This cost us too much time as our city mode programmer had to implement the graphics and iterate the code multiple times before the rest of the team was happy with the results, and all this time was taken away from implementing more features into the city mode. In the end we had to drop many nice-to-have features from the city mode and from the game flow due to this.

Scheduling. The project was scheduled as a project where you have a good idea of what you were doing. This was not the first time Sumea worked on one-button game mechanics: two years ago we developed a game called Johnny Crash and its sequel, Johnny Crash Does Texas. Before the production of Tower Bloxx we carefully went through our internal postmortems of those projects trying to internalize all the learnings from them.

This worked well, and we managed to dodge the major problems of both Johnny Crashes. But now, looking back, we can say that Johnny Crash was not the best case to base your planning from a producer’s perspective, especially because in that case we got the tuning right fairly quickly.

Tower Bloxx was an innovative title and still we treated and scheduled it like it was a sequel or a game where you can have at least a good guess on how much each task will take. For example, the iteration cycles of tuning the tower physics were not initially forecasted to be as long as they ended up being. Another example is that initially we planned the city mode to be just a graphical high score table, so our estimates were based on that. When we decided to change it, it put the schedule in risk, though in the end we did manage to keep the schedule.

Producer was wearing two hats. In our projects we have a lead designer who is responsible for the design of the game and a producer who takes care of the whole project. In this particular project, the same person was the Producer and the Lead designer, which created some conflicts within the project. As a designer, you want to tweak the game to perfection, and as a producer you want to do it as on time/budget as possible.

This is a healthy tension in any game, but the lines are a bit blurred when you have the same person making both calls. This can also be very frustrating to the team, who might come up with a new design solution and they can’t know which hat the producer/lead designer was wearing when deciding to drop a feature.

3D version could be better. Although we did get a 3D version of the game out at the same time and in a cost-effective manner as we had planned, we only managed to do it by making it as similar as possible with the 2D one. We had a few other cool features planned, but implementing those would require time we ended up not having.

Naming. One of the hardest things in the mobile landscape when you are working on unlicensed titles is the name of the title. Our industry has the smallest advertisement window in the world, meaning that in most cases the user will buy the game while browsing a WAP page and seeing only a list of names, without any screenshots or extra information.

So in many cases the end-user has to make a decision based only on the name of the game. As a result, the name has to be descriptive and appealing on its own and also when compared against games with licenses. This problem gets even worse when you’re trying to come up with something new – how do you describe a game where you pile floors up to build towers that you want to place in a city so you can attract people to it?