Chapter 26 Exercises — Combat Design

These exercises move from observation to design to implementation to critique. Plan to spend 8-12 hours across the four, more if you go deep on the implementation. Combat design rewards time spent actually doing it; reading about it only gets you to the starting line.

Throughout: when the exercise asks for numbers, give numbers. "The attack feels slow" is useless to another designer reading your work. "The attack has 23 frames of startup, which is 383ms at 60 FPS, nearly double the typical light-attack 10-15 frames in comparable games" is a design document.

Exercise 26.1 — Analysis: Frame-Data a Fight You Own (★★☆☆☆, ~2 hours)

Pick a game you own that has real-time combat — any genre, any perspective, any level of realism. Choose a single enemy or boss encounter that you can re-enter repeatedly. Then measure it.

What You Will Produce

A one-page frame-data document containing:

  1. A named list of every attack this enemy has in the encounter. If it has three attacks, list three. If you think it has two but on your fifth attempt you see a third, correct your list. Be exhaustive.
  2. For each attack, measured values of: - Startup frames (from first animation movement to first damaging frame) - Active frames (how long the hitbox is live) - Recovery frames (from end of active frames to when the enemy can act again) - Tell signal (animation, VFX, audio — what does the attack look and sound like before it commits?) - Damage (as a fraction of player max HP, or a rough HP number)
  3. A short paragraph on the attack's purpose in the encounter. Is it pressure? Spacing? A high-risk commitment the player is meant to punish? Filler?

How to Measure

Most games do not expose frame data. You will need to estimate, which is part of the exercise.

  • Record video of the encounter. A phone pointed at the screen is fine, but screen-capture (OBS, ShadowPlay, the PS5/Xbox built-in recorder) gives you frame-accurate stepping. Sixty-FPS capture is ideal; thirty-FPS capture still works — just double your frame counts for the 60-FPS-equivalent estimate.
  • Step frame-by-frame through the attack using your player. VLC's e key advances a single frame; most video apps have a similar shortcut.
  • Count from visual events. The first frame of noticeable wind-up movement is frame 0 of startup. The first frame where the weapon visibly intersects the player's model (or where the on-screen hit confirmation shows) is frame 0 of active. And so on.
  • Sanity-check with repeated attempts. Measure the same attack three times. If your counts vary by more than 2-3 frames, you are miscounting the boundaries; pick clearer reference events.

Analysis Prompts

After your table, answer these in prose:

  • Which attack is the most dangerous and why? Highest damage? Longest active window? Shortest tell? Most frequent?
  • Which attack is the player's best punish opportunity? Longest recovery? Most predictable rhythm? Widest safe angle?
  • What is the rhythm of the encounter? Does the enemy cycle through attacks on a clock, or react to the player, or a mix?
  • What would you change? One specific frame-count adjustment you think would improve the fight, and your justification.

Deliverable

A 500-800 word document with a table of frame data and the analysis prose. Include at least one annotated screenshot showing a tell and calling out the distinguishing visual signal.

Practitioner Note: This is the exact exercise combat designers run in professional studios, usually on a competitor's game before starting their own. If you do this well, you will see combat differently for the rest of your career. Most players feel combat; combat designers measure it.

Exercise 26.2 — Design: Sketch a 3-Phase Boss (★★★☆☆, ~3 hours)

Design a boss fight you would put at the 60% mark of your 10-hour action-adventure game. This is the game's mid-climax — not the final boss, but a memorable milestone. You have three phases to work with. The player has encountered the boss once before in a cutscene and knows their name.

What You Will Produce

A boss design document covering:

Section A: Concept (1 paragraph)

  • Who is this boss narratively?
  • What is the player's fantasy of defeating them? (The emotion you are selling, not the mechanic.)
  • What thematic or visual identity holds the three phases together?

Section B: Arena (1 paragraph + sketch)

  • Describe the physical space of the fight.
  • Include a top-down sketch (hand-drawn, digital, or a whiteboard photo) showing dimensions, cover, hazards, and the boss's typical position.
  • Justify each geometric feature: why is that pillar there? Why does the arena have an edge the player can fall off, if it does?

Section C: Phase 1 Moveset (1 page)

