🕹️ Capstone: Build the Collect-the-Orbs Mini-Game

Thinking in Loops

The single most useful shift from following tutorials to building a game is to stop thinking about features and start thinking about the loop. A feature is one thing the engine can do: play a sound, show text, spawn a particle. A loop is the small cycle a player repeats: they do something, the world responds, the game keeps score, and that invites them to do it again. Collect an orb, hear the chime, watch the counter climb, reach for the next orb. That cycle, not any one feature, is the game.

This matters because a loop is small enough to finish. Our whole game is one sentence: the player moves around a space, walks into a glowing orb, the orb reacts and disappears, a counter goes up, and collecting all three wins. Everything in this lesson serves that sentence, and every feature you learned is one word in it.

Figure: The game as a loop, not a pile of features. The player acts, the world responds to a collision, the player senses the response, and the game updates its score, which sends the player back for more · each quarter of the ring is one module you already know.

The rest of this lesson builds that loop, and the order of the sections is the order you build it. Each step leans on modules you already finished, so the map below is also a map of the course.

flowchart LR
    S[Build the space
Modules 2, 3, 4] --> P[Make it playable
Modules 5, 6]
    P --> F[Give feedback
Modules 7, 8, 9]
    F --> W[Win and lose
Module 5]
    W --> R[Package and ship
Modules 10, 11]
    style S fill:#ede7f6,stroke:#7e57c2
    style F fill:#fff3cd,stroke:#ffc107
    style R fill:#e8f5e9,stroke:#4CAF50
                    

Build the Space

Everything starts with a place to play. Make a level, drop a floor to walk on, and place the three orbs the player will collect. The orbs are just actors with a sphere mesh, and what makes them read as collectible is the material: a bright emissive material so each orb glows against the ground rather than sitting there like a grey ball. Then light the arena so the floor, the character, and the glowing orbs all read clearly.

This is Modules 2, 3, and 4 doing exactly what they taught, with a game in mind. The level and the actors are the stage, the emissive material is what turns a plain sphere into an inviting target, and the lighting is what makes the whole thing legible. Keep it simple: a flat tiled area, three orbs spaced out so the player has to travel between them, and enough light to see.

Figure: The mini-game's play space, staged live in the ClaudeTest project · three glowing orbs (spheres with a bright emissive material) sit around the player character on a tiled arena, lit so the collectibles pop against the ground. This is the space the rest of the loop brings to life.

Make It Playable

A space with orbs in it is a diorama. To make it a game, the player needs to move and the orbs need to react. Movement comes from the template's pawn plus the Enhanced Input system you already set up: press a key or push a stick, the character walks. The reaction comes from Blueprints listening for a collision.

The heart of this step is one event. Each orb carries a collision component set to generate overlap events, and its Blueprint responds to On Component Begin Overlap: the moment the player's capsule enters the orb's space, that event fires, and from it you trigger everything else. This is the exact interactable object and collision pattern from Module 6, used for the simplest possible interaction, touching a thing.

Figure: The pickup, as a Blueprint sees it. The player pawn walks into the orb's collision volume, which fires an On Component Begin Overlap event · from that one event you branch out to the feedback, the score, and destroying the collected orb.

Give the Player Feedback

The overlap fires, the orb vanishes, the score goes up. Mechanically the game works. But a game that changes state in silence feels broken, because the player cannot tell that anything happened. Feedback is what turns a state change into a moment, and the reliable trick is to hit more than one sense at once.

On each pickup, fire three things together. Show it: update a UMG heads-up display so the counter ticks from one number to the next. Hear it: play a sound, a short bright chime that says got it. Feel it: trigger a Niagara burst where the orb was, a quick spray of particles that punctuates the moment. Modules 7, 8, and 9, fired from the same overlap event, turn a silent increment into something satisfying.

Figure: Feedback across three senses. The same overlap event that scores the orb also updates the UMG counter, plays a pickup sound, and spawns a Niagara burst · hitting sight, hearing, and motion at once is what makes a collectible feel collected.

Close the Loop: Win and Lose

