Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Vivid Games' Real Boxing
View All     RSS
August 1, 2014
arrowPress Releases
August 1, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Postmortem: Vivid Games' Real Boxing

January 21, 2013 Article Start Previous Page 3 of 4 Next
 

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.


Article Start Previous Page 3 of 4 Next

Related Jobs

Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States
[07.31.14]

Unity Engineer
Retro Studios - Nintendo
Retro Studios - Nintendo — Austin, Texas, United States
[07.31.14]

Gameplay Engineer
Crystal Dynamics
Crystal Dynamics — Redwood City, California, United States
[07.31.14]

Producer
GREE International
GREE International — San Francisco, California, United States
[07.31.14]

Senior Software Engineer, Unity






Comments


Valentina Ciolino
profile image
Great article guys!

russell mckee
profile image
Soooooo........ ummmmmm.......... most (if not all) Post Mortems talk about sales, like in the number of paid downloads??? Like um, how much money did you make off of this game?? But you give us one little ol sentence in four long pages "We feel that with Real Boxing, we achieved a victory, one that was confirmed by reviews and gamers alike". You'd rather talk about "Joe Shmoe beta -tested 36 hours" and "More than 500 energy drinks"???

Simon Carless
profile image
Russell, I note that the game has IAP, so it won't just be about 'paid downloads', but yep - $300,000 is a fairly hefty sum for a mobile title (or maybe not nowadays, but seems like it to me!), so I wonder how it's doing on the road to making its money back.

Quan Ngo
profile image
Totally agree. This article provide little useful information as a postmortem.

Grzegorz Brol
profile image
Hi Russell,

One month and a half after release = almost 150 000 sales.

Bram Stolk
profile image
Is there is 0 missing in the budget?
How can you hire 25+8 people for half a year at 300K?

Justin Lloyd
profile image
You can't. $300K would barely cover a single month of a 25-person team's salary plus G&A unless you are paying each of them $1,000 a month.

Pawel Miechowski
profile image
You can. The guys are from Poland where costs of "daily" life are significantly lower than in US or Western Europe but the salaries are lower too. And I'd say not each one of the 25+8 team was 100% assigned for this game so the costs should be filtered thru this. Of course, they have had to pay for the office and the overhead costs, but I can easily imagine this team would have done RB for 300k. After all, I'm a developer from Poland too.

Grzegorz Brol
profile image
Hi Paweł,

Thanks for the answer. I could write exactly the same thing :-) Btw, great article about Anomaly!

Justin Lloyd
profile image
I concede the point to Pawel.

Pierre Xavier
profile image
Hmmm, i still prefer super punch out! :D

Jorge Garcia
profile image
I really appreciate the postmortem on this, I am a huge fan of boxing and interactive media, so this was a joy to read.

Bram: I was thinking the same thing, there doesn't seem to be enough in that budget to pay the employees a reasonable wage...

Jay OToole
profile image
I really enjoy postmortems and yours is no exception. So, thank you. I apologize if some of my questions appear naive or unimportant. I am still very much learning about game development and the inherent challenges and risks associated. For what it is worth, I thought I would offer a few questions and comments that remained with me after reading your postmortem.

WHAT WENT RIGHT

1. You write that "one of the key decisions was to bring people from different teams together to work on the game." Why was this so important?

Beyond simply providing more "hours" of production in the last weeks before release, how did having people from different teams working on the project make this particular development process better than it otherwise might have been? Did the diversity of perspectives or experience lead you to make novel decisions? Did you find that having people from different teams allowed you to generate more creative ideas, new ways of developing the game, etc? Just curious.

2. I really enjoyed reading the section on The Fighting System. I thought it was thorough and provided sufficient detail to allow me to see how it might generalize to other game development projects. Admittedly, I am not a game developer so maybe others who are actively making games feel differently.

3. Sounds like the decision to outsource some of the development was made early. I would be curious to know what criteria you used during your selection process. How many animation studios did you consider before making your decision to work with Dash Dot Creations? I have similar questions for your decision to work with Alvernia Studios and Studio OM. I thrilled to hear that it worked out for you and I think giving readers an understanding of how you came to those decisions would be really beneficial (especially if the cost of outsourcing to those particular studios is prohibitive for other projects).

WHAT WENT WRONG

1. Is it standard practice to implement changes AFTER final testing? Again, my ignorance of game development is exposed, but I am still curious. Based on my experience with other software testing and my understanding of other development processes, changes are not encouraged after final testing, for the very reason you illustrate in the postmortem. Are implementing changes after final tests a necessary evil?

2. I really appreciated the concrete suggestions you outlined under "Crunch Time." To give me/us some perspective, how much time did you spend planning and researching for this project? Having an a better understanding of the resources (time / money) committed on this project would give me/us a sense of what "more" means in this scenario.

Thank you again for your insights and contribution.

Grzegorz Brol
profile image
Hi Jay,

'Did you find that having people from different teams allowed you to generate more creative ideas, new ways of developing the game, etc?' No, it was the last month of the production. There was no time for such things.

The Fighting System - developer Diary Part #2 should help.
http://www.youtube.com/watch?v=hVbjjORop3U

The decision to outsource some of the development - developer Diary Part #1 should help.
http://www.youtube.com/watch?v=GwEbsqfkOOg

'Is it standard practice to implement changes AFTER final testing?' Well, "final testing" should mean "final testing". Theoretically... 'Are implementing changes after final tests a necessary evil?' It could be true ;-)


none
 
Comment: