Exercise 3 — Rules & States

GAME 1303-002 · Unreal Engine 5.8 · Week 4 — Tuesday, September 15
In class, 10:30 – 11:45 · 2 points · Submit by end of class
📄 Your One Sheet is due in Canvas tonight — see assignment-one-sheet.md

The skill

Last week you built a verb. A verb alone is a toy. What turns a toy into a game is stakes: something you're trying to do, something that can stop you, and a defined moment when either happens.

That's what rules are. Not "the controls" — the answer to three questions:

1. What am I trying to do? → the goal
2. What can stop me? → the failure
3. What happens then? → the consequence

The third question is the design question. Super Meat Boy and Dark Souls both kill you constantly, but the consequence is a half-second respawn in one and a long walk back in the other, and that single difference produces two entirely different games from the same failure rate.

By the end of the block you will have: your Ex 2 course with a goal, a hazard, a win state, a lose state, and a consequence you chose deliberately.

With Ex 2, this feeds Milestone 2 — Core Game Mechanic (Week 5), next week.

What you need

• Your Ex 2 project, with the verb and three-obstacle course
• GAME1303_Helpers content pack imported

Part 1 — Draw the state diagram (10 min)

Before you build anything. On paper, or in any drawing tool, five minutes maximum.

Draw a box for each state your game can be in, and an arrow for each thing that moves between them. The minimum:

        ┌──────────┐
   ┌───▶│ PLAYING  │───── reach goal ────▶ ┌─────┐
   │    └──────────┘                       │ WON │
   │         │                             └─────┘
   │         │ touch hazard                    │
   │         ▼                                 │
   │    ┌─────────┐                            │
   │    │  LOST   │                            │
   │    └─────────┘                            │
   │         │                                 │
   └─────────┴───── press R ──────────────────-┘

Then add your states. A game with checkpoints has a respawn arrow. A game with lives has a counter and two different lose arrows. A puzzle game might have no lose state at all — and if so, draw that, because "you cannot fail" is a real and deliberate design position.

Photograph or export it. This drawing is part of your submission.

Five minutes with a pen here prevents an hour of confused wiring later. Every state bug you will hit this semester is a state you didn't draw.

✅ Checkpoint 1 — a state diagram exists, photographed, with at least one state beyond the default four.

Part 2 — Wire the goal (15 min)

1. Set up the manager

Your BP_GameState actor from Ex 2 is already in the level. Select it and set:

2. Make the goal

At the end of your course, Place Actors → Box Trigger. Name it Goal, and scale it to a doorway.

Add a Cube mesh beside it with a green material so you can see where it is — trigger volumes are invisible in play.

3. Hook it up

Select Goal → Details → Events → On Actor Begin Overlap → +. This drops an event node into the Level Blueprint:

