8.2 — Boss Body, Health & Phases
Your spec exists on paper (8.1). Today it becomes an object standing in
a room — and there is nothing to drag in: search Assets/Prefabs for a boss and you
come up empty. You assemble one from the enemy art that is already here, give it a shape the
physics engine can find, and give it a number that says how alive it is. Health first, attacks
in 8.4.
A boss that stands in a room, can be hit, and changes its mind twice as its health falls — in a project that contains no boss at all. As one problem it is not startable, because there is nothing to drag in: the body, its shape, its number, where that number is kept and the rules on it all have to be decided before any of them can be written.
First, before any code: cut that into parts small enough that you could look each one up on its own.
- Assemble the body out of art that is already herewhat does this part do?Read: 8.1 — Boss Design: Spec It First: the honest inventory of what this project ships, and the scene you chose to host the fight
- Give the body a shape the physics engine can findwhat does this part do?Read: 2.1 — Coins: Triggers, Tags & Your First Stat: the collider you added to the coin, the body you added to the Player, and the renderer-on-a-child discovery
- Give the body a number, and one method that can subtract from itwhat does this part do?Read: 2.2 — Spikes: Physics, Damage & Death: the signed damage method, and 2.3 — Healing Pickups & the Max-Health Cap: the rule that bounds a value inside the method that changes it
- Decide where that number lives — and it is the opposite answer to the player'swhat does this part do?Read: 5.3 — Into the Cave: Scenes, Persistence & The Refactor:
StatManager.Instance, theAwake()that claims it,DontDestroyOnLoad(gameObject)and the duplicate guard - Guard each threshold so it fires once, on a crossingwhat does this part do?Read: 3.3 — Fire Rate: Cooldowns & Time: a rule that fires once and must then wait — and the phase table you wrote in 8.1
- Make the change visible before any attack existswhat does this part do?Read: the
Debug.Log(...)readout you have watched since 2.1, against the HUD you built in 5.3
The split follows one number through its whole life: an object is assembled, given a shape, given a value, told where to keep that value, given rules about when it may change, and finally made visible. Four of those six parts are things you have already built — a collider, a signed damage method, a persistence decision and a rule that fires once. What is new is small enough to miss: none of it is boss code. This is the coin, the spike, the singleton and the cooldown, pointed at one object and told to hold still.
The test for a finished split: does the part name something you could point at — a component, an object in the Hierarchy, a field, a method, a scene? "Build a boss" points at nothing. "Which object carries the collider the player will hit" points at one object in one hierarchy, and that is a part.
Your turn
Pick two of the parts above and say in one line what each one actually does.
Your player's health and your boss's health are both numbers that go down. Say which of the two lives on an object a scene load cannot delete, and what the player would find in the arena if you gave the boss the same answer you gave the player.
A threshold is a boundary, not a value. Say in one line what your guard actually checks — the crossing, or the current health — and describe what the fight looks like on the day the other one ships.
-
Project window →
Assets/Artwork/Character/Enemy:OrcwithAxe1.png,OrcwithAxe2.png,LoRTowerV2_blue_no_soul_no_fire-Sheet.png,Turret_Bullet.png— no boss sheet among them. The three honest ways to assemble a boss out of what is there: (a) duplicate an enemy and scale it up — cheapest, and it reads as the same enemy, bigger; (b) the tower sheet — a fixed emplacement, so any moving attack in your spec becomes a projectile; (c) recombine, a scaled body with a scaled-down tower as a child — a second place attacks come from, and a second thing to keep aligned. -
Project window →
Assets/Prefabs, selectMobileEnemy, Edit ▸ Duplicate (Cmd+D) — the copy is your boss. Inspector → the name field: call itBoss. Hierarchy → drag it into the arena scene you named in 8.1. -
Hierarchy →
Boss, then Inspector → read its component list: a Transform, anEnemyController, and a child named Sprite. Say what is missing out loud: noCollider2D, noRigidbody2D— the same shape the coin and the Player arrived in as in 2.1. -
Hierarchy → the Sprite child, then Inspector →
Transform → Local Scale is already
1.5on it, so 3× on the root is nearer 4.5× the art you can see — read that number before you pick yours. That same child carries the Sprite Renderer and the Animator, not the root. Which object draws the boss decides which object a collider must cover, so write both names down. -
Project window →
Assets/Artwork/Animations/Top_Down/EnemyMotion/, double-click one clip, then Window ▸ Animation → its property list: sprite keys only, no position keys and no scale keys. -
Inspector → Add Component →
Box Collider 2Don the object you decided is the target, then Edit Collider to fit what you can see. Scene view → press Play, walk into the boss: does it stop you?
| Animating the boss | What it looks like | What it costs | When it wins |
|---|---|---|---|
| (a) Reuse the enemy controller | Drive MobileEnemy's controller: a Direction integer (0 = Right, 1 = Up, 2 = Left, 3 = Down) and an Attack trigger. |
It has no idle states, so a boss standing still still looks like it is walking, and it uses a separate clip per direction rather than flipping the sprite. | Your boss moves like your enemies already do, and you want it working today. |
| (b) Build a new controller | Two states — Idle and Attack — reusing the same clips in a controller you own. | You learn the Animator window's transition graph properly, and you inherit every mistake in the original clips. | Your spec is standing still and telegraphing, and the walk states would be noise. |
| (c) No Animator at all | A static sprite whose telegraph is a scale punch or a colour flash driven from your own script. | Almost no expressive range — but a colour flash is a genuinely good telegraph, and the cheapest to build. | You want the fight working first and the animation second, which is the right order for a deadline. |
Socratic: What Is a Boss Made Of?
- You scaled an enemy to three times its size. Which two things scaled with it that you did not intend to change — one in the scene, one in how the fight feels?
- Your player is a small character in a room. If the boss's collider is enormous, what happens to the player's ability to walk past it — and does your spec's arena still work?
- A boss made of two recombined pieces gives you a second place attacks can come from. Which attack in your 8.1 spec could come from a child object rather than the body?
One file today: the script that owns the boss's number. A phase threshold is a guard — a rule that fires once, at a boundary, and never again — so here are three guards from other worlds, none of them game code:
Example 1 — Stadium floodlights at halftime (once per match, not once per reading):
// The halftime cue fires once. Without the guard, every dimmer
// reading below 50% would re-run the entire sequence.
Example 2 — A factory quality gate (two thresholds, two responses):
// The line inspector flags a batch at a 50% reject rate
// and stops the line at 20%. Same sensor, two different rules.
Example 3 — The stadium scoreboard (bolted to the stadium, not to the team):
// The scoreboard does not travel with the team. Whatever shows
// a score has to live where the score is being kept.
Predict Before Building
- In the floodlight example, what exactly is the guard — the cue, or the state that says the cue has already run? Which one will you need in your boss script?
- The quality gate fires two different responses from one sensor. In your spec, what are the two responses at your two thresholds — and are they different enough to be worth two thresholds instead of one?
- The scoreboard is bolted to the stadium rather than to the team. Which object in your scene is going to show the boss's health — and is it the same object that keeps it?
| API | What you get | What it costs |
|---|---|---|
void TakeDamage(int amount) |
The signed damage method you built on the player in 2.2 and moved into StatManager in 5.3. The boss needs that same shape on its own script. |
A copy is a second place the rule lives — which is why 2.3's cap travelled with the method. |
Mathf.Clamp(int value, int min, int max) |
Bounds a value at both ends, as 2.3 used it to stop healing past the maximum. Here the interesting end is the floor: a hit can take health below zero. | It clamps the number, not whatever draws it. The frame the value reaches zero is still yours to handle. |
DontDestroyOnLoad(Object target) |
The call that made your player's numbers survive a scene load in 5.3. | Reach for it last, not first: whether the boss wants it follows from a property of the boss, not from tidiness. |
- Your player's health lives in
StatManager, a singleton withDontDestroyOnLoad— a decision you made in 5.3 for a reason. What was the reason, and does it apply to a boss? - Name the property of the boss's lifetime that decides where its numbers belong — and say whether it is the same property as the player's.
- Health on a component of its own, or on the script that will schedule its attacks in 8.4? Argue the split point, then write it that way.
- How many thresholds does your spec have, at what values, and what is the response at each one?
- A check that reads "health is below X" fires on every frame the boss is below X; a guard that reads "not already in this phase" fires once. Which do you need, and what does the other one do to your fight?
- Phases only move forward, and only downward. Why is a transition that can run backwards a bug generator rather than a feature?
- What if two thresholds are crossed in a single hit? Which phase is the boss in afterwards, and what does that say about the order of your checks?
Last decision, and the one the player actually perceives: how the boss's remaining health becomes something they can see.
| Health display | What it looks like | What it costs | When it wins |
|---|---|---|---|
(a) Debug.Log(...) |
Every health change prints the new value. | Only you can see it. It is not a game, it is an instrument. | Today — and it is the honest instrument for a boss: 5.3's HUD exists to show the player's own stats. |
| (b) A world-space bar | Three child sprites — a background, a fill, a frame — with the fill's localScale.x driven by the health fraction. |
You must handle the fraction reaching zero without inverting the sprite, and it scales with the boss. | You want the player to watch the bar fall without taking on a whole UI system yet. |
| (c) A UI Slider on a Canvas | The conventional answer: a Canvas, a Slider anchored to the top of the screen, and a reference from the boss. | The subsystem is familiar from 5.3, the anchoring is not: a new RectTransform hierarchy pinned to a corner, and a decision about which scene it belongs to. | You want the standard look, and will find out how much of 5.3's HUD you can reuse. |
Choose, Then Justify
- Which health display did you choose, and which row of the table did you reject? What is the cost you accepted?
- The world-space bar drives
localScale.xfrom a fraction. What does that fraction look like on the frame the boss dies, and what would the bar do if you forgot to clamp it? - The reusable enemy controller has no idle states. What does the player conclude about a boss that appears to be walking while standing still — and is that a bug you can live with, or one you must fix?
Checkpoint — before moving on, you must be able to:
- Explain why the boss was assembled rather than found, and name the art you assembled it from
- Say which object in your boss carries the renderer, and which object carries the collider the player will hit
- Explain why the boss's health is scene-local while the player's is a singleton — in terms of lifetime, not tidiness
- Explain why a phase threshold must be guarded, and what happens without the guard
- Defend your choices of health display and animation approach, naming what each one cost
- Break this feature into parts small enough to look each one up on its own, and say which earlier lesson each came from
- Commit and push
Reference Docs
Need a deeper explanation? These pages cover the same concepts:
- Unit 8: Boss Fight — health, phases and assembly
- Enemy State Machines — thresholds and guarded transitions
- Unity + C# Quick Reference —
Mathf, clamping and component access
Next: 8.3 — Player Attack: Fight Back, where the number you just built starts going down.
Saved on this device only — the Dashboard tracks your progress.