What makes a combat system for fighting games?

Recommended Posts

Hi there,

it's been a while since my last post. I was creating a bunch of games but there was always something missing. Something which makes the game (maybe unique)... After a few tries I decided to start a side project for a combat system which should be used for fighting games.

I did a lot of research and programming to finally get something that makes actually fun to play. Well... it is only a prototype and I do not want to share it (yet). Now I decided to share my ideas of the basics of a combat system for fighting games.

Don't get me wrong... This is only my way of doing stuff and I want as many feedback as possible and maybe it will help people with their games.

I will provide a few code snippets. It will be some sort of OOP pseudo code and may have typos.

Content

1. Introduction

2. Ways of dealing damage

1. Introduction

What makes a combat system a combat system?

I guess it could be easy to explain. You need ways of dealing damage and ways of avoiding damage. At least you need something for the player to know how to beat the opponent or the game. As i mentioned before, I will focus on fighting games. As it has ever been there is some sort of health and different ways to reduce health. Most of the times you actually have possibilities to avoid getting damage. 

I will focus on these points later on.

2. Ways of dealing damage

How do we deal damage by the way?

A common way to do so, is by pressing one or more buttons at one time in order to perform an attack. An attack is an animation with a few phases. In my opinion, an attack consists of at least four phases.

1. Perception

2. Action

3. Sustain

4. Release

Here is an example animation I made for showing all phases with four frames:

attack_frames.png.eedca8526ccd73023c2e59fa84233518.png

Every one of those has its own reason. One tipp for our designers out there is to have at least one image per phase. Now we should take a closer look at the phases itself.

2.1. Perception

The perception phase should include everything to the point, the damage is done. Lets say, it is some sort of preparing the actual attack.

Example: Before you would punch something, you would get in position before doing the actual action, right?

Important note: the longer the perception phase is, the more time the opponent has to prepare a counter or think about ways to avoid the attack. Like having light and heavy attacks. The heavy attacks mostly have longer perception phases than the light ones. This means, that the damage dealt is likely greater compared to the light attacks. You would like to avoid getting hit by the heavy ones, right?

2.2. Action

The action phase is the actual phase where damage is dealt. Depending on the attack type itself the phase will last longer or shorter. Using my previous example, heavy attacks might have a longer action phase than light attacks. In my opinion, the action phase should be as short as possible.

One great way to get the most out of the attack animation itself is by using smears. They are often used for showing motion. There's ton of reference material for that. I like using decent smears with a small tip at the starting point and a wide end point (where the damage should be dealt). This depends on the artist and the attack.

2.3. Sustain

At first sight, the sustain phase may be irrelevant. It is directly after the attack. My way of showing the sustain phase is by using the same image for the action phase just without any motion going on. The sustain phase should be some sort of a stun time. The images during the sustain phase should show no movement - kind of a rigid state.

Why is this phase so important?

It adds a nice feel to the attack animation. Additionally, if you want to include combos to your game, this is the phase, where the next attack should be chained. This means, while the character is in this phase of the attack, the player could press another attack button to do the next attack. The next attack will start at the perception phase.

2.4. Release

The release phase is the last phase of the attack. This phase is used to reset the animation to the usual stance (like idle stance).

2.5. Dealing damage

Dealing damage should be only possible during the action phase.

How do we know, if we land a hit? I like using hit-boxes and damage-boxes.

2.5.1. Hit-boxes

A hit box is an invisible box the character has. It shows it's vulnerable spot. By saying "Hit-box" we do not mean a box itself. It could be any shape (even multiple boxes together - like head, torso, arms, ...). 

You should always know the coordinates of your hit-box(es).

Here is an example of a hit-box for my character:

hit_box.png.c9c1a2444b1deb175ee414b268d0bf86.png

I am using Game Maker Studio, which is automatically creating a collision box for every sprite. If you change the sprite from Idle to Move, you may have a different hit-box. Depending on how you deal with the collisions, you may want to have a static hit-box.

Hit-boxes could look something like this:

class HitBox {
	/*
    offsetX = the left position of you hit-box relative to the players x coordinate
    offsetY = the top position of you hit-box relative to the players y coordinate
    width = the width of the hit-box
    height = the height of the hit-box
    */
	int offsetX, offsetY, width, height;
    
    /*
    Having the players coordinates is important.
    You will have to update to player coordinates every frame.
    */
    int playerX, playerY;
    
    //initialize the hit-box
    HitBox(offsetX, offsetY, width, height) {
    	this.offsetX = offsetX;
    	this.offsetY = offsetY;
    	this.width = width;
    	this.height = height;
    }
    
    //Update (will be called every frame)
    void update(playerX, playerY) {
    	//you can also update the player coordinates by using setter methods
    	this.playerX = playerX;
    	this.playerY = playerY;
    }
    
    //Getter and Setter
    ...
    
    //Helper methods
    int getLeft() {
    	return playerX + offsetX;
    }
    int getRight() {
    	return playerX + offsetX + width;
    }
    int getTop() {
    	return playerY + offsetY;
    }
    int getBottom() {
    	return playerY + offsetY + height;
    }
}

When using multiple hit-boxes it would be a nice idea to have a list (or array) of boxes.

Now one great thing to implement is a collision function like this:

//check if a point is within the hit-box
boolean isColliding(x, y) {
	return x > getLeft() && x < getRight() && y > getTop() && y < getBottom();
}

//check if a box is within the hit-box
boolean isColliding(left, right, top, bottom) {
	return (right > getLeft() || left < getRight()) && (bottom > getTop() || top < getBottom());
}

2.5.2. Damage-boxes

Damage-boxes are, like hit-boxes, not necessarily a box. They could be any shape, even a single point. I use damage-boxes to know, where damage is done. 

Here is an example of a damage-box:

damage_box.png.509207b6809c9fe7f7dfdd1bb1caaf67.png

The damage box does look exactly like the hit-box.

The hit-box differs a bit to the actual damage-box. A damage-box can have absolute x and y coordinates, because there is (most of the times) no need to update the position of the damage-box.

If there is a need to update the damage-box, you can do it through the setter methods.

class DamageBox {
	/*
    x = absolute x coordinate (if you do not want to update the coordinates of the damage-box)
    y = absolute y coordinate (if you do not want to update the coordinates of the damage-box)
    width = the width of the damage-box
    height = the height of the damage-box
    */
	int x, y, width, height;
    
    /*
    The damage the box will do after colliding
    */
    int damage;
    
    //initialize the damage-box
    DamageBox(x, y, width, height, damage) {
    	this.x = x;
    	this.y = y;
    	this.width = width;
    	this.height = height;
        this.damage = damage;
    }
    
    
    //Getter and Setter
    ...
    
    //Helper methods
    int getLeft() {
    	return x;
    }
    int getRight() {
    	return x + width;
    }
    int getTop() {
    	return y;
    }
    int getBottom() {
    	return y + height;
    }
}

2.5.3. Check for collision

If damage-boxes and hit-boxes collide, we know, the enemy receives damage.

Here is one example of a hit:

check_collision.png.951b28f084237338e7493a6d88e7bbde.png

Now we want to check, if the damage box collides with a hit-box.

Within the damage-box we can insert an update() method to check every frame for the collision.

