Designing a Realtime Combat System

Combat in action RPGs seems simple; avoid enemys attacks while dishing out your own but even a simple system is made up of many design decisions! In this article I'll cover the most important decisions you need to make when designing combat. I don't see many people talking about these systems, so I hope this sparks some conversation! These are my notes from the frontlines - problems I've encountered and navigated but make no claims to have solved.

This article is about melee combat foremost. A combat system that focuses more on ranged weapons has similar but different constraints.

What's It All About?

This article covers realtime combat. That is combat without "turns". Time passes continuously and characters are free to move and attack as they wish. We'll be talking about combat that occurs on a 2d plane (even if the models are 3d). We're not dealing with FPS-style combat with rich, multi-level 3d environments.

Combat on a 2d plane is all about controlling space. By space I mean where the player can move now and where they'll be able to move in the future. The player has two objectives:

1. Defeat enemies
2. Don't get hurt

To meet these objectives, a successful player must be aware of the combat space. The player needs use and manipulate the space as best they can. Practically this means things like:

• Lure harder enemies away and dispatch them separately
• Avoid situations where you'll get swarmed by enemies
• Avoid getting boxed into a corner
• Look for the places that give you breathing room on the battlefield

If you think about combat in terms of controlling space then it's easier to design interesting gameplay mechanics; timed bombs, creatures with sweeping laser-style attacks, creatures that spawn smaller creatures when they die etc.

How hectic your combat feels is controlled by how difficult the space is to navigate. If you don't want a hectic game then lower enemy counts.

Decisions

The most important combat systems decisions are covered below. Be aware you can't design this totally on paper - you will need to prototype and tweak.

Enemy Speed

1. Can enemies be faster than the player?

If enemies are faster or the same speed as the player then the player can never disengage from combat. This means when an enemy turns aggressive, the player must fight to the death and is unable to run away. This leads to situations where the player cannot win and is just waiting to die. That's not fun.

From a design perspective, you want to stop the player being able to run past all enemies to the end of the game. Don't solve this by making the enemies fast; find a different solution. Enemy patrol paths, stationary enemies etc. are all worth investigating. Notice that in "Zelda: A Link to the Past" when the player is exploring a dungeon, they are often locked in a room until all enemies are dispatched.

This doesn't mean fast enemies are forbidden! They just need designing the right way.

• Make fast enemies a one-hit kill or make them die on collision with the player.
• For stronger enemies prefer special fast states with a long cool down such as dash attacks, chase patterns etc. Special states with appropriate animations and effects make it clear to the player something special is happening that can be anticipated in the future.

Don't add a simple stamina system to your enemies. Giving enemies stamina sounds like a good solution, when the enemy runs they deplete stamina - problem solved! Unfortunately it doesn't work. Stamina is too fine-grained and hard to communicate to the player. Prefer special fast states. Special states with a cool-off are also easier to balance than a recharging stamina bar.

Invincibility

1. When hurt does the enemy go invincible for a short time?
2. When hurt does the player go invincible for a short time?

Games usually indicate invincibility by flashing the player sprite on and off, or flashing the player sprite white or red. Granting a few seconds of invincibility after being damaged, gives the player time to escape the damaging situation. It's a good way to avoid endless damage-loops and frustrating deaths. If it suits your game, then invincibility is a good idea for the player.

Invincibility for normal enemies is a bad idea. You may want to stop the player running at enemies and spamming the "attack" button, killing the enemy before they can react but adding a period of invincibility is dangerous. Let's take an example:

• The player hits the attack button
• The enemy is hit and goes invincible for 1 second
• The player hits the attack again
• The attack passes through the enemy because they are invincible
• The enemy stops being invincible
• The enemy hits the player

This kind of situation feels very unfair. It can feel even worse if the player didn't trigger the creature's invincibility directly. The creature might have taken environmental damage (lava) or a blast from a bomb, causing them to go invincibile and ignore the player's attacks.

Things get even worse if you allow enemies to attack while they're invincible. It feels terribly unfair. The same goes for causing an enemy going invincible due to collision damage. The only invincibility worth implementing is per-attack, if the player swipes a sword at the enemy, it will hit the enemy over the course of several frames, only the first hit per attack should be counted!

Knockback

1. When a player takes attack damage are they knocked back?
2. When a player takes collision damage are they knocked back?
3. When an enemy takes damage are they knocked back?
4. Can an enemy or player be knocked back, while they're already being knocked back?

