Gamasutra - Feature - "Postmortem: Digital Chocolate's Tower Bloxx"
It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.

By Mikko Kodisoja
[Author's Bio]

and Jeferson Valadares
[Author's Bio]
Gamasutra
July 7, 2006

 

Postmortem: Digital Chocolate's Tower Bloxx

Introduction
What Went Right
What Went Wrong
Final Thoughts

 


Change Login/Pwd
Post A Job
Post A Project
Post Resume
Post An Event
Post A Contractor
Post A Product
Write An Article
Get In Art Gallery
Submit News
 


 


Latest Letters to the Editor:
Perpetual Layoffs by Alexander Brandon [09.21.2007]

Casual friendliness in MMO's by Colby Poulson [09.20.2007]

Scrum deals and 'What is Scrum?' by Tom Plunket [08.29.2007]


[Submit Letter]

[View All...]
  



Upcoming Events:
Women In Games Conference
Coventry, United Kingdom
09.10.08

3rd ACM International Conference on Digital Interactive Media in Entertainment and Arts - DIMEA 2008
Athens, Greece
09.10.08

GDC Austin
Austin, United States
09.15.08

Game Career Seminar
Austin, United States
09.17.08

Games Convention Asia 2008
, Singapore
09.18.08

[Submit Event]
[View All...]
 


[Enter Forums...]

Note: Discussion forums for Gamasutra are hosted by the IGDA, which is free to join.
 


Features

Postmortem: Digital Chocolate's Tower Bloxx

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?

Final Thoughts

 


join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2005 CMP Media LLC

privacy policy
| terms of service