What Went Wrong

1. Training Mode

The challenge for any game is to launch as bug-free as possible. This is especially crucial on the App Store, where a minor error can result in poor reviews and a lowered star rating. Testers reported 1403 errors -- including both the smallest ones that were corrected in five minutes as well as 193 fatal errors. The team worked almost nonstop, and the infamous record belongs to Jacek Szarejko, senior tester, who worked 46 hours in a row -- just like doctors in hospitals (he also recorded 3.13 GB of gameplay videos and photos).

Despite all of this, the first version of the game contained two critical errors, which meant that it failed to end if the player completed the final task ahead of time. The error slipped through testing because of some changes implemented in the version after the final tests, which theoretically weren't supposed to affect the training in any way. We immediately eliminated the problem in the first update, but for many players their first impression was associated with this error, resulting in a mix of one and five star reviews.

Early in the development, we were well protected from such errors. Once a week, we had a control of the files and code review. The document reported bugs and fixes, and attributed them to specific developers. Our goal was primarily to eliminate the problems of further development of the code. The advantage of this arrangement was that one person had an insight into the whole project.

We also had also several additional documents for our developers, thanks to which a new programmer could quickly get in the draft, for example one about the setting-up tools (configuration, commissioning of the project), technical docs (technical aspects of the implementation), or Unreal script best practices (code tips). Of course, the preparation of documents and full control required a lot of time. Krystian Komisarek, our lead programmer who dealt with the code reviews, earned the name of "doc writer."

However, in retrospect, we can still see some imperfections and shortcomings of our system, for example naming and sorting of reported comments in reviews which caused the use of the review to be very difficult.

2. iPod Touch (4th Generation)

Literally a week before the premiere, there were problems with support of both iPod Touch 4th Generation and iPhone 4, and we thought we had overcome them. After the release, though, it turned out that despite our efforts, there were still problems. We immediately informed players, adding a message to the App Store description of the game and apologizing to them. The error has been eliminated in another update, and players who purchased the game on these devices were rewarded with in-game coins.

We handled errors via FlySpray, whose advantage is the ability to add tags. It allows you to quickly search for specific errors, set the priority and specifying the percentage of its amendments. We added attachments (print screen, videos), which allowed us to fix or verify bugs quickly.

Testers also connected errors: if one error was due to another there was a chance that one patch will work for both. In addition, we always added the following comments to all errors: who and what improved, version, device. This allowed fast transmission of information to the right people. Unfortunately, even this system didn't save us from those two big mistakes. We're always striving to improve processes and learn from mistakes, that was a good lesson for us.

3. Documentation

The preproduction phase was rather short, and we didn't have much time to discuss some key game features. The main game design document and other additional documents (i.e. SFX and music list, voiceover document, game economy sheet) were finished as the project was moving on. Updating documents every week was a great way to monitor progress. For each documentation update, we sent a short outline of the changes to the team members with bullet points in the email giving them a glimpse of key changes in the project.

The information flow may fail a bit from time to time. We decided that the best way to improve the information flow was to organize meetings with the people involved in the implementation of specific features. Sometimes, spontaneous talks took place in the team's room saving us from lots of additional work or helped to solve the major issues.