Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Vivid Games' Real Boxing
View All     RSS
October 24, 2014
arrowPress Releases
October 24, 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 2 of 4 Next

3. Unique Features: Gesture Control System and Multiplayer Mode

The idea for the gesture control system was put forward by our CEO Remigiusz Koscielny at a meeting with Apple. We put forward the idea of using the camera on Apple devices to enable the player to control their fighter in a Kinect-like style. This immediately sparked Apple's interest, but the challenge was that we hadn't actually developed the system and no other iOS application featured anything like this, so we so then had to figure out how to make it work!

The development of our innovative motion control scheme (later dubbed V-Motion) consisted of three phases. In the first we acquired the necessary data, which was then processed in phase two, the longest one. This processed data became the base of our technology for the Gesture Control System.

In the third phase, movements were transferred into the game engine. The initial results weren't very good. The system was unstable and needed to be continuously re-tested. However, three weeks before the project's deadline, we finally had a breakthrough which meat that it worked. We were all surprised and excited by how the motion controls turned out. People at Apple, who were given an early build of the system, were also very impressed.

At the time, we noticed that each player moves differently, and that the system didn't always register the gestures correctly. It was therefore necessary to design a tutorial for the player to learn how to move, so that their boxer behaved how they wanted him to. The work on the gesture control system lasted three months. Admittedly, the motion controls still had some limitations, working best in a brightly lit environment with the player dressed in a contrasting color over a plain background such as a wall.

True multiplayer rarely appears in iOS games. When it does, it is usually in a turn-based form. Our goal was to create a fully-fledged, real time multiplayer experience for two players, but first we needed to see how the Unreal Engine worked with iOS and the Game Center system.

Most of the problems we encountered whilst developing Real Boxing's multiplayer were due to the need to optimize the performance across different devices, because one player may be running the game on an iPhone 4S and the other on the new iPad. Making it work meant facing many challenges.

The multiplayer mode was created by Jaroslaw Dziuk and Lukasz Purcelewski, and the whole process took more than three months in total. We're are still working on further optimization for the online experience, with future updates expanding it with new social networking functionalities and even game modes created by Bartosz Biniecki -- one of our game designers.

4. Outsourcing

Both the scale and degree of sophistication of the project were enormous, which is why we decided to outsource some of the work to other companies. The most important thing for us in any collaboration is receiving a finished product, ready to be implemented into the game itself.

Dash Dot Creations, one of the best animation studios in Poland, did the animations for Real Boxing. This encompassed the teaser trailers, game trailers, game intro, animations, and computer processing.

In order to achieve a high degree of realism, we decided to use motion capture sessions with real boxers. This was undertaken in the state of the art Alvernia Studios, which has been used for The Witcher 2: Assassins of Kings and Bulletstorm. Voice acting for the game was recorded in London, at the famous Studio OM (Driver: San Francisco, Risen 2: Dark Waters, Tales of Monkey Island). Working with these companies allowed us to maintain high quality standards and also to finish the game in a very short time.

5. Visuals

Using the Unreal Engine has brought a lot of praise for the game's visuals. It's one of our best achievements, and it shows just how far one can push current mobile devices. Just some of the graphical effects we implemented are depth of field, color grading, bloom, rim lighting, normal mapping, and environment mapping.

The boxers are the most important element of our game and that is why they received the most polish. We made highly customizable characters with players being able to change not only their name and hair color, but also skin color, tattoos, and clothes. We want to highlight this because implementing tattoos, as simple as it sounds, required us to modify the game engine. What's more, during the fight every punch has a visible effect on the boxer: face and body deformation, facial expressions, blood, bruises -- we wanted to create boxers as close to the reality as possible.

Real Boxing is a game for iOS, but Wojciech Michalski, created 3D models that could be used in games for PlayStation 3 and Xbox 360. Each one consists of 10 million polygons, which wasn't an easy thing to do, considering some of the limitations of the iOS version of Unreal Engine -- poor lighting being one. In order to obtain good results, we had to resort to a number of tricks (for example, the light source is positioned at the point of the camera, which gave good shading and good effects on the skin of boxers) as well as work around compression issues, because you'll not find clearly pixelated textures like in many other games on iOS, yet our boxers show great detail right down to their muscles.

What we managed to do with the audience, however, is on a different level; it was our mini Mission Impossible. One of our graphic artists, Bartosz Rydel, created the most advanced animated audience on mobile devices and based the models on our own Vivid Games' people. Sadly, everything comes with a price. Performance optimization was very important; hence the iPhone 4 version of Real Boxing doesn't have these animated character models, but a texture with the audience instead.

The 3D menu is another jewel. The background is an interactive training arena, from which you can go straight to mini games (mini-bag, speed-bag, jumping rope). Creating games for mobile devices is in many ways much more difficult than a PC. On a smartphone you can't just add motion blur with a press of a button, but you still need to implement it. That is why we are very happy Real Boxing was appreciated in terms of graphics.

Article Start Previous Page 2 of 4 Next

Related Jobs

Red 5 Studios
Red 5 Studios — Orange County, California, United States

Graphics Programmer
Red 5 Studios
Red 5 Studios — Orange County, California, United States

Gameplay Programmer
Gearbox Software
Gearbox Software — Plano, Texas, United States

Server Programmer
Giant Sparrow
Giant Sparrow — Playa Vista, California, United States

Junior 3D Artist


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.


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).


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.

The decision to outsource some of the development - developer Diary Part #1 should help.

'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 ;-)