◀ 8.48.58.6 ▶

8.5 — Win, Lose & the Death Loop

Every fight ends one of two ways, and today both have to be real: the boss dies and the game acknowledges it, or you die and find out what your death loop costs. Systems from five units meet here — and two of them disagree.

In this lesson you will be able to answer“how do I make winning and dying both real?”Outline only
Break It Down~10 minOutline only

The boss can be beaten and the player can die, and neither ending is real yet: a health value reaches zero, an object disappears, and nothing a player would call a win or a loss ever happens. The fight has two exits and today both of them are walls.

First, before any code: cut that into parts small enough that you could look each one up on its own.

  1. Build the thing the win happens towhat does this part do?Read: 5.2 - The Door: Opening It with Events (the object that changes, and the listener you wire in the Inspector); the machine itself is Assets/Prefabs/Switch.prefab
  2. Fire the win from the boss's death, not from a keypresswhat does this part do?Read: 8.2 - Boss Body, Health & Phases (the boss's health, and what already runs on the frame it reaches zero)
  3. Put the health reset where nothing can skip itwhat does this part do?Read: the StatManager singleton you moved the stats into in 5.3, and the death rule you chose in 2.2 - Spikes: Physics, Damage & Death
  4. Decide which scene the respawn lands in, and check what is in itwhat does this part do?Read: 5.3 - the build-index order, and Assets/Scripts/Package Scripts/SceneSwitch.cs, whose static fields reposition the player after any load
  5. Time the walk back and decide whether the wipe costs too muchwhat does this part do?Read: 7.5 - Design a Big Cave: Flow & Difficulty (the same audit, run on your own arena)

Notice the shape: one ending is a cause looking for an effect, and the other is an effect looking for a reset. Four of these five parts are machinery you already own - a UnityEvent with an Inspector listener from 5.2, a death rule from 2.2, a scene load and a singleton from 5.3, an audit from 7.5. What is genuinely new today is that two of those pieces disagree: the singleton keeps health across a load, and the death rule was written back when a load wiped everything. Naming that disagreement is the work; the win itself is a few lines of wiring.

The split is finished when each part names something you could point at and defend: an object in the Hierarchy, one method on one script, a scene index, a number off a stopwatch. "Make the endings real" points at nothing. "The frame the boss's health reaches zero" points at one method in one file, and that is a part.

Your turn

Pick two of the parts above and say in one line what each one actually does.

The lever fires on a keypress and the boss would fire on a health value. Which of the two is the better model for your win - and what would the boss's script have to know about your level in order to do it the other way?

Your win happens in a scene and your coins live in a singleton. Name one thing the player should deliberately keep across a win and one thing you should deliberately reset, and say where each of those two decisions is written down today.

The Problem: Winning Has Nowhere to Go ~10 min

Write down what your game does when the boss's health reaches zero. Not what should happen — what the code does. For most builds the boss's object disappears and the Console prints nothing.

The obvious fix is "open the exit", so check whether an exit exists: this project has no boss door, no arena gate and no locked exit. What it has is machinery you have used once — Assets/Prefabs/Switch.prefab carries a working Lever.cs whose two UnityEvents, onLeverOn and onLeverOff, ship empty on the prefab. Today you point that machinery at a new cause.

How the win landsWhat you buildWhat it costs, and what it buys
(a) A lever-style event An exit object in the arena, and a UnityEvent fired from the boss's death path instead of from a keypress. The listener does whatever your win means — disable a barrier, play an animation, reveal the way onward. An object to build and a listener you configure in the Inspector, where the code cannot see it. In exchange, the boss has no idea what a door is.
(b) Load a scene directly The death path calls a scene load — the same idea as the SceneSwitch script that has moved you between scenes since 5.3. A hard cut with no ceremony, and it skips anything you wanted to show the player. Check which scene you are loading into before you write it.
(c) Nothing but a statement A single line printed when the boss dies, and the fight simply stops. The player is left in a quiet room, with no confirmation the game noticed. It is also today's fallback: prove the fight can be won before you spend a session on ceremony.

Socratic: Two Endings, Two Paths

  1. Write your win and your loss as two separate sentences. Which of the three approaches above does each need — and do they need to be the same approach?
  2. All three of your scenes contain a Player, so no scene can strand you. But only one contains your HUD. What does the player see if your death loop sends them somewhere else — and does that change which death rule you chose in 2.2?
  3. The lever's UnityEvents are empty on the prefab and already wired on the instance in your Overworld. What does that tell you about where a behaviour lives — and if you drag in a fresh Switch, which of the two do you inherit?
Read Function-Level Examples ~15 min

The end of a fight is a procedure, and procedures have a shape. Five from other worlds — ask of each: who decides, who acts?

Example 1 — A fire alarm and the door magnets (the alarm does not know what a door is):

// The alarm cuts power to the door magnets. It has no idea what a
// door is - it stops holding them open, and physics does the rest.

Example 2 — The final whistle (the end of the match is one event):

// The whistle ends the match. Everything after it is a separate
// procedure - the whistle itself does not clear the pitch.

Example 3 — A dead-man's handle (the safe outcome is the default):

// If the driver's hand leaves the handle, the brake applies by
// itself. Safety is what happens when nobody does anything.

