Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Planning the System

What's in an attack?

If you've been around games long you're probably familiar with the term hitbox. Hurtbox, maybe not so much, it's generally used in the fighting games community. A hurtbox is some sort of collider on an entity that determines where it exists in physical space to possibly be hurt by things. A hitbox is the same, but it is something that deals damage to hurtboxes when the two overlap.

So if your fireball's hitbox overlaps an enemy's hurtbox, the enemy is hit by the attack and takes damage. What about a melee attack? When you swing a sword, at some point in its animation its hitbox becomes active for some amount of time, and then disables itself.

Both are instances where a hitbox doesn't exist/is disabled, becomes enabled for some period of time, and move over some period of time, before being disabled due to some condition. In other words, they are identical. Because we're primarily a game where the hitboxes we turn on for a bit and then disable are in the form of projectiles, well, we're going to call them all projectiles.

The Shape of a Projectile

A Projectile needs the following elements:

  1. Hitbox - How big is the active hitbox of the projectile, and what shape is it?

  2. Visualization - what does the projectile look like? Do the visuals need to be animated? Does it have a trail of some kind? Is there an effect that plays when the projectile hits something / ends its existence?

  3. Lifetime - How long does the projectile stay in existence? How many things does it have to hit before it dies?

  4. Interaction Behavior - What happens when it hits something? Can it hit the same thing more than once? What can it hit, and how much damage does it do to them?

  5. Movement - How does it move? How much velocity does it have, in what direction, and does that change over time?

  6. Sound - Does it play a sound as its alive? Does it play a sound when it hits something? Given that Bloop doesn't currently do sound on native, we can skip worrying about this for now.

This may sound like a lot, and maybe it is! But these are the kinds of things you have to think about as a game dev.

So if we've described what an attack is at its core, how does it get summoned and appear?

Pattern

When a unit does an attack, at some point it needs to control when and where it spawns projectiles. A pattern needs to know the following:

  1. Timing - how long does this pattern last for? Is it instantaneous? Does it fire a few projectiles over a short burst?

  2. Projectiles - What projectiles to spawn (with all of their individual considerations), where to spawn them, and when to spawn them? Do they have some variance to their directionality (aka lower accuracy) or are they fired at an angle?

Our patterns determine what projectiles to spawn, and when and where in relationship to themselves, but what determines when a pattern starts?

Attacks and Attack Phases

Our next layer is the Attacks themselves. An attack in a game typically consists of multiple phases, so we'll be architecting them around this. Our Attacks will just be:

  1. An array of Attack Phases that get executed in order
  2. an interrupt behavior for what happens if interrupted
  3. A cost, such as how much ammo this attack requires.
  4. While technically it could just be another attack phase, we're going to separately have an attack cooldown here, how long before the attack can be used again.

Traditionally attacks have a windup phase, the time it takes before an attack happens, like a fighter pulling their fist back before punching, or an energy weapon charging up before shooting out its projectile. Then we have our active time when the attack is being performed. This may not even last a single frame for a gun, but for a punch it might last for multiple. Finally we have our recovery phase, which determines how long after doing the attack the combatant takes before having control again. Once again, this may be super short to immediate for a gun, but maybe longer for a melee attack.

For instance, a shotgun might have a 0.1s windup (raising the gun), 0.0s active (instantaneous), 0.3s recovery (recoil animation), spawning a Pattern that creates 8 Projectiles in a cone.

|--Windup--|--Active--|--Recovery--|--Cooldown--|
            ↑
         Pattern spawns projectiles here

Our Attack Phases will need the following:

  1. Duration - How long they last
  2. Pattern(s) - What patterns to spawn and where at the start of their phase.
  3. Audio/Visuals - Any sort of audio or visual effect that accompanies the attack phase?
  4. Animation State - to communicate with the thing performing the attack what animation state to take.
  5. Interruptable? - an enum, whether or not the phase can be interrupted, interrupted only by being hit, or interruptable by being hit and cancelable by the user performing an action (and what actions can cancel it).

This then begs the question, what is the thing that performs these attack made up of attack phases?

Weapons

Weapons initiate attacks, a series of attack phases, each of which may summon patterns of projectiles.

This is finally where we stop aiming to be completely universal and need to get pretty game specific. For our game a weapon will need the following:

  1. Visuals - what does the weapon look like? does it have animations (that then sync with attack phases)?
  2. Attack - what attack does it perform? Where does this attack originate in relation to the weapon's art? Other implmentations may want to allow for multiple attacks triggerable by multiple buttons, ie a left click attack and a right click attack.
  3. Resources - how much ammo can it hold at maximum? How much is in a clip?
  4. Reloading - How long does it take to reload? When is the active reload window and what's the punishment time for failing? What feedback accompanies the reload?

With all that settled, who uses weapons?

Combatants

Not every combatant needs every thing here, and our system is flexible enough to allow them, but we'll want to have the following associated with our player and (most) enemies:

  1. Hurtbox - How big is their hurtbox and what is its shape? If we have some kind of invulnerability on hit (which we will), how long after taking damage does it take to become enabled again?
  2. Health - How much health do they currently have? What's their maximum health? What happens when they reach 0 health?
  3. Weapon(s) - What weapon(s) do they have and how do they use them?
  4. Modifiers - An attack modifier that multiplies damage dealt, a defense modifier that multiplies damage taken

After all that, we can finally consider our combat system fleshed out. Of course, to make it engaging we'll need enemy AI, but that's coming in chapter 4. For now, we should get this show on the road and implement our first and most important step: projectiles.