Wednesday, September 09, 2009

TKO - Designing a fighting game - Part 2

Last time I talked about figuring out the minimum requirements to make a good fighter and the decisions made to find the right balance of simple and solid. Now I want to address the general design and production strategy of the game.

Art/Character Production strategy
Making every fighter totally unique was simply not possible. We worked up a strategy where all characters had a pool of moves. Then characters would use those moves to focus their character type. A few general rules:
1) All characters share the same light attacks (high, low, jumping)
2) Character has 1 of 3 heavy punches : straight (good on the ground), angled (good anti-air), arc (in-between))
3) Character has 1 of 3 heavy kicks: straight (good on the ground), angled (good anti-air), arc (in-between))
4) Character has 1 of 2 jumping heavy punches : straight (good air to air), angled down (good for jump-in attacks)
5) Character has 1 of 2 jumping heavy kicks: arc (middle, knocks down), angled down (good for jump-in attacks)
6) Character has 1 of 2 low heavy punches : straight up (good anti-air), angled down (good for ground)
6) Character has 1 of 2 low heavy kicks: fast sweep (good distance), sliding kick (good for movement)

From a few choices for heavy attacks characters styles start to emerge: strong ground game, strong air-to-air, strong anti-air, strong jump-in, etc.

For special attacks we would repurpose some of those moves, add special effects and sounds to make their special attacks. We are using any animation we think would look good and work with the special. This could be 1 frame of jumping mixed with 2 frames of kicking, etc.

All characters share the same core animations such as walk, jump, hit, etc. Somewhere along the way we got time to do different idle animations for all the characters.

Character Design
At the most basic level, designing a fighting game character is choosing how they will control space on the game field. Many of these divisions have already been figured out by the myriad of fighting games on the market. Honestly, without designing new systems around each character (like BlazBlue did) there is not much new ground to break here.

For simplicity, the decision was made that all characters have only 2 special moves, one with punch and one with kick. We would modify parameters of the special moves based on strength of the button used.

I started with a baseline character, Swampfire. He has a projectile attack and a rising hitbox right in front of him. I am sure this will look familiar.

Fireball


VineSpike


From here I worked out the the other characters. I wanted to make the robots feel like their CN counterparts. Swampfire was an easy fit but Big Chill needed something special, He needed to freeze you. I gave Big Chill an offensive and defensive freeze. Obviously freeze loops would be a problem so we made the rule that you cannot freeze an opponent during hitstun. As a result Big Chill must rely on hitting freeze attacks (which do little damage) and then land link combos.

I knew I wanted Kevin to be a close up brawler. His game was going to be to get close and land his special throw, a throw that bounced opponents off the wall and set up juggle combos. For his 2nd move I gave him an attack that closed distance and avoided projectile attacks.

I wanted Van Rook to be a run-away character. He would rely on lobbing projectiles and teleporting away from his opponents. The lobbing arc allows his projectiles to be both a ground and anti-air attack when timed correctly. His teleport kick would shoot him off the back of the screen and reappear on the other side, kicking the opponent in the back.

Munya was going to be the heavy hitter archetype but with a twist. He had all arcing normals and a dash attack. However his kick special was a counter, he would strike a stance and when his opponent attacked him he would automatically counter with an attack that bounced opponents off the wall setting up juggle attacks.

Zak had to have the his claw attack. His claw is a great long distance poke and a fair anti-air attack. However, he has an array of anti-air normal attacks. He had a fast kick which jumped to the back edge of the screen and then flew down at angle quickly with a kick. Zak would be used most efficiently right out of opponent normal attack range.

Those were the first six we went into production with. I will not delve into the other characters because they were all redesigned. If you played TKO, you will have surely noticed many of the moves are not as originally designed.

Character Design Redux
As development progressed, it was clear we had to trim the timeline. Swampfire and Big Chill were in the game and working but the remaining characters required new systems that were not yet implemented: counters, special throws, bouncing off the edge of the game screen, attacks moving on and off the game screen.

As a result many of the moves were refitted to use existing systems or be modifications of existing systems. The juggle system was changed to make attacks have juggle properties instead of relying off the edge of screen bounce. I thought the juggle change would be a big issue. The bouncing off the edge of the screen was really a timer to allow juggle attacks to have a significant recovery so on miss or block it would be punished. To make the juggle attacks effective (i.e. you have enough time to recover and attack after a successful juggle attack), juggle attacks had to recover very quickly. I was worried this would be abusable but the core juggle system our programmer implemented (juggles are less effective each hit) took care of this.

Frame Data
When we started I tried to take simplified approach to frame data. I quickly discovered this does not work. The accepted frame data system (using start-up, hit, recovery, hitstun, blockstun, knockback, damage, block level, knockdown) is as simplified as it can get.

I set up an Excel document for all my data. I also set up some custom columns to calculate simple judgement on moves. I set up columns for things like: "Is this safe on block?", "Safe on hit?", "Jab after hit?", etc. so I could evaluate the effectiveness of an attack.

Then this was linked to another sheet with just the data the programmer needed to copy out.

I tweaked and tweaked frame data over and over. I am still tweaking this data daily to fix previous characters and set up new characters. It's uncanny how 3 less frames of start-up on a special attack can make a character go from weak to strong.

Testing & Balance
Once all the 6 characters were in it was time to test and balance. I made an Excel document where I tried to exploit the damage output of each character and then graph this along certain situations. How much damage could they do in the corner? Off a throw? With a full super meter? The graph then made it easy to see which characters had huge damage spikes or deficits.

To remove the factor of execution, I had another sheet where I could enter combos and they end values, taking into account damage scaling, would be output.

I also had an Excel sheet which was more of a power check list. How many link to special attacks? How many knockdown attacks? Can this character throw to super? Can they combo after super? Do they have a stun attack? How many ways can they land a super attack? Etc. Then I summed up these checkboxes to get a general idea of power.

From here I tweaked frame data and damage values. My damage output sheet showed me something troubling, it was more effective to use normals for damage output than special attacks. Based on this I totally retooled the damage values for all moves.

Ongoing
TKO is being tested and balanced daily. We are listening to feedback and looking at player data. We have 3 more characters to release and that means 3 more builds of balancing too. If enough people are playing, maybe more will be on the way.

Labels: , ,

Thursday, September 03, 2009

TKO - Designing a fighting game - Part 1

The Long Road
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.

Beginning
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.
  1. 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.
  2. 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.
  3. You must have blocking and as a result you must have a move that defeats blocking (i.e. throwing)
  4. You need combos, they are fun.
  5. Characters needs to feel significantly different. They should require different strategies to play. For this, attacks unique to the character are required.
  6. You need a significant number of characters for players to play, at least 8 to cover the expected styles of fighting game characters.
Looking at this list, it's obviously a ton of work. However, there are many excellent fighting games on the market. The bar is set very high and without these key features the game would lack any value of production.

In addition to the unsaid requirement of making a fighting game. there were some explicit requirements as well.


Requirement - Simple controls.

Core attacks
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.

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

Special Attacks
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.

Super Attacks
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.

The Plan

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.

Labels: , , ,