Example 4 — Shift-end lockout (restarting is deliberate):

// The klaxon locks the line out. Starting it again takes a person
// turning a key - it is never a side effect of the klaxon.

Example 5 — A hotel key card (the room is reset by a deliberate step):

// The room is re-armed at check-in, not when the guest walks out.
// Nothing resets just because somebody left the building.

Predict Before Building

  1. Example 1 separates the alarm from the doors. Which of your two endings would benefit from that same separation, and which is fine as a direct call?
  2. Example 3 makes the safe outcome automatic. In your game, what is the automatic outcome when the player's health reaches zero — and who or what makes it happen?
  3. Example 5 is the one that will bite you. Which of your numbers is not reset by leaving a scene, and therefore needs a deliberate re-arming step of its own?
In the Editor ~20 min
  1. Hierarchy → create the exit object — right-click → Create Empty, or drag a sprite in from Assets/Artwork — then Scene view → place it where the player will see it. There is no door in the arena, so what you are placing is the door.
  2. Inspector → Add Component → whatever your exit needs: a Box Collider 2D with Is Trigger ticked if the win is "the player arrives somewhere", or a Sprite Renderer alone if the exit is a thing that appears.
  3. Project window → Assets/Prefabs → Switch.prefab is 5.2's machinery. Drag a fresh instance into the Scene view if you want its two events, then Inspector → the event's list: + adds a slot, the object field takes the exit, the dropdown takes the method.
  4. Inspector → Game view → press Play and win the fight any way you can, then watch whether your exit changes. A win path you have never seen fire is a theory.
  5. GitHub Desktop → commit the win path before you touch the death rule. One ending is about to make the other harder to debug.
In the Code ~25 min

Read your own death rule before you change it. In 2.2 you chose one of three designs, and the choice was simple then: everything about the player lived on PlayerController and died with the scene. Then 5.3 moved your stats into a StatManager singleton that survives a load — and nobody told you what that did to this rule.

Your 2.2 choiceWhat it did thenWhat it does now that stats are a singleton
(a) Reload the current scene The scene was rebuilt from scratch: the player, the coins and their health all reset. Death was a clean slate. The scene is rebuilt, but the health number is not — it lives in the singleton, which survived the load. Follow it through: the player spawns with the health they died on, and the next frame that checks it kills them again, forever.
(b) Load a scene by name Whatever scene you named was loaded, and everything about the player was rebuilt there. Same persistence problem, plus the scene-identity problem: check whether the scene you named is the one the fight is in. All three scenes contain a Player, so you cannot be stranded — but load Start (the hub scene) and the arena is a load away.
(c) No reload at all Health was reset by hand and the player was moved back to a start position. Coins were kept on purpose. The only one of the three that already does the right thing, because you were already resetting health explicitly. Check that the reset writes to the singleton, not to a field on the player.
The boss does not have this problem, and that is the point. The boss's health is scene-local — the decision you made in 8.2 — so the arena reload brings it back at full health. That is the arcade rule: a wipe resets the test. Keep it or change it, but say which, because it is a decision rather than a side effect.
Architectural specification: the win path.
  • What exactly does the listener do — disable an object, move a barrier, load a scene, print a line? Write that as one sentence.
  • Who can hear the event? If two objects in the arena both listen, what happens — and is that useful or confusing?
  • The death path probably also destroys the boss's object. Before or after the event fires — and what breaks if the object is gone when the listener runs?
  • Anything the boss spawned and left in flight — attacks, projectiles — outlives the boss unless something stops it. Which pattern from 5.2 finds them all at once?
  • Is the win state reachable twice? What happens if the death path runs a second time, and what guards it?
Architectural specification: the loss path.
  • What condition means "the player is dead" now that health lives in the singleton — and where is that condition checked?
  • Which scene does the respawn land in, does it contain a Player, and does it contain the arena? Those may be two different scenes, and if so that is a decision.
  • What sets health back to maximum, and where does that step live — the death path, the singleton's own start-up, or the player's spawn?
  • What happens to the coins under your rule? State it as a rule the player could be told, not as a side effect of where the number lives.
  • How many times can the player die in a row before the game becomes unplayable? Test the loop three times.

Ascertaining the Loop

  1. Die on purpose and watch the Console. What is the player's health on the first frame of the new scene, and how do you know?
  2. Which of the three 2.2 death designs did you choose, and what does it now fail to reset?
  3. Your death rule loads a scene, and SceneSwitch repositions the player from static fields that your load never updated. Where does the player actually arrive — and is that where you meant?
Playtest & the Death Audit ~20 min

Hand the game to a partner. Watch for one thing per run — write down what you see before you say anything.

Then time the walk back yourself. Stopwatch, from the frame health hits zero to the frame they stand in the arena ready for the first exchange. That number is what a wipe costs, and it decides whether your boss is a challenge or a chore. Over a minute? Pick one fix and defend it:

Checkpoint — before moving on, you must be able to:

Reference Docs

Need a deeper explanation? These pages cover the same concepts:

Next: 8.6 — Boss Studio + Final Review, where you play the whole thing from the beginning.

0/12 answered

Answers save on this device as you type. At the end of class, click Download and upload the file to the Canvas assignment.

Saved on this device only — the Dashboard tracks your progress.