List every attack the boss has in phase 1. For each:

  • Name (something designers and QA can say out loud — "overhead slam," not "Attack_03")
  • Startup / Active / Recovery frames (target values, not measured)
  • Damage (as a fraction of player max HP)
  • Telegraph description — the animation, VFX, and audio cue that warns the player
  • Player response — what the player is supposed to do in response (dodge direction? parry timing? retreat?)
  • Punish opportunity — after the attack ends, how long does the player have to strike?

Include at least 3 attacks. Include at least one that has a long tell and big damage (teaches patience) and one that has a short tell and small damage (rewards aggression).

Section D: Phase Transition 1 → 2

  • What HP threshold triggers the transition?
  • What happens visually, cinematically, and audio-wise during the transition? How long is it?
  • Can the player take damage during the transition, or are they safe? (Justify.)
  • What new information does the transition communicate to the player?

Section E: Phase 2 Moveset (0.75 page)

The design rule: phase 2 should combine familiar attacks (possibly faster) with one new attack that extends the boss's vocabulary. Not two new attacks. One. This is a specific guideline drawn from Team Cherry's Hollow Knight bosses and Team Ninja's Nioh bosses.

  • Restate or modify each phase 1 attack with new frame data if tightened.
  • Introduce the one new phase-2 attack with full frame data, telegraph, and player response.

Section F: Phase Transition 2 → 3

Same structure as Transition 1. But consider: by phase 3, the transition should feel like "the gloves are off," not "here's another attack to learn."

Section G: Phase 3 Moveset (0.5 page)

The design rule: phase 3 should almost never introduce a mechanic the player hasn't seen. The player's job in phase 3 is execution, not learning. Exceptions exist — Hollow Knight's Radiance introduces new patterns in her final phase — but the default should be recombination and tightening of existing attacks.

  • Describe the phase 3 attack cycle.
  • Is there a "desperation move" the boss only uses below 10% HP?
  • What is the kill moment? What does the final hit look, sound, and feel like?

Section H: Death / Aftermath

  • What happens after the boss is defeated?
  • Is there a cutscene? (Refer back to Chapter 23.)
  • Does the player get a reward, and is the reward gameplay (a new ability, area, weapon) or spectacle (a cutscene)?

Deliverable