void update() {
	//get all actors you want to damage
	actors = ...; //use a variable or have a global method (it is up to you, to get the actors)
	//iterate through all actors
	foreach(actor in actors) {
		//lets assume, they only have one hit-box
		hitBox = actor.getHitBox();
		//check for collision
		if(hitBox.isColliding(getLeft(), getRight(), getTop(), getBottom()) {
			//do damage to actor
			actor.life -= damage;
		}
	}
}

To get all actors, you could make a variable which holds every actor or you can use a method you can call everywhere which returns all actors. (Depends on how your game is set up and on the engine / language you use).

The damage box will be created as soon as the action phase starts. Of course you will have to destroy the damage-box after the action phase, to not endlessly deal damage.

2.6. Impacts

Now that we know, when to deal the damage, we should take a few considerations about how to show it. There are a few basic elements for us to use to make the impact feel like an impact.

2.6.1. Shake the screen

I guess, I am one of the biggest fans of shaking the screen. Every time there is some sort of impact (jumping, getting hit, missiles hit ground, ...) I use to shake the screen a little bit. In my opinion, this makes a difference to the gameplay. As usual, this may vary depending on the type of attack or even the type of game.

2.6.2. Stop the game

This may sound weird, but one great method for impacts is to stop the game for a few frames. The player doesn't actually know it because of the short time, but it makes a difference. Just give it a try.

2.6.3. Stun animation

Of course, if we got hit by a fist, we will not stand in our idle state, right? Stun animations are a great way to show the player, that we landed a hit.

There is only one problem. Lets say, the player is a small and fast guy. Our enemy is some sort of a big and heavy guy. Will the first punch itch our enemy? I guess not. But maybe the 10th one will.

I like to use some damage build up system. It describes, how many damage a character can get before getting stunned. The damage will build up by every time the character will get hit. After time, the built up damage reduces, which means, after a long time without getting hit, the built up shall be 0 again.

 2.6.4. Effects

Most games use impact animations to show the player, that he actually hit the enemy. This could be blood, sparkles, whatever may look good. Most engines offer particle systems, which makes the implementation very easy. You could use sprites as well.

2.7. Conclusion

By using the four phases, you can create animations ideal for a fighting game. You can prepare to avoid getting hit, you do damage, you can chain attacks and you have a smooth transition to the usual stance.

Keep in mind, the character can get hit at phases 1, 3 and 4. This may lead to cancel the attack and go into a stun phase (which i will cover later).

A simple way to check for damage is by using hit-boxes and damage-boxes.

3. Ways of avoiding damage

Now we are able to deal damage. There is still something missing. Something that makes the game more interesting... Somehow we want to avoid taking damage, right?

There are endless ways of avoiding damage and I will now cover the most important ones.

3.1. Blocking

Blocking is one of the most used ways to avoid damage (at least partially). As the enemy starts to attack (perception phase) we know, which attack he is going to use. Now we should use some sort of block to reduce the damage taken.

Blocking depends on the direction the player is looking. Take a look at this example:

blocking.png.f57db1edd381112e8700690eefa9d49e.png

If the enemy does an attack from the right side, we should not get damage. On the other side, if the enemy hits the character in the back, we should get damage.

A simple way to check for damage is by comparing the x coordinates.

Now you should think about how long the character is able to block. Should he be able to block infinitely? You can add some sort of block damage build up - amount of damage within a specific time the character can block (like the damage build up). If the damage was to high, the character gets into a stunning phase or something like that.

3.2. Dodging

Every Dark Souls player should be familiar with the term dodging. Now what is dodging?

Dodging is some sort of mechanism to quickly get away from the current location in order to avoid a collision with the damage box (like rolling, teleportation, ...) Sometimes the character is also invulnerable while dodging. I also prefer making the character shortly invulnerable, especially when creating a 2D game, because of the limited moving directions.

3.3. Shields

Shields may be another good way to avoid taking damage. Just to make it clear. I do not mean a physical shield like Link has in the Legend of Zelda (this would be some sort of blocking). I mean some sort of shield you do have in shooters. Some may refill within a specific time, others may not. They could be always there or the player has to press a button to use them. This depends on your preferences. While a shield is active, the character should not get any damage.

Keep in mind. You do not want to make the character unbeatable. By using shields which are always active (maybe even with fast regeneration), high maximum damage build up / block damage build up you may end up with an almost invulnerable character.

3.4. Jump / duck

These alternatives are - in my opinion - a form of dodging. The difference between dodging and jumping / ducking is, that you do not move your position quickly. In case of ducking, you just set another hit-box (a smaller one of course). While during a jump, you are moving slowly (depends on your game).

The biggest difference in my opinion is, jumping or ducking should have no invulnerable frames.

 

 

I hope you enjoyed reading and maybe it is useful to you. Later on, I want to update the post more and more (maybe with your help).

If you have any questions or feedback for me, feel free to answer this topic.

 

Until next time,

Lukas

Edited by LukasIrzl

Share this post


Link to post
Share on other sites

That sounds like a reasonable explanation of the collision and animation aspects, but you left out one very important point: fighting games are pretty much always built around a circular rock-paper-scissors aspect so that every attack has a counter and it is a mind game to anticipate what your opponent will do next.  The usual set is punch-block-throw (block stops a punch, throw ignores blocks, punch beats a throw), but you could presumably do other things, adding in more than three options, or having a different three actions.

David Sirlin (http://www.sirlin.net/) has a bunch of writing about the design of fighting game systems and balance.  You have probably seen his work, but if not, you should definitely check it out. Edit: He even implemented the punch-block-throw cycle as a turn-based card game called Yomi where both players select a move from their hands and lay it face down, then reveal them simultaneously.  It has combos, more and less powerful moves, the whole deal.  It's interesting to see that you can have the mind game without the reaction time parts.  IIRC you can try it for free with limited character choices both as printable PDF cards and in the online version.

Edit: Also (and this is minor) I think the tone of your piece could use a little work. It's not bad, but it feels a little amateurish with the vibe of "I experimented and thought things up and here are my ideas" when everything in it is pretty standard fighting-game mechanics. I couldn't find it in a quick search, but there's an article on the internet somewhere that covers almost exactly this same ground, using debug screenshots from one of the Street Fighter games (I think?) as examples. So some acknowledgement that you've done your homework and aren't just reinventing the wheel would make it feel more solid.

And the anticipation/windup frames add a delay between the button press and the actual action, so in games with network play it also serves the purpose of helping deal with network delay and reducing the chance that the game has to be like "Well...we showed you kicking him, but actually he punched you in the face three frames ago, we just didn't know it yet, so...sorry!".

Edited by JoshGrams
Added several more thoughts. Maybe should have been another post, but I'm assuming double-posting is bad?

Share this post


Link to post
Share on other sites

Thank you.

You are absolutely right. I did spend a little to few time for this aspect. In my opinion it is very important to think of counter attacks and assume what the opponent is going to do. The "mind game" as you called it. I will definitely spend a "chapter" on it.

Actually, I have never seen his work but I will check it out for sure. Maybe I will get ideas from him to implement and to write about.

Up to this point, I truly covered only the standard fighting-game mechanics and my thoughts about them. Later, I want to cover more aspects like gameplay, rock-paper-scissors aspect (which is in my opinion some sort of gameplay), and more which comes to my mind.

I will try to rework the tone of my piece. :)

In my opinion this thread should help me completing my combat system and help others with theirs. That's why I want to keep it as general as possible. (I hope it works ;))

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Forum Statistics

    • Total Topics
      628636
    • Total Posts
      2983968
  • Similar Content

    • By Dayze213
      Hello,
       
      I have been working on a level design asset for a 2D RPG and I was wondering what would be the best way to push the concept in order to get additional assistance with improving on the idea. I know that a prototype/demo of the level is a good start, and that is what I am working on currently, but with this being just an idea for a dungeon style level what other methods could be used to get others to see my work? 
    • By Nikola Tesla
      Just wondering the best method for selling concept art and 3D character models? Is there anything that I should be sure to include in my drawing model sheets? Like character name, artist name, or story synopsis.
      Also, what methods are best for advertising, promoting, and sales of game assets. Is there anything I need to know before selling a game or game asset? Is Unreal Engine Marketplace a good place to start selling game assets like 3D modeled weapons, armor or characters?
      Is it very hard to get a game onto Steam, or are there better platforms to start with selling a game? What is Steams policy for allow a game into its market?
      I do apologize for the broad topic and the scattered questions. If anyone could provide any insight to any of these fields it would be helpful. Also, tried and tested methods are much more enlightening than simply accepting a Google search answer.
    • By matrefeytontias
      So here's the deal : many many years ago, I saw screenshots of Miegakure, that very famous 4D puzzle-platforming game you probably all know about by now. The thing is, it never came out, not even a playable demo, except at big gaming events that I have no way to get to. As such, I decided a while ago that I had waited long enough and I decided to start working on my own mathematically accurate 4D rendering engine.
      Without going too deep, the point of it is that 4D objects live in 4D space, and the so-called 4D camera just cuts a 3D slice of the 4D space and of every 4D object in it, which is then passed to your regular run-of-the-mill 3D engine to display. Doesn't sound like anything too hard then.
      The big problem however comes from optimisation. In 3D engines, you expect your geometry to never change ever, allowing for a lot of cool stuff like GPU caching and the like, and is usually pretty vital for performance. However in a 4D engine, the thing that never changes is your 4D geometry, not the 3D geometry that results from the cutting (that in fact changes every frame). The more mathematically inclined will also think about spatial complexity, since in 4 dimensions you have "a lot more space" to put objects in (purposefully keeping it vague). Moreover, I don't want to go through the trouble of building an actual 3D engine, because a lot of existing engines do that a lot better, and I would probably waste all of my time and motivation working on 3D instead of 4D.
      As a demonstration, my very first demo uses Three.js and is basically a 4D enigma : http://mattias.refeyton.fr/PAF/slicing . The goal is to get to the other side of the wall where the green cube is, knowing that the wall is too high to jump over and that you can't go around it. You can use ZQSD to move (French keyboard, sorry), and A and E to look "ana" and "kata", which are the 4D equivalent of left and right. You'll excuse the roughness of the whole thing, as it was done in 5 days for a school project (it was the perfect opportunity). This has only been tested on Firefox and Chrome.
      Hence my question : what do I use as a foundation to work on this ? I'd like to use either C, C++ (for performance) or Haxe (for the multiple targets), if that gives any leads. Of course, doing it from scratch is a totally valid answer, as I would be able to include many 4D-only things (such as 4D lighting and other cool shit) that I'm having trouble seeing how I could implement them in an existing engine. Another thing to take in consideration is that there's probably going to be a 4D physics engine to come with it, and that I'm not sure how hard or easy making that work with an existing 3D engine would be.
      Also I'm killing two birds with one stone by asking if anybody would be interested by a stream of this. I'm planning to eventually stream my work on this, which would include math on blank paper, and heavily mathematically-inclined discussion, not just coding (relatively little coding in fact).
    • By ConsolaLarry
      This will be my third thread here, and I'll celebrate for being....engage in a forum community for this much by....er....ah yes, thanking everyone that has helped me in my previous two thread, esp to Kylotan for nuking my mistakenly submitted thread, also for the friendliness and patience of everyone toward me, a complete n00b. :confetti:
      As I've mentioned before in my previous threads and in the above paragraph, I know nothing. So I thought to myself: At least don't just sit there waiting for Jesus to come down and bless you with programming skills and do something! Thinking that, I wrote /have been writing out my ideas for my game while looking for pirated udemy courses (I'm broke btw fyi). The game is a big one, and it being my first game ever, lead me to thinking: "Maybe I'm taking more than what I can chew" after reading tips that can be generalized into "Making small game frequently first, then tackle big ones". But I plan to work on this game for quite a long time in a part-time manner
      Then it hit me. Most of the features I planned to include in the game is already there in, if not, have high similarity to, other games that I played and am playing. The thing is, most of those games are backed by companies like KOG Games, and other company that can...hit me with a copyright report. Why.....
      TL;DR: I think I picked the wrong to start my game making path, my game may get hit with copyright reports
      Again, I need advices, on these questions:
      - Am I taking the wrong path? I think I am taking the wrong path....
      - Should I be too worried on copyrights? If yes, how should I deal with it, tweaking the game or play "Dodge the Bullet"?
      Also, here is my game idea, at:
      Is this okay? Is there anything I can add in to spice things up or cross out? Also, I have an under-average skill in English so, if there are any clutter in my writing, let me know so I can clarify it to you.
       
      Again, thank you you guys so much! >~<)/
  • Popular Now