chick chick BOOM Title
INTROWe are tons of bits, a tiny indie development studio from Frankfurt Germany and this is our postmortem on our debut game: chick chick BOOM for WiiWare.chick chick BOOM is about two teams of chicks, pitted in a deadly battle against each other: Five chicks on your side, five chicks on the other...BOOM! You need to beat the opposing team by throwing pianos, pink elephants, and sumo chicks or summon slimy giant jellyfish and real UFOs. At the same time you defend you teams by drawing lines in the arena. How well this works, depends on your use of ink, creativity and timing. If you would like to have this description as a rap, check out Jeff Gerstmann's NintenDownload X-press podcast from 15th Feb 2011 (4:48).WHAT WENT RIGHT?
tons of bits Team
1. The Teamtons of bits was founded by three people: Ivica, Bogac, and Steve. We knew each other already for some time. All of us passionate video game players from the cradle on, having the dream to make one day our own game. A common indie dev story so far.Finally, we got the opportunity in January 2008. Steve (3D Modeling) and Bogac (Graphics Design) did already run a company (extra toxic) making premium Flash Sites for big players of the game industry as we heard that Nintendo will be starting WiiWare soon. extra toxic applied for the license and as soon as it was there, Ivica (Programming) left everything else aside and joined the company. tons of bits was created.At that moment we had everything in one room which we needed to start our game project. A programmer, a graphics artist, a 3D modeler, and 3 game designers. 2. Code & Flash-Dummies as the Design DocumentGame Design Documents suffer from the same problems like every piece of documentation in any software engineering project out there: It easily gets out of sync with the project vision and the code (which is THE final design actually). As soon as you have one "broken window" in your documentation, not long and the whole "building" decays. For chick chick BOOM we tried to make a design document and update it regularly, but we ended up having the design document landing in the trashcan.Instead of that we focused on the following approach:a) Keep everything in the game configurable in a set of plain text files, which are read by the program on start-up.We strived for letting our configuration files look like pages from the design document. For instance, this is how the attack values were configured/documented:/*
min threshold perfectDamage
max thresholdDamage */
20.0 40.0 0.5 20.0 50.0 /* lightningAttackSettings */
30.0 40.0 0.5 30.0 45.0 /* weightDamageSettings */
10.0 16.0 0.5 10.0 20.0 /* plantDamageSettings */
...
Readable enough and pretty much straight forward with the advantage that there are no redundancies - one single source of information. It is maybe not that nice in the layout like an excel table, but the trouble you save, is worth this trade-off.
b) Describe features and interactions between these as simple flash-prototype
Bogac, our game/concept/graphics designer was skilled in Flash. When he had an idea how something had to look or how things in the game should behave or interact, he sketched this for the team in an interactive flash prototype. This was great, for two reasons: first, while sketching, he could already tweak on the feature itself saving lot of work in programming and 3d-modeling later. Second, the flash prototype was the best implementation reference the team could ever get. Once a feature got incorporated into the program, the flash prototype was thrown away, because it would have been too much effort to keep it in sync with the fine-tunings done directly in the program.
Flash Prototype for Attack Upgrades
Flash Prototype: Attack Upgrades3. Incremental Development and on-the-fly Tweak-abilityThe only long-term plan we had, was to finish the game one day which would be a pleasure to play. Beside this, we had no concrete plans which would go beyond one or two weeks. If we would have had a project manager, he would have committed suicide after few weeks on the project. In sum, it was an evolutionary process. We had lot of iterations like: plan, implement, test, accept/change/throw-away a portion or everything. We also went lot of wrong paths, trying stuff out, then returning back, and so on until we brought features in balance which we were satisfied with. Most people developing a game, will describe the process being like this.So what we've done right here was:a) No matter how much work something was: throw it away or redesign it if it doesn't feel right! Don't be afraid of that. If you're not radical enough here, you'll end up with work-arounds at some point. And work-arounds will make your game less fun.b) Make as much as possible configurable on-the-fly. A large part of game development is about tweaking the parameters. If you can do this without to recompile the program: a big win. And if you can do this on-the-fly while the game is running and directly observe the effect of the change: A HUGE WIN! This way, you can try more things out in less time and you make "tweakers" independent of the programming team, which will be in most cases under pressure and most probably will have the reflex to block change requests.
Testing and Finetuning
4. Testing and Fine-TuningThe process was a top-priority issue. We iterated many times until we were perfectly satisfied with the results. No compromises were made: every instability, every unclarity, and every imbalance had to be identified and removed. It costed lot of time, but at the end it payed off: we produced a game which was stable, streamlined and balanced.What we have done in particular:a) Regular, internal play-tests within the companyb) Beta-Test with testers from outside coming across different age- and skill-groups.c) Regular, automated tests running over the night on the development kits.5. DemoWith the demo everything went just perfectly. First, Nintendo announcement the revival of the demo program just as we finished with the project. This was a good fortune. Second, the dosage of the gameplay and content the demo gave to players was just perfect. Moreover, we had a huge problem having potential players being confused of what chick chick BOOM and the fun behind it actually is. Also, there was lot of prejudices like: "this looks like a flash game and now they want $8 for it, no chance". But after the demo was released, suddenly everyone had a chance to try the game for free and lot of players were surprised how addictive and multifaceted chick chick BOOM is.In summary, the possibility to offer a demo saved our lives! At least our lives as game developers. It catapulted the game out of the state of invisibility. We entered TOP10 in all major countries. It is and will always be the marketing tool #1. Especially in a small and cautious market like WiiWare. We are extremely happy that Nintendo finally decided to make this available on WiiWare too.
what went wrong?
WHAT WENT WRONG?1. FundingThe project was completely self-financed. In parallel we worked on customer projects or did consulting jobs to get some money in, which would keep our company and our private lives running. This was a very painful process introducing lot of accidental complexity into the project:a) Energy and time spent on the customer projects, which were important for our survival, was missing at the other sideb) Switching the context often led to inefficiencyc) Dependency Problems: X is idle, but depends on Y, which is working on a urgent customer projectAll this significantly contributed to the inefficiency. That we were able to finish the project under this circumstances and pressure, is for us personally a medium-sized wonder.2. Project ManagementMoreover, we had nothing which would deserve to be called project management. We developed from day to day. After one year we started making jokes like "It's finished when it's finished", or chick chick BOOM FOREVER. From the business and financial perspective it was a huge catastrophe. The size of the project and the final costs were unknown until the end. We have no proof for that, but we believe, if we had a project manager, the project would have been cancelled: "Sorry guys, no money and no resources to do it!".3. Bad Timing in MarketingWe know how to design and code games, but we had no idea about the marketing and had to learn it the hard way. Lot of things started wrong here:a) The Marketing started too lateMarketing was for us something which lied mystic in the future: "When we send the game to Nintendo, then we'll start with marketing."b) Release DateWe released in the most terrible time period imaginable for an unknown newcomer: X-MAS time. This was like committing suicide. During this period the press and the gamers are busy with the upcoming AAA titles and have less or almost no time to look at your game. Which results in no reviews at major sites or in best case a fast written review from someone who had not enough time to check the game in details (which can be even worse than having no review at all).4. Confusing Game PresentationThe game was released in October/December and we had no Trailer until February. The (raw) ingame videos, which we had online, were too complex and confusing for the player to grasp what the game is about. We needed a trailer explaining the fun behind the game, but we had none at release time. A big mistake. Trailer is a must-have. If it is good, people will talk about it more than about some confusing ingame videos. At this place we would like to send out a special 'thank you' to Josh Thomas from TheBitBlock.com who did an awesome gameplay video and video game review about chick chick BOOM! This is the best video material ever produced on chick chick BOOM! We used it a lot to show people what chick chick BOOM is.
Mission in Snowdriftland
5. Nice marketing ideas, but terrible ad-hoc planningFor the X-MAS period we organized Mission in Snowdriftland - Indie Games Edition to promote our game and other indie developers' games. It was an advent calendar, where each door was a jump & run level. At the end of each level the player unlocked a chest with exclusive material from one of the participating indie devs. We had some 5,000 visitors in average, but the event didn't gain the visibility which it could have gained, because the time was too short to get attention by the press. Nevertheless, it was a really nice event, where we made lot of friends in the indie developer scene. We'll try to repeat this one, but with a better planning next time, so that Team Meat and Nicalis also have enough time to join us. ;-)CONCLUSIONThis is it - our story on chick chick BOOM. Our mistakes almost killed us, but we are still here and we are mobilizing for our next project. Stay tuned for another tons of bits story coming up!GAME DATADeveloper: tons of bitsPlatform: WiiWareRelease Dates: 29th October 2010 (Europe) 21st December 2010 (Japan) 27th December 2010 (North America)Number of full time developers: 4Number of part time developers: 4Development Time: ~2 yearsTotal lines of code: approx. 70.000
.png?width=300&auto=webp&quality=80&disable=upscale)