A 5-8 page design document, ideally as a PDF or Markdown file, containing all sections. Include the arena sketch, the three movesets as tables, and at least one flowchart showing the attack selection logic (even if it's just "50% sweep, 30% lunge, 20% slam").

Bonus: Write the first 10 lines of movelist_for_phase(1) in GDScript, using the frame data from Section C.

Exercise 26.3 — Implementation: Add a Parry Mechanic (★★★★☆, ~3-4 hours)

Take the CombatSystem.gd from the chapter. Extend it with a parry verb. Tune it until it feels good.

Requirements

  • A new state: PARRYING, entered by input.
  • A short active window (tune in playtesting — start with 6 frames and adjust) during which an incoming hitbox is deflected rather than damaging the player.
  • A long recovery window on a failed parry (the player inputs parry, but no attack arrived during the active window; now they cannot act for 30+ frames).
  • A visual/audio cue on successful parry — sparks, a chime, a short screen freeze.
  • A reward for successful parry — the attacker is stunned for ~20 frames, exposing them to counter-attack.

Tuning Targets

Your parry should feel:

  • Risky. Missing it should punish the player. A whiffed parry that exits into immediate action is too safe.
  • Rewarding. Landing it should open a clear counter-attack window. Without a counter window, parry is just a fancy block.
  • Just reactable. The active window should be wide enough that an attentive player can learn to time it, but tight enough that it never becomes a default response.

Playtest with at least one other person, ideally someone who has not played your prototype before. Watch where they miss the parry. Is the active window too tight? Is the telegraph too short? Is the punishment too harsh? Tune.

What to Submit

  • Your modified CombatSystem.gd file (or a fork of it named CombatSystemWithParry.gd).
  • A 200-400 word tuning log recording:
  • The frame values you started with.
  • The values you ended with.
  • What playtesters said, and how their feedback changed the tuning.
  • A 30-second gameplay clip demonstrating a successful parry and counter-attack.

Hint: Where to put the parry state in the enum. Parry should sit at the same level as WINDUP/ACTIVE/RECOVERY, not as a child state of ATTACK. A clean implementation has a top-level attack state AND a top-level defense state, running on the same state machine, with a clear rule that they cannot be simultaneously active. Think about what the enum should look like before you start typing.

Warning: Do not let parry shortcut the attack-recovery punishment. If the player can parry during their own attack's recovery, parry becomes a free safety net and breaks the whole combat balance. The state machine must enforce that you cannot parry during RECOVERY.

Exercise 26.4 — Critical: Find a Combat Encounter You Hate (★★☆☆☆, ~2 hours)

Pick a real, shipped combat encounter — from any game, any era — that you personally find frustrating. Not "hard and satisfying." Not "a skill-check I failed." Frustrating. The kind of fight you have an emotional reaction against, where your experience was that the encounter was unfair or unfun or tedious.

What You Will Produce

A 700-1000 word essay, structured as follows.

Part 1: The Encounter (150 words)

Describe the encounter factually. What game, what enemy or boss, what is the setup, what happens when you enter the fight? Assume the reader has not played the game.

Part 2: Why You Hate It (300 words)

Diagnose specifically. Do not say "it feels bad." Every paragraph must name a specific mechanic, frame timing, arena feature, telegraph, camera behavior, or AI pattern and connect it to the player-experience problem it creates. Use the vocabulary of this chapter: telegraphs, frame data, cancels, tells, arena, phase design.

Common failure modes to consider: - Tells that are invisible or too short. - Arenas that punish the camera or make dodging impossible. - HP that makes the fight long without making it challenging. - Multi-enemy encounters where a secondary enemy makes the primary unreadable. - Cheap-shot second phases that reset learned patterns. - Camera lock-on failures against large or flying enemies.

Part 3: Counter-Perspective (150 words)

Steelman the design. Why might the original designer have made the choices they made? What player experience were they trying to deliver that the choices, in principle, serve? Even encounters you hate usually have intentional design behind them. Find it.

Part 4: The Redesign (300 words)

Propose a specific, surgical fix. Not "rebuild the whole encounter." One to three changes. For each:

  • Describe the change.
  • Specify numbers (frame counts, damage percentages, arena dimensions, spawn counts).
  • Predict the new player experience.
  • Name a cost or tradeoff — what does the fix break, or what would need additional compensation?

Good design criticism is not a rant. It is a diagnosis and a prescription, with enough specificity that another designer could implement your prescription and test whether it works.

Example Structure of a Good Response

"In Dark Souls II's Ruin Sentinels fight, three enemies drop into a small arena simultaneously... [continues with specifics, then]... the problem is not the three enemies — it's that the arena's narrow ledge forces the player to either engage one enemy at the center while two others swing from the edges, or fall off. The lock-on snap between enemies is inconsistent because their AI staggers attacks in tight windows... [diagnosis]... the designers wanted to communicate that Drangleic's knights fight in formation, which is a thematic goal worth preserving... [steelman]... the fix is to delay the second and third sentinels by 15-20 seconds each, creating a gradient encounter rather than simultaneous overwhelm. Cost: the 'overwhelm' feeling weakens, and the fight's reputation as a notorious challenge drops..."

Deliverable

The essay. Submitted as a Markdown or PDF file. Cite the game and (if you can find them) the credits of the designers responsible; good criticism names its targets and credits their work.

How to Submit Your Exercise Work

If you are taking this chapter as part of a class, follow your instructor's submission protocol. If you are self-studying, treat these exercises as portfolio pieces. Keep them. When you interview for a combat-design or gameplay-programming role in three years, your Exercise 26.2 boss design document (revised with a fresh eye) is the kind of artifact a hiring manager will ask to see. Do the work now; revisit it later.

Further Practice

If the four exercises above do not fill your appetite for combat design:

  • Replay the first two hours of Dark Souls, Hollow Knight, and Celeste. Note, frame-by-frame, how each teaches the combat system. Write up which teaches the fastest.
  • Implement a simple 2D fighting-game prototype in Godot: two characters, 3 attacks each, a hitbox/hurtbox collision system, hit pause, frame-data UI for debugging. A weekend project. Invaluable learning.
  • Watch a full speedrun of your favorite action-combat game. Identify the places where the runner exploits the combat system (cancels, i-frame routing, AI manipulation). Consider: are these exploits design-intended, design-tolerated, or design-failures? Argue a position.

Combat, like every design skill, grows with deliberate practice. Spend the hours.