On Actor Begin Overlap (Goal)
  → Other Actor → Cast To BP_Player      (filters out anything that isn't the player)
  → Get Actor Of Class (BP_GameState) → Win

The Cast To BP_Player is what stops a stray physics cube from winning the game for you. Skipping it is the most common trigger bug in the course.

4. Test it

Play. Walk into the goal. The debug text should read WON.

✅ Checkpoint 2 — touching the goal produces a win state on screen.

Part 3 — Wire the failure (15 min)

5. Make a hazard

Duplicate the Goal trigger. Rename it Hazard, mark its mesh red, and place it where the player will actually hit it — under a gap, in the path of the second obstacle.

Wire its On Actor Begin Overlap to BP_GameState → Lose the same way.

6. Add a kill volume

Unreal gives you this one free: Place Actors → Volumes → Kill Z Volume, stretched wide and placed well below your floor. Or set World Settings → Kill Z to a value under your lowest floor.

Every game needs this, and forgetting it is the single most common soft-lock in student builds — the player falls forever and has to close the application. Route the kill volume to Lose so it produces your consequence rather than just destroying the pawn.

7. Test both

Play. Touch the hazard → LOST. Fall off the edge → LOST. Press R → PLAYING.

✅ Checkpoint 3 — both failure routes work, and R returns you to a playable state.

Part 4 — Choose your consequence (15 min)

This is the graded design decision. Pick one and implement it:

"No failure" is a legitimate choice and scores full marks if you argue it. Puzzle and narrative tracks should think hard about it — a puzzle game that kills you is usually two games fighting each other.

8. Tune the timing

Whichever you chose, tune the delay. How long between failing and playing again?

Try 0, then 0.5, then 2.0 seconds. Notice that a delay under about 0.3s feels responsive and blameless, while anything over about 1.5s makes you dread failing. Both are usable. Choose which one your game wants.

9. Write your notes

Docs/Ex03_notes.txt:

States: Playing, Won, Lost, Respawning  (diagram attached)

Goal:    reach the green door at the end of the course
Failure: touching a red hazard, or falling past Kill Z

Consequence chosen: CHECKPOINT RESPAWN
RestartDelay: 0.35
Checkpoint placed after obstacle 2

Why: my dash is a commitment with no mid-air correction, so players
fail a lot while learning it. At full-level restart the third gap felt
unfair — I'd lose 20 seconds of correct play for one mistake. With a
checkpoint after obstacle 2 and a 0.35s delay, failure costs about
two seconds, so I kept trying the hard gap instead of getting annoyed.
I want a game you fail at cheerfully, like Celeste, not one you fear.

Three sentences minimum, naming what the consequence does to the player's behaviour. That's the point.

✅ Checkpoint 4 — a consequence implemented and tuned, notes written naming its effect on play.

Part 5 — Package and submit (5 min)

10. Package

Platforms → Windows → Package Project into MyGameName/PC_Builds/Ex03/.

Start the package before you write your notes — it takes several minutes and you can work while it runs.

11. Record

20–40 seconds: win once, fail once, and show the consequence playing out.

12. Submit

Zip as lastname_ex03.zip:

• PC_Builds/Ex03/
• Your recording
• Your state diagram image
• Docs/Ex03_notes.txt

Canvas → Assignments → Exercise 3. Due before you leave.
📄 One Sheet due tonight, 11:59 PM, separately.

Rubric — 2 points

Troubleshooting

Nothing happens when I touch the goal.
Four things, in order: the trigger has Generate Overlap Events ✔ · the player's capsule also has Generate Overlap Events ✔ · the trigger's Collision Preset is OverlapAllDynamic · your Cast To BP_Player is succeeding — drop a Print String on the failure pin to check.

The win fires immediately on Play.
Your trigger overlaps the player's start position. Move it.

It fires repeatedly.
Add a DoOnce node after the overlap event on the goal. Hazards usually don't want one.

R doesn't restart.
Open Level needs the level's name, not its path, and the level must be in Project Settings → Packaging → List of maps to include. It works in editor and fails silently in a packaged build otherwise — which is exactly the kind of thing building early catches.

"Accessed None trying to read property..."
Your Get Actor Of Class (BP_GameState) returned nothing, which means BP_GameState isn't in the level. Drag it in.

The debug state text doesn't show.
ShowDebugState ✔, and confirm BP_GameState is actually placed in the level rather than only existing in the Content Browser.

If you finish early

• Add a second, different failure — a timer, a fall limit — and decide whether two failure types make the game better or just noisier.
• Try the opposite consequence to the one you chose. Play both for two minutes. Note which you'd rather keep, and why.
• Add a win condition that requires the goal and something else — collect three things, then reach the door. Notice how that changes the level's shape.

Before next week

Week 5 is Milestone 2 — Core Game Mechanic, worth 5 points, demoed live. It is your Ex 2 verb plus this week's rules, applied to your own game rather than a test course. Read milestone-2-core-game-mechanic.md and check the ③ Core Mechanic tab of the course checklist before you arrive.

Package it before class. Do not package it during class.