Let's first consider player knockback: what role does it perform in a game?

• Moves the player out of harms way (especially if there's collision damage)
• Acts as a punishment for messing up (usually removing control)

It's fine to have knockback for the player but it's best done with invincibility. The longer the player is in knockback, the more annoying it is. For an action RPG don't let the player take additional damage while in knockback, also don't fire-off another knockback while in the knockback state. You don't want to get into an endles loop of the player bouncing around the screen!

The role of enemy knockback:

• Stops the player attack spamming the enemy to death
• Makes the player "chase" enemies to kill them
• By definition interrupts enemy attacks

Personally, I'd avoid knockback for enemies apart from under special circumstances - at the end of a special combo attack for instance. I find it hard to make chasing the enemy around feel good. But if all enemies are a couple of hits to kill then it's not so bad.

If you chose to have enemy knockback then the enemy should never go invincible and they should be able to be knocked back even while in the knockback state. While in the knockback state think carefully if you want enemies to deliver collision damage.

Castlevania: Circle of the Moon, pictured above has some serious knockback going on, also note the flash to indicate invincibility. The knockback distance is very game specific and depends on player speed and the ratio between avatar size and world shown on screen. In most action RPGs the knockback distance would be less than Castlevania.

Collision (and Blocking)

1. When a player walks into an enemy does he take damage?
2. Do enemies take damage when they hit the player?
3. When enemies walk into each other do they take damage?
4. Can enemies pass through enemies?
5. Can the player pass through enemies?
6. Can the enemies pass through the player?

If you're making a side scrolling game then player-enemy collision damage is expected. Otherwise you're free to do whatever feels right for your game. Collision damage matters most when used with knockback. Taking additional collision damage while being knocked back is usually bad.

Consider only having knockback for attack damage. Ensure your player character can't get trapped in a corner by an enemy, in a endless damage-loop they can't escape.

It's worth looking closely at how existing games handle this type of thing. (2d scrollers like Castlevania do have player-enemy collision damage AND knockback AND allow the player to receive collision damage again while in knockback! But it works for that game).

In regard to blocking, a good rule of thumb is that the player cannot normally pass through enemies. Enemies may pass through the player if they have set "patrol paths" or set movements. Enemies should not pass through the player if they have more dynamic movement such as a seeking behavior. While enemies are in a knocked back state, let them pass through other enemies, as in practice this works well.

Attack Animations

1. How long is the lead-in?
2. How long is the lead-out?
3. Can the player cancel an attack?

In action RPGs and combat heavy games - animation cannot be added later, it cannot be an after-thought! It has a massive affect on gameplay, both for the PC and enemies.

The lead-in is the amount of time between the user hitting the "attack" button and the attack hitbox being active in the world. In some games this is almost instant, you do the attack, the character snaps to a pose with the sword outstretched to cause damage in the very next frame. In other games the attack can take time, the player might take their sword out of their sheath, then raise it above their head and bring it down infront them. The lead-in could be up to half a second long. The longer the lead-in the more frustrating your game will be to play.

During the lead-in period the player may receive damage. It's often part of gameplay to correctly time attacks so you inflict damage but don't receive it.

Avoid overly flashy animations. The player will be attacking a lot, keep it simple and short.

Keep lead-in consistent. The lead-in should be a fixed time. The player shouldn't, for instance, occasional resheathe their sword, then if the sword is sheathed the attack takes longer, because the player has to get it out. In an action RPG, this doesn't feel good and distracts from the core gameplay.

After defining lead-in I'm sure you can guess what lead-out is! Lead-out is the time between the attack causing damage and resetting to the idle state, ready to attack again. Again, lead-out shouldn't be too long and it should take a consistent length of time.

It's ok to prevent the player cancelling an attack. You're taking away a little autonomy but it's also sending a message - in this game, an attack is something you commit to and you need to consider that going forward. Frustration happens if the lead-in and lead-out are so long the player may take damage without being able to anticipate it. For example if the lead-out has a sword cleaning animation, blocking player input, it's not going to feel good if an enemy runs in, attacks and causes damage.

Consider only having a very short lead-in or lead-out and having it's complement animation take a little time.

The animation doesn't have to show EVERY frame. Look at how other games work, they often snap to attack poses in a single frame, this gives a real sense of speed and power.

Interrupt

1. When hurt does the enemy cancel it's attack?
2. When hurt does the player cancel they're attack?

Let's say you're fighting a troll with a big club. Trolls are slow. A troll's main attack is to draw the club over it's head in both hands, then smash it down. What happens if the player hits the troll during it's lead-in animation? If attacks interrupt then the troll's attack is cancelled and it plays a flinch.

If the player has a very fast attack speed then they can approach an enemy and spam the attack and win automatically. Every time the enemy begins their attack it will be cancelled by the interrupt. Strategies for avoiding this situation include:

• If the enemy starts an attack, they finish it, unless they're killed
• Only certain weapons interrupt (one's with slow attack rates!)
• After being interrupted enemies have a fast counter attack
• Enemies visibly flinch but it's blended on top of the attack anim

As for the player being interrupted - either decision can work well depending on the game. If the player knows their attacks can be cancelled when they get hit, they'll approach combat more cautiously.

Flinch

1. How does the player know when they're damaged?
2. How does the player know when an enemy is damaged?

Combat events are telegraphed to the user via animations and special effects. One of the most important events for the player to know about is when they or an enemy has taken a damage.

This may be a grimace, or a blocking animation such as the enemy throwing their hands up. It should be very short - less than the length of time it takes the player to attack again. It's best avoid a situation where the enemy is caught in cycle of being hit and playing the grimace animation again and again.

The player should be able to interrupt their grimace animation at anytime - by moving or attacking. If you want the player to be incapacitated after being hit, it's less problematic to handle it with a small knockback. It's bad for an enemy to be caught in a grimace-damage loop but it's far worse to let this happen to the player.

If damage is taken while in the grimace state then I'd acknowledge the additional damage with a particle effect, or flash but not reset the grimace animation, or play another one after, just let the current one play out then go back to normal.

Priority

1. When two attack hitboxes collide how is priority decided?

This happens occasionally usually depending on how you score a hit in combat. I would normally favor the player in this situtation. Or if you have the manpower to spare; a neat clash animation that resets both attacks.

Balance

The three elements that need carefully balancing are knockback, invincibilty and interrupts. They should be balanced differently for the player and the enemies.

Rules of Thumb

Here's are the decisions I'd make for a simple action-RPG.

For normal non-boss monsters: - No invincible state after taking damage - Monster attacks cannot be interrupted (apart from by death) - No knockbacks (or limit to special weapons / attacks)

For the player: - Have an invincible state after taking damage (no animation, just a flash) - Enemy attacks may interrupt the player - If you have collision damage then have knockback. Otherwise test and see what you prefer. - The normal attack hit box should minimally extend ~1 player unit (i.e. width of the player) forwards.

The fact that the player cannot interrupt monster attacks means player attacks need to be timed carefully. This makes monsters a little dangerous and not something that can just be mown down.

Stat Balancing

When balancing health, instead of thinking in numbers - like the player does X damage and the monster has Y hit points. It's easier to think in terms of number of hits to kill. One enemy might be one hit to kill, one might take five etc.

Some Thoughts about Automony

Sometimes games need to lock-off player control and ignore all inputs. For instance, the move buttons may be ignored while an attack animation plays.

It's fine to occasionally remove control from the player, provided it's done in a predictable, consistent and fair way.

If the player decides when control is taken away, it can even be fun! Think of pinball; you wait for your moment, fire off the ball and then you mostly sit back and watch. But it's still fun!

Many fighting games have powerful moves that have long lead-in animations but the risk is clear so it doesn't feel unfair if it doesn't work out.

See Yoshimitsu's impale attack from Tekken, shown above. During Yoshimitsu's lengthly lead-in animation, the player is vulnerable but if timed correctly it's a very strong attack.

Blocking input feels bad when it happens without much choice. For instance, if a player is knocked back, then locking the controls can feel overly punitive.

A Few References

These games are worth studying to see how they handle combat and the decisions they've made:

• Zelda (any)
• Castlevania Symphony of the Night (even though it's side-on 2d)
• Dynasty Warriors
• Mount and Blade
• Dark Souls
• Diablo
• Secret of Mana
• Ys

Next Actions

Decide what kind of combat suits your game. Is it a light-hearted button-mashing romp, or a more tactical, "every-move-counts" type of game? Then make your combat system decisions. Make a prototype and begin the long process of iteration. Once you have a system that feels good then you can add more layers. Layers include things like armor, resistances, ranged weapons etc. Your imagination is the only limit!