|
Here at Vivid Games, we've been making mobile games for nearly 10 years. We've produced several sports titles around ski jumping, speedway, and BMX. We've even tried our hand with the future of sport, by bringing the classic Speedball 2: Evolution to both iOS and Android.
Whilst deciding on our next game, we saw a great opportunity to bring a realistic boxing title to mobile and tablet. With EA's Fight Night Champion being the only real contender for the boxing title, we thought that we would enter the ring as the wildcard outsider.
We've noticed that in the last year, something has fundamentally changed on mobile and the App Store. The bar has been raised massively in terms of gameplay and production values, with standout titles such as Infinity Blade II, Dead Space, CSR Racing, Sky Gamblers, Dead Trigger, and Bastion.
The increasingly competitive world of the App Store means that you've got to invest heavily and have triple-A titles that will grab the attention of the media, and, most of all, Apple and Google -- with all developers hoping to be featured each Thursday.
That's why we made a point of never compromising our vision of the game, Vivid Boxing, and we invested a huge amount of resources into the project, using the best technology available. The cornerstone of this was Epic's Unreal Engine 3, to bring a console look and feel to the game. We risked a lot and crossed a lot of barriers, but our initial vision remained unchanged.
What Went Right
1. The Team
People are definitely Vivid's most important and valuable asset. It's something you have to keep in mind when organizing their work. Whilst working on Real Boxing, rooms and furniture were rearranged so that people wouldn't have to run across the building searching for one another. Team meetings were being held so often that we had to use our social room, because the only conference room we had was not enough.
Researching boxing through movies and games was part of getting ready for Real Boxing. We also had gym sessions, martial arts training, and a punching bag hanging in the heart of the office -- all that constantly reminding us how important this project was for the company.
One of the key decisions was to bring people from different teams together to work on the game. Developers, designers, and everyone working on some of the other projects ended up helping with the production of Real Boxing in the last weeks before release. We're extremely proud of everyone's involvement, which extended far beyond what was expected of them. For example, game testers not only reported on errors, but also suggested how to fix them. Their knowledge of boxing also proved very resourceful. Most importantly, everyone was highly motivated throughout the entire production.

2. The Fighting System
The fighting system was always going to be our greatest challenge. When production started, we tested different types of touchscreen control. The first version of the control system used two buttons to dodge left and right. Tapping and holding with both fingers led to a blocking movement. Making single-tap or slide gestures performed different types of punches.
However, the first focus test clearly proved that most people were unaware that boxing involves a lot of dodging, so we decided to implement a single dodge button which would trigger the appropriate type of dodge depending on the attacks received. This way, the player only had to pick the right moment to dodge.
Simplifying the gameplay mechanics went even further. Someone suggested dividing the screen into two areas: the left side being defensive -- where taps would trigger a dodge, whilst tap-and-hold would start blocking, and the right one being offensive -- where taps and slides would trigger punches.
We soon discovered that this required too much interaction and killed all the fun. Players couldn't decide which hand to use for the next attack and it wasn't natural. There was even a moment when we were thinking about dividing the screen into four areas so that the player could decide between throwing punches at the head or at the opponent's body but we abandoned this idea since it overly complicated the gameplay.
Eventually, we returned to the previous idea, which was pretty similar to what we have in the final build with the control system deciding if it's better to hit the head or the torso. This gave the player time to attack properly with the addition two buttons on the HUD for blocking and dodging.
We then had to make a difficult decision about the flow of the fight. We needed something that would make the fight less chaotic -- less like a street brawl and more like actual boxing. Implementing smart AI was an important part of the process. The effectiveness of each blow was limited by the amount of stamina each character had. Each punch lead to a decrease in stamina, so the AI should not only decide when to attack the player, but also when to slow down for a bit to regain stamina. This is how "floating turns" were born.
The duration of each turn depends on the actions of both fighters: if the player's fighter has a full stamina meter, it means that the player may attack soon, so the AI becomes defensive, and uses blocks and dodges; if the player decides not to attack, despite the high stamina, the AI will attack -- if his stamina meter is full.
In addition, each turn can interrupted with a dodge. A successful dodge grants the player a stamina boost and a great opportunity for the counterattack, which then causes greater damage than a regular punch. Transitions between offensive and defensive "floating turns" were marked with text displayed on the screen: ATTACK and BLOCK or DODGE.
We found that sticking with this “natural” flow of the fight was the best way to beat down the opponent. Just like in the real ring, it's wise not to rush at your opponent from the very start. A wild and furious charge drains all the stamina and your moves become less effective --offensively and defensively.
Finally, to make the player feel truly like they're in a boxing ring, you also need to have a camera that works in the right way. We wanted one that would shake in a realistic way during attacks and whilst taking damage, and our first attempt involved point interpolation and the built-in shake mechanics of Unreal Engine 3. This turned out to be more chaotic than we anticipated, and we decided to go with a camera sporting smoother transitions. We placed the camera at a fixed point in relation to the boxer, and then simulated movement using particle physics affected by several forces.
For example, one of these would be the force stemming from animations, an elastic force turning the camera back to its default position in relation to the boxers, or the resistance force, which prevents the camera from moving at excessive speeds or shaking too much. Assigning a single three-dimensional vector to each animation allowed us to create a fully animated gameplay camera, with each attack making it respond in a unique and satisfying way every time.
|
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 ;-)