|
4. Kismet and Animation
We had problems with Kismet, which was used by designers for the prototypes. Their job was well done, but a problem appeared in the final version of the game. We saw real monsters built from the blocks, and gargantuan links between independent elements of the game. It was a source of extreme errors.
We also had to deal with the framerate and drops in performance. For example, the reaction to the attack was associated with face and body deformation, facial expressions, blood or bruises. Problems ended after we transferred those events to the Unreal Script -- programmers rewrote what level designers had created in Kismet on the scripting language. It gave us better control and improved performance.
We also encountered serious problems with the animation. Perhaps we didn't spend enough time on research and training, because part of it was incorrect. Particularly troublesome was the distance between players. We recorded three different distances for each hit, so that devs could afford to choose the best one.
However, we still had the unusual situation when the boxers began to attack at the same time. We had to use a couple of tricks to overcome this including collision detection, inverse kinematics and selection of the most appropriate action.

5. Crunch Time
The decision to cooperate with external companies was correct, but we found out that reporting errors and bug fixing became much harder. Direct contact always shortens the path and speeds up the process. It was the right decision, but passing the data to the new programmers who later joined the production almost killed our server on the same day when we had to finish a valid build!
Like most developers, our team was working flat out at the end of the project to deliver on time, as Apple had indicated they would possibly get behind the game in a big way. During this time, one of the rooms literally turned into a repository of energy drinks and local restaurants provided meals on a daily basis for those working extra hours. The ambitious nature of the project put massive pressure on the team, and each developer was aware of the need for it.
There is no simple recipe for a solution to this problem. We can't pretend we found one either -- yet -- but we will change few things in the future. To name but the smallest one, for example, as we experienced occasional delays due to lack of complementary equipment -- graphic designers required additional monitors and had to wait for delivery, so we'll surely optimize the work stations earlier next time.
In the case of a tight schedule, every short downtime can cause people to stay longer. For our next high-budget title we will spend more time planning, researching and will invest even more resources into the project preparation. For Real Boxing, we knew that we were working on a triple-A title, but that's easier said than done.
It is certain, however, that every team needs to rest and regenerate after such a hard work, so everyone got additional paid vacation after the release of the game and began to receive overtime. We also prepared a huge “Thanks for the hard work” banner for the office.

Final Verdict
We feel that with Real Boxing, we achieved a victory, one that was confirmed by reviews and gamers alike. The investment in quality shone though, and we were awarded the coveted Editor's Choice by Apple, and received almost universally great reviews from all the major media that we targeted.
We also learnt a lot of lessons, as developing high-end games for mobile devices is new territory. Real Boxing has by far and away been the biggest venture for our studio and brought invaluable experience. But this is not the end. We plan on supporting Real Boxing by providing updates, releasing new content (arenas, boxers, items), and expanding the multiplayer mode. We're also looking at the possibility of releasing our game on other platforms. Of course, Real Boxing is just the first of a few high end titles we've got in the works, so watch this space!
Data Box
Developer: Vivid Games Publisher: Vivid Games Release Date: 15 November 2012 Platforms: iOS Number of Developers: 25 full-time, 8 subcontractors Length of Development: 5 months Budget: $300,000 Development Tools: Unreal Engine, Scaleform And: More than 500 energy drinks, few boxing training sessions, 25 pairs of boxing gloves, about 200 dinners, one punching bag, a few thousand coffees, one big Thank You banner for our team.
|
One month and a half after release = almost 150 000 sales.
How can you hire 25+8 people for half a year at 300K?
Thanks for the answer. I could write exactly the same thing :-) Btw, great article about Anomaly!
Bram: I was thinking the same thing, there doesn't seem to be enough in that budget to pay the employees a reasonable wage...
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.
'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 ;-)