The first boss I ever designed was a giant stone golem that hit hard and had a lot of health. That was it. That was the entire design. It would walk toward you slowly and punch the ground. The playtesters called it "The Big Sad Rock." Not because it was too hard. Because it was boring. It had size but no personality. It had attacks but no language.
A boss fight isn't just a tough enemy. It's a dramatic moment in your game — a punctuation mark at the end of everything the player has learned so far. The best boss fights feel like arguments: the boss makes a claim about what this game is about, and the player proves they understand it well enough to win. The worst boss fights feel like errands.
This is how you design the first kind.
A Boss Is a Test, Not Just an Obstacle
Before you design any specific attack or health bar, answer this: what is this boss testing? If the game has been teaching the player to dodge left, the boss should force them to use that. If the game has been about resource management, the boss fight should stretch those resources. If the game has been about reading enemy patterns, the boss's patterns should be the final exam.
This is the single most important principle in boss design and the one most beginners skip entirely. They design the boss as a standalone encounter instead of as the culmination of what came before. When the boss tests skills the game has been building, beating it feels earned. When it doesn't, it feels arbitrary — a random difficulty spike that has nothing to do with the game you've been playing.
Before you open your engine, write one sentence: "This boss tests the player's ability to ___." Then design every mechanic around that sentence.
Phases: How to Build a Story With Attacks
A boss fight with one phase is a long enemy fight. A boss fight with two or three phases is a story.
The best boss fights change. Not just "gets faster at 50% health." They genuinely transform. Flowey becomes Omega Flowey. Margit becomes staggered and desperate. Ganon's second phase is a different argument entirely from the first. These transformations communicate something about the boss: their desperation, their true form, the thing they were hiding.
Phase design doesn't need to be complex. Here's a simple three-act structure for a beginner's first boss:
- Phase 1 — Introduction: Slower attack patterns. The player learns the boss's vocabulary. What does each attack look like? What's the tell before the charge? This phase should feel manageable once understood.
- Phase 2 — Escalation: Faster, more frequent, or more demanding versions of the same attacks. Maybe a new attack that combines two patterns the player already knows. The player is being quizzed on what they learned in Phase 1.
- Phase 3 — Desperation: The boss breaks its own patterns. Faster transitions, shorter windows, possibly a screen-filling attack that forces the player to do something they've never done before. This is the moment of maximum tension right before the end.
The key is that each phase should feel like a response to what the player just did. The boss didn't plan Phase 2 from the start; Phase 1 ended because the player hurt it. You're building a fight that reacts, not one that runs a script.
Telegraphing: The Contract With Your Player
Here's the thing about boss attacks: they need to be survivable. Not easy. Survivable. And for an attack to be survivable, it has to be readable before it lands.
Telegraphing is the visual or audio signal that precedes an attack. A sword raised above the head before a downswing. A deep inhale before a fire breath. A red glow on the fist before a ground slam. Telegraphs give the player time to react. Without them, attacks feel random and deaths feel unfair.
The gap between the telegraph and the attack is where the game lives. Too short and the player can't react — it becomes a test of pattern memorization rather than skill. Too long and the boss feels sluggish. The right window depends on the attack's severity. A one-hit kill needs a long, obvious telegraph. A minor chip damage hit can be fast. As a rough guide: attacks that deal 10% of health need about 0.3 seconds of telegraph. Attacks that deal 50% need closer to 0.8 seconds.
Distinct telegraphs also teach the player which attacks to prioritize. A big windup means a big attack — dodge it. A quick flash means chip damage — maybe worth taking if you're mid-combo. Players learn to read your boss's body language, and that reading skill is what the fight is actually testing.
The "Oh No" Window
One of the most satisfying feelings in a boss fight is the moment right before you win when you have a narrow escape. You're at low health. The boss is at 5%. You dodge one more attack, land the killing blow, and exhale. That near-death at the end isn't an accident. It's designed.
Good boss design accounts for the "oh no" window — the stretch of the fight where the player realizes they're going to win but isn't sure they'll survive to do it. You create this by making Phase 3 genuinely dangerous even to players who've learned the fight well. It should be possible to lose in Phase 3 after comfortably handling Phase 1. That possibility is what makes the victory feel like survival, not just completion.
Calibrate by playtesting with players who already understand the first two phases. If they find Phase 3 trivial, add pressure. If they consistently can't finish it after learning the earlier phases, dial it back. The target is one or two close calls per attempt for an experienced player.
Giving a Boss Personality
Mechanics alone don't make a boss memorable. What makes Sephiroth memorable isn't his moveset — it's that he uses Masamune, moves with uncanny calm, and feels like he's barely taking you seriously. What makes Flowey memorable is that he shatters the fourth wall. What makes Genichiro memorable is that he's the game's thesis statement in humanoid form.
Every boss should feel like it exists for a reason beyond blocking the path. It should embody something. A boss in a game about trust could be an ally who turned. A boss in a game about memory could attack by erasing your moves. A boss in a game about control could be a mirror of the player's own power, grown too large.
You don't need a big budget to give a boss personality. Personality comes from:
- A theme that connects to the story. Not just "fire boss in fire world." A character who uses fire because they burned down something important, and they know it.
- Distinctive movement vocabulary. The way a boss moves before it attacks tells you who they are. An arrogant boss circles slowly. A desperate boss rushes. A grief-stricken boss hesitates before striking.
- Reaction to damage. Bosses that stagger, recoil, or change behavior when hurt feel alive. Bosses that just lose health feel like vending machines.
- A death that means something. When the boss goes down, what happens? An explosion? A collapse? An outstretched hand? The death animation is your last line of dialogue in the conversation.
The Fair Challenge Problem
Here's the tension at the center of boss design: the boss needs to be hard enough to feel like an achievement, but fair enough that the player understands what they did wrong when they fail.
Unfair difficulty feels like bad luck. The attack came from off-screen. The telegraph was too subtle to read in time. The hitbox extended further than the animation suggested. Dying to unfair mechanics doesn't teach the player anything — they just die again the same way, increasingly frustrated.
Fair difficulty feels like skill being tested. The player sees the attack coming, times the dodge wrong, takes damage. They know exactly what happened and exactly what to do differently next time. Every death is a lesson, not a punishment.
The checklist for fair boss design:
- Every attack has a visible or audible telegraph with enough time to respond
- Hitboxes match the visible animation exactly (no invisible extended reach)
- The player can fail in a way that teaches them what to do next time
- There's no attack that's unavoidable on first encounter unless it's intentional (and even then, it should be survivable)
- The player can always tell how much health the boss has remaining
The last point is more important than it sounds. A visible health bar lets the player make strategic decisions: should I play safe now that they're at 20%? Should I push aggressively? A boss with no visible health bar creates uncertainty that tips into anxiety. Sometimes that's intentional design. Usually it's just frustrating.
Prototyping Your First Boss
Don't start with the full boss. Start with one attack.
Build the telegraph for one attack. Test that it's readable. Build the attack hitbox. Test that it's fair. Then build the counterplay window — the moment after the attack where the player can strike back. Get that one exchange feeling right before you add a second attack.
A boss with two well-designed attacks is infinitely better than a boss with eight attacks that each feel off. Complexity can come later. Feel comes first.
For rapid prototyping, visual engines like GDevelop or tools like Chatforce, GameMaker, and Godot all let you build and test basic boss encounter logic quickly without getting buried in engine overhead. The goal is to get the one-attack exchange in front of a player, watch whether it teaches or frustrates, and iterate from there. Speed of testing matters more than speed of building.
A Note on Checkpoints
One of the most debated design decisions in boss fights: should there be a checkpoint inside the fight itself?
There's no universal answer, but here's the framework I use. A multi-phase boss that takes more than five minutes to reach Phase 3 should have a mid-fight checkpoint, or at least some progression carry-over between attempts (like a boss that remembers how much damage it took). Forcing a player to replay ten minutes of Phase 1 to reach Phase 3 again isn't difficulty. It's a time tax.
Celeste checkpoints aggressively. The game is hard, but you're never set back more than about thirty seconds. Dark Souls has no checkpoints inside fights, but the fights are short enough (most under four minutes) that retrying feels acceptable. The thing both games avoid is the worst outcome: a long fight with no checkpoints and a slow journey back to the boss after death. That combination kills motivation faster than any difficulty spike does.
After the Fight: The Landing
The boss dies. Now what?
Too many games treat the post-boss moment as a logistics issue: drop the loot, unlock the door, move the player to the next area. That works, but it wastes the most emotionally available moment in the entire game. The player just survived something hard. Their adrenaline is up. They're invested. What do you want them to feel right now?
Great boss endings do one of three things. They reveal something (a cutscene, a message, an item that recontextualizes what you just fought). They close a loop (the boss's death solves a problem established earlier in the game). Or they open something new (a door opens to a place you've been building toward).
Give the player a beat. Don't rush them to the next room. Let the music swell or fall silent. Let the camera linger. The emotional resonance of a boss fight isn't just in the fight. It's in the breath after it ends.
Your Big Sad Rock
I redesigned that golem boss. I gave it a phase where it shed its stone armor when hurt, revealing the cracked clay underneath. In Phase 2 it moved differently — slower, but angrier, dragging one arm. Its death wasn't an explosion. It just collapsed. Slowly. Like something exhausted.
The playtesters said that version felt sad, in a good way. One of them said they almost felt bad for it. That's the kind of feeling a boss can produce when you give it something beyond a health bar and a punch animation.
Start with one well-telegraphed attack. Add a phase when the player hurts it. Give it movement that reflects its personality. Build the fight as a test of what your game has been teaching. And give the ending a moment to breathe.
That's the whole thing. The Big Sad Rock was just waiting to become something better. Yours probably is too.
