Lesson 3: Core Game Loop Prototype

Art can wait. Animation polish can wait. What cannot wait is proof that your game is fun to repeat. This lesson helps you stand up a core loop prototype in one Unity scene so you can press Play and feel the heartbeat of your design.

Lesson Objective

By the end of this lesson you will have:

One scene that runs your loop from start to end state without loading other levels
Placeholder visuals that read clearly in motion
A minimal GameFlow controller that owns win, lose, and restart

Why This Matters

Teams that skip a loop prototype often build beautiful levels around a mechanic that does not sustain interest. A cheap prototype exposes that risk in days, not months.

Step-by-Step

Step 1: Name the loop in one line

From your Lesson 1 brief, write:

Player does X → game responds Y → player gains or loses Z → repeat until condition W.

Example for a small arena game:

Player dodges hazards → score ticks up → difficulty rises → repeat until timer hits zero or health hits zero.

If you cannot write W (end condition), pause and tighten scope before adding systems.

Step 2: Create a dedicated prototype scene

In Assets/_Project/Scenes/, create CoreLoop_Prototype.
Add a ground plane or tile area, a spawn point for the player, and a simple boundary so playtests do not fall forever.
Keep lighting default. You are validating rhythm, not mood.

Step 3: Use primitives as stand-ins

Replace final art with:

Capsule or cube for the player
Cylinders or scaled cubes for hazards or interactables
Text - TextMeshPro for score, timer, and state labels

Color-code roles (player green, hazard red, goal gold) so observers understand the scene instantly.

Step 4: Implement the smallest interactive beat

Choose the shortest path to one complete cycle of your loop:

If your game is about collecting, spawn one pickup and increment a counter.
If it is about combat, spawn one target with a health integer and destroy it on hit.
If it is about timing, start a countdown and fail when it reaches zero without meeting a goal.

Use UnityEvents or direct references sparingly. Clarity beats architecture in the first prototype.

Step 5: Add a GameFlow controller

Create GameFlow.cs on an empty GameObject:

using UnityEngine;

public class GameFlow : MonoBehaviour
{
    public enum State { Playing, Win, Lose }
    public State Current { get; private set; } = State.Playing;

    public void ReportWin()
    {
        if (Current != State.Playing) return;
        Current = State.Win;
        Time.timeScale = 0f;
    }

    public void ReportLose()
    {
        if (Current != State.Playing) return;
        Current = State.Lose;
        Time.timeScale = 0f;
    }

    public void Restart()
    {
        Time.timeScale = 1f;
        Current = State.Playing;
        UnityEngine.SceneManagement.SceneManager.LoadScene(
            UnityEngine.SceneManagement.SceneManager.GetActiveScene().name);
    }
}

Wire UI buttons or keys to Restart for fast iteration.

Pro tip: Log state transitions with Debug.Log so playtest videos stay readable when you review footage.

Step 6: Timebox the session

Give yourself 60–90 minutes to reach first Play Mode victory. If you exceed that, your loop definition is still too large. Cut a feature, not a deadline.

Step 7: Record a task board update

Add a card: Core loop playtest with 3 fresh players and link to this build hash or branch name. Tie the card to your production metric from Lesson 1.

Mini Challenge

Invite one person who has not read your brief. Ask them to play for two minutes, then explain the goal in their own words. If they cannot, your feedback layer is too weak. Add one UI line or one audio cue, then retest.

Pro Tips

Use Play Mode tint and clear scene naming so you never edit prototype values you meant to keep.
Avoid Addressables or complex pooling until the loop feels good with ten objects or fewer.
Snapshot your scene after the first “fun” session. That commit is your emotional anchor.

Common Mistakes

Building inventory, narrative, and meta-progression before the minute-to-minute loop works
Tuning numbers before players can fail in an understandable way
Skipping lose states (players need stakes to care)

Troubleshooting

"Play Mode feels empty."

Add one reactive sound or a punchy camera shake on success. Feedback sells the fantasy before models do.

"I cannot decide win versus survive."

Pick the condition that is faster to script. You can swap victory logic later; you cannot swap wasted weeks.

"Restart breaks references."

Use scene reload as shown, or reset fields explicitly in Restart if you refuse to reload. Consistency matters more than style here.

Recap

You defined the loop, built a single-scene prototype with placeholders, and centralized flow in a GameFlow controller so wins and losses are explicit.

Next Lesson Teaser

Next you will replace the capsule with a real player controller and input architecture that stays responsive as features accumulate.

FAQ

Should the prototype use the new Input System?
If your team already standardized on it, yes. If you are solo and moving fast, legacy input is acceptable for this lesson only. Migrate before Lesson 4 if possible.

Is a game manager MonoBehaviour okay?
Yes. Start simple. Refactor into services when you have more than one scene depending on the same rules.

How many systems belong in this scene?
As few as possible. If it is not required to complete one loop, disable it for now.