TKO - Designing a fighting game - Part 1
TKO had a very long and winding road to the light of day. At the start of the project it was a reskin of Adult Swim's Naked Toonbots, a turn-based multiplayer "fighting game" which was really just fancy RPS (rock, paper, scissors)... with super moves.
Then this evolved into Naked Toonbots but you could build your own fighting robot by choosing arms, legs, torso and head. These parts would have different attacks and visual looks.
Then that evolved into real-time mutliplayer robot fighter where you could build your own robots. Luckily, at some point I decided the build-your-own feature was insanity so it was cut.
So now we were making a "real" fighting game for the Cartoon Network demographic. Now the following statement may sound uninspired but it's the most important part of my job, I had to figure out what were the minimum features needed for a solid fighter. Our team is small and we have to make numerous games a year. Even the most most frugal game design is a huge amount of work. I needed a feature set that would produce a good fighting game (good for kids and yet solid enough to be a "real" fighter) and still be doable by our team in about 6 months.
Without a few key features a fighting game seemed pointless to create.
- You must have jumping attacks, standing attacks and low attacks. Fighting games are an elaborate series of RPS guessing games and this is the core system you must have.
- You must have at least 1) fast light-damage moves and 2) slow-heavy damage moves. This is a core risk/reward system for attacking. Range of attacks also plays a large role.
- You must have blocking and as a result you must have a move that defeats blocking (i.e. throwing)
- You need combos, they are fun.
- Characters needs to feel significantly different. They should require different strategies to play. For this, attacks unique to the character are required.
- You need a significant number of characters for players to play, at least 8 to cover the expected styles of fighting game characters.
In addition to the unsaid requirement of making a fighting game. there were some explicit requirements as well.
Requirement - Simple controls.
I wrestled with numerous control schemes, 6-button, 2-button, 3-button. 6 seemed too many and 2 or 3 seemed too few. We explored doing things like direction + a button to keep the button number low but that was more complicated than having more buttons. I finally settled on 4 buttons, light punch, heavy punch, light kick and heavy kick.
We needed a throw and I think explicit throw command (not distance related move change) with throw miss animation is the best execution. We used both light attacks pressed at the same time ala Street Fighter 3 3rd Strike and Street Fighter 4.
I decided to keep things simple all character would have the exact same special attack command, toward > toward > attack. While I think down > toward > attack is more classic for fighting games and easier to input, accidental special attack execution would be a problem when moving from crouch to forward.
I wanted these to be very simple to execute. At the start I wanted the input to be all 4 attack key pressed at the same time. However, I discovered many keyboard will not accept more than 3 simultaneous key presses! While I did not want to add another key, using the SPACE key worked out well.
Requirement - One-click multiplayer gaming
Our last multiplayer game, Ben 10 Bounty Hunters, taught us a very important lesson, our site traffic is too great for the normal "make a room and let players join." The rooms churn too fast and this makes for a very frustrating experience. We opted for auto matching people and allowing them to either rematch with their current opponent or find a new one.
Requirement - In-browser
Another lesson from Bounty Hunters, our audience will not download a client. We had to make the game in Flash. Since Flash does not support P2P (without special Adobe software which was not released at the time, I am not even sure if its released now) this also meant that the game has to be client-server and not P2P. In addition to all this, there were a few extra challenges. Unlike many other multiplayer games, like racing and shooters, you cannot do movement prediction. To our knowledge, no one has ever made a real-time multiplayer fighter in Flash so our guys were doing the most difficult thing possible with no frame of reference. Our programming wizards spent a few months working out a system to get the needed messages passed as fast as possible and coming up with a slick server system to manager players.
Now we know what we wanted to do, now it was time to plan the how. Stay tuned for Part 2 where I will detail our plan for animation production, character design and the importance of frame data, hitboxes and testing.