Do you have aspirations to become a game designer on a game like God of War, Mortal Combat, or Devil May Cry? Well then you’re really looking at becoming what is called a combat designer in most studios these days. Combat designers should know the inner workings of great fighting games like Street Fighter, Marvel vs. Capcom, and Mortal Kombat. The combat systems in these games are very complex and have stood the test of time for good reason. Although games like God of War are not straight up "fighting" games, they borrow from these systems to make the player controls feel tight and fun. Having passion for fighting games is a big plus. If you've been involved with the popular EVO tournaments then combat design is probably your type of gig.
The combat designer's main job or any designer’s job is to keep the design true to the pillars of the game. You will work heavily with animation, programming, and art to create player character and artificial intelligence abilities that stick to these pillars. In combat games the player's character usually has a vast selection of attack combos from which to choose. Knowing how many frames a light attack should be to feel “right” compared to a heavy attack, and when you can trigger them from another action like jumping, crouching, and standing, are things you need to know.
Let’s take, for example, that you are tasked with creating a giant elephant mini-boss. It has two attacks, a light trunk swing attack and a heavy foot stomp. What are the main ingredients in making each attack feel right? Let’s go through a few of these in detail:
The heavy attack should do more damage than the light attack, enough that any player could instantly tell a difference between attacks. Most games will show the player's health bar, which is the most obvious visual cue to how much damage the player is taking. If the light attack took 20% of the player's health and the heavy attack took 30% I would doubt most players could tell the difference. Having the heavy attack take at least double what the light attack does should be enough for the player to take notice.
All attacks should have a tip off period to give the player time to react. This is very important since it wouldn't be a game if the player took instant damage every time the elephant decided to attack. That's like asking someone a question and giving them zero seconds to answer.
The heavy attack should have a noticeably longer tip off than the light attack for a few reasons. First, the player should get more of a head start to avoid the higher damage attack. The heavy attack should feel like the elephant is putting more effort into the attack like you would expect in real life. Second, the player needs to see a big windup of the elephant raising its front legs followed by the legs crashing down for damage. Also, the heavy attack can also be made uninterruptible to emphasize its power. Uninterruptible means if the player attacks and hits the elephant during the windup, the elephant will not hit react and continue the attack until it's completed.
The player hit react animations are another noticeable piece to making combat feel right. Players should react harder to the heavy attack which could mean the player gets knocked on his butt compared to just twisting while standing in place from a light attack.
Effects help make the size and power of the attack more readable to the player so he/she can defend accordingly. For the light attacks let’s assume a yellow blade trail and for the heavy a red one.
The light attack is yellow because it's obviously lighter when compared to red making it clear to the player it does less damage. The effect will trail the swing attack and stay on for a few seconds so the player can gauge its size. If the player has dodge ability he/she should be able to learn that he/she can dodge away from this attack based on the blade trail's length.
The heavy attack is red because it's darker than yellow and it's a pretty universal color for taking damage. You would probably avoid using colors like green or blue in this case as those colors usually hint to being healed. The heavy foot stomp will make a splash effect on the ground in a radius around the elephant. With the effect appearing on the ground the player should easily learn that he/she could trigger a well timed jump to avoid this attack.
Sound effects add a good bit of personality to any attack and can make the tip off more noticeable. If the heavy stomp attack triggered a loud elephant roar as the elephant reared back on its hind legs the player would have that extra bit of cue to make a better decision on a counter move.
The level of polish is all up to you and your resources. The attacks could be enhanced by the addition of screen shake, controller rumble, having nearby crowds cheer or boo, or having the ground crack. Great games like God of War add bits of polish that often surprise players. They give you something you've never seen in a game like in the Helios head ripping scene from God of War 3.
To give yourself the right perspective for making proper design decisions, you’ll need to get the perspective of your audience. You will want to know what will surprise them and what will bore them by the time your game comes out. Say your audience is 18 to 35 year old males, which is often the case in video games. You should ask yourself what games have they been playing recently? What movies and TV shows have they been watching? If you're including an elephant mini-boss, what is the player’s expectation when they see an elephant? Will they find the elephant to be a joke based on the game’s setting?
Immersing yourself in all that your audience does and researching the great games of your genre will help you answer these questions and push your designs in the right direction. This should be your first step in creating a design. If you're creating an elephant mini-boss you should go and find similar mini-bosses from other games and take note of its behavior and attributes. What’s fun about it? What’s frustrating? What can you bring to the table that others have not?
Game Design Schools to Consider:
When researching a game you should be taking notes and recording video of the systems you’re shooting for. That means lots of pausing and restarting since games aren't tailored to show you these things in depth. With fighting games the action happens so fast that the need for recording and slowing down the action is very necessary so you can get it right for your own game. It’s so easy to think you get it after playing through a level once, but to truly be great at what you do it’s important to study the greats in as much depth as possible.
Write an outline of the systems between a AAA game and a game you consider mediocre and see what they do differently. Note all the components of the main player abilities including what sounds and visuals they trigger and what effects the abilities have on the enemies. You’ll start to notice things you’ve skipped over when just playing the game for fun.
You'll find that good combat games have multiple interrupts, meaning frames where the player can perform another move from their current move. Knowledge of where interrupts should be placed to feel right is important. Animations look and feel great because they fit the character and have the right amount of weight at the right time. When you see the elephant rear back for an attack, you want to see it struggle to shift its massive weight right before the attack is executed which makes for a good tip off. You would expect an animator to have some knowledge of this but often this is not the case. Animators do not usually spend their time learning the nuances of fighting game systems so you will have to make sure this is executed correctly. Knowing when artificial intelligence needs to hold a pose to tip-off the player and emphasize its power is very important in balancing the game.
Artificial intelligence systems need lots of iteration for the game to feel right. Artificial intelligence needs to have good spacing so the player can assess the encounter of enemies and not feel cheated. Designers need control of the ranges they setup, where they decide to attack, and where they retreat. Normally you would have a range where they run to around the player before they attack. This would be a ring around the player the artificial intelligence positions itself. When artificial intelligence is off-screen they need to behave in a different way so the player is not being cheaply damaged by something he/she can't see.
Your designs should always strive to be “cool” in the player’s eyes. If they can say “I’ve seen that before” then you need to push yourself harder to create designs that exude cool in their eyes. This is probably the hardest task to accomplish as a designer and will pose many questions that you may not have a clear-cut answer for.
Since “cool” can be different thing to many people what’s the right way to go? Do you have the resources to pull off your design based on your games engine? If not what components must you have and what can you cut? At this point you’ll need to communicate with programming on what exactly you can pull off with your engine and how long it will take. You’ll need to find your audience and poll them on what they think of your current direction. Of course you just can’t freely start posting your designs on the web and ask questions. You should be able to find people around the office that match your audience’s criteria or friends that can help you without revealing any secrets before the game is out. Make sure you’re actually talking to your target audience. If you start gathering info from someone who never plays or hates action/adventure or fighting games then it's basically like asking your mom how you should dress.
Once you’ve gathered enough research, it's time to do one of two things. Write a design document or prototype the design. Some studios will prototype a design before even writing a design document. Some will do the opposite. A lot of it comes down to time and previous experience with the design. Let me explain what each is and then I’ll explain the pros and cons of doing one before the other
A design document holds all the necessary info needed to create the design. Every department in the studio as well as the publisher usually reads the design document. Programming, art, animation, and production will need to understand your design clearly by reading your design doc. Usually you will have an overview, references of similar designs that can include video reference and screenshots from other games, an explanation of the systems needed to execute the design, and a list of assets needed from each department.
In recent years there has been a push to make design documents shorter and more concise because time and time again it has been proven that no one likes reading them. They are also poorly updated as the project carries on because designers get busy on other tasks. Even when they’re updated its hard to communicate to the right parties that it has been updated. I’ve seen examples of docs from AAA studios that only have an overview and 10 to 15 bullet points to describe the design. The rest of the design is created through iteration of the prototype, a process of which I am a fan because of the usual drawbacks mentioned above.
A prototype is a working bare bones example of your design with the least amount of work needed to get the design’s point across. If you are trying to prototype the elephant mini-boss attacks you can probably get away with very crude attack animations with no movement animations slotted at all. The elephant can be sliding when performing any movement since that is not the important piece of the design. You want to prove that a trunk swing attack and a foot stomp are effective against the player’s abilities. Crude attack animations with the damage values attached and triggering in the right situations should be the main components to finish your prototype. You want to get it to a point where the team can tell if it would be fun and worth keeping and polishing up.
The pros of starting with a design document is that everyone is clear on what their tasks are for the near future. On the surface it's easier to schedule and all departments can get the big picture and comment on it immediately. On the other hand the realities of development are usually lots of changes to the original design, which makes documents (especially longer ones) useless in the long run.
Starting with the prototype to figure out what the design should become is a good alternative. There’s factual proof that the design is fun before ever writing the doc and it will go through less iterations. It really comes down to the needs of the studio. Lots of publishers like to approve detailed docs before any work is done so there’s no getting around that.
Your next job is to communicate it all to the other departments involved. Combat designers usually spend more time with animation since there's tons of attack and hit react animations in combat games. Having a really good relationship with animation is key in getting the design right. You want to be able to walk over to animation or ideally work right next to them to make communication easy. You want to be able to pop in and feel free to iterate on animations face to face instead of making a task request through email. Too much can get lost in translation when it comes to animations because of all the small details involved. Often you’re not going to find the exact attacks you want for your game in video reference so you'll need to be proactive and act out these moves with animation. If you want a body slam done a certain way you better be ready to perform the move the best you can in front of the animators as if you were wearing a motion capture suit.
For all designer types, knowledge of how programming likes to receive design requests is helpful. If details need to be more technical then a background in programming is helpful. C++ and Java are widely used languages in the industry. Some studios expect designers to have knowledge of a scripting language like Lua or Python as well. Scripting is needed to implement systems like where and when an enemy triggers a certain action or how many enemies can be spawned at a given time.
Some studios are more design centric and designers can communicate designs with clear user stories and visuals. A user story is a statement from the player’s perspective, which is easy for all parties to understand. Writing a statement like “When the player is damaged by an elephant trunk swing he/she should feel the impact.” is enough to communicate the idea to the team to start. From there each department will create tasks and iterate as tasks are completed.
The fun begins for the combat designer once assets like the models and animations start coming in for tuning. Tuning is the tweaking of values of just about anything you have control over. Player run speeds, jump heights, damage values, the size of explosions, etc. Tuning combat systems can go on for the rest of the project to get your designs to a point where they are hitting the pillars of the game.
How do you know what changes to make? Holding playtests with players in your target audience who have never touched your game goes a long way in helping you make the right tweaks. You’ll often find players getting stuck in spots in which you never get stuck or constantly dying to enemies you thought were easy. It takes good observation and listening skills to decipher every issue correctly, but hopefully your project has enough time to hold regular play tests which will enable you to test changes.
It’s easy to get tunnel vision on a project you’ve been working on for 6+ months. Many designers tend to have their own agenda or just rely on their personal tastes to tune a game. A good designer must remember they're making a game for a target audience that usually sees things very differently. Playtests are invaluable for this reason since the entire studio can be too invested to make the right decisions.
If all of this sounds like your vibe then start researching your favorite combat games with a fine toothed comb, find a school with a good design/programming course, and get ready for a rewarding career as a Combat Designer.