A loop that never ends is a toy, not a game. What makes it a game is a goal, and the goal here is simple: collect all three orbs. To know when that happens, the game has to keep score, and that is one integer variable, held somewhere that outlives any single orb (the player, the level Blueprint, or a small game-mode Blueprint). Each pickup adds one to it, then checks: is the count now three?

This is Blueprint flow control at its most useful. Increment the counter, then a branch: if it equals the target, the player has won, so fire the win, whether that is a message on the HUD, an opening door, or simply a bright You Win panel. If it is not there yet, do nothing special and let the player keep collecting. That one branch is the difference between a pile of pickups and a game with an ending.

Add stakes: a countdown and a lose

A goal with no pressure is a chore. The cheapest way to add tension is a countdown timer that races the player: a clock that starts full, ticks down while they play, and shows on the HUD next to the orb counter. Now the game has two ways to end, and they race each other: the player wins by reaching the target first, or loses if the clock reaches zero first.

The clock is a second small piece of state: a float of seconds remaining, decremented over time. You can drive it two ways, subtract the frame's delta time every tick, or set a repeating timer that fires once a second and subtracts one, and each time it changes you update the HUD so the player feels the pressure. Then add the mirror image of the win branch: when the timer reaches zero, check whether the game is already won, and if not, the player loses, so fire a Time's Up panel. Winning and losing are the same shape, one branch each, watching two different numbers.

flowchart LR
    Z["Orbs: 0 of 3
clock ticking"] -->|collect| O["1 of 3"]
    O -->|collect| T["2 of 3"]
    T -->|collect| H["3 of 3"]
    H --> W["You win"]
    C["Clock reaches 0
before 3 collected"] --> L["You lose"]
    style Z fill:#ede7f6,stroke:#7e57c2
    style W fill:#e8f5e9,stroke:#4CAF50
    style C fill:#fff3cd,stroke:#ffc107
    style L fill:#fdecea,stroke:#e53935
                    

Ship It

A game that only runs when you press Play in the editor is a project, not a game someone can play. To turn it into something you can hand to a friend, you package it: set the project's name, icon, and default map, pick a platform, and let the engine cook the content and build a standalone application. The output is a runnable build, no editor required.

This is Module 10 closing the course the way it opened, with the whole project rather than one feature. Packaging is also where small oversights surface, a default map that is not your game level, or a missing setting, so it is worth doing once early rather than only at the very end.

flowchart LR
    P[Your project
level + Blueprints] --> S[Project settings
name, icon, default map]
    S --> C[Cook and build
for a platform]
    C --> B[A runnable build
anyone can play]
    style P fill:#ede7f6,stroke:#7e57c2
    style B fill:#e8f5e9,stroke:#4CAF50
                    

One more tool worth naming: the AI-assisted workflows from Module 11 are not a separate step so much as an accelerator for every step above. Staging the arena, wiring a Blueprint, or checking a setting can all be driven through the Unreal MCP bridge, which is exactly how the play-space figure earlier in this lesson was staged and captured. The game is still yours to design; the assistant just moves your hands faster.

Hands-On: Build the Whole Loop

Build the entire game once, end to end. Keep it small: one flat arena, three orbs, one counter, one win. The goal is not polish; it is to run the whole loop once so the connections between modules become muscle memory.

Knowledge Check

Summary

You put the whole course to work. Here is the arc, which is also the order you build every small game:

Plan the loop, then build in order. A game is a cycle the player repeats: act, respond, keep score, repeat. Name that loop, then build the space, make it playable, give feedback, close the loop with a win and a timed lose, and ship it. Each step depends on the one before, which is why the order is not negotiable.

Every step is a module you already know. The space is levels and actors, materials, and lighting; playability is input and a Blueprint overlap; feedback is UMG, audio, and Niagara; the win and the timed lose are flow control; the deliverable is packaging, sped up by AI-assisted workflows. The capstone is not new knowledge, it is the wiring between what you already have.

Where this fits

This capstone is the whole game-development half of the course in miniature. Where the two cinematic capstones in the Intermediate and Advanced tracks assemble a shot to be watched, this one assembles a game to be played, from an empty level to a packaged build. Finish it and you have done the thing the whole course set out to teach: turned Unreal's systems into something interactive that runs on its own.