What Is Game State? — one variable, one whole game

Learning Goals 3 min

By the end of this lesson you will be able to:

1. Name the four phases most games go through — title, play, paused, game over — and describe what each phase allows and forbids.
2. Explain why a (state) variable acts like a remote control for the whole project — change one value, and dozens of scripts behave differently without touching a single other block.
3. Read a script that begins with if <(state) = [play]> then and predict whether it will do anything, given the current value of state.

Warm-Up — Hafiz's broken pause 7 min

Hafiz finished a catch-the-durian game and tried to add a pause feature. His plan: when the player presses P, broadcast pause and stop everything. Here's his script on the durian sprite:

when flag clicked
forever
  change y by (-5)
  if <touching [edge v] ?> then
    go to x: (pick random (-200) to (200)) y: (180)
  end
end

when [p v] key pressed
stop [all v]
        

The durian falls fine. P freezes the screen. But Hafiz can't unpause — clicking the flag restarts the whole game from zero. Predict — what's wrong with using stop [all v] for pause?

This whole lesson is a sit-down-and-think lesson. No project to open. Just the idea.

New Concept — the state variable 18 min

So far, the variables you've built have held numbers — score, lives, count, fall speed. Today, a variable holds a word. And that word controls the entire shape of your game.

What is a "phase" of a game?

Open any game on your phone. Before you start playing there's usually:

• A title screen with the game's name, a Play button, maybe a Settings button. The player can't move yet. The score isn't counting.
• The play phase. Now the player moves, enemies move, the score climbs, the music thumps.
• Sometimes a paused phase. Everything stops but is still there. Press resume and play continues.
• A game over screen. Final score, "Play again?" button. The player can't move any more, but the screen is still alive.

Each of these is a phase. The same sprites are loaded, but their rules change. The player sprite only listens for arrow keys during play. The score variable only counts during play. The title music only plays during title. The "Final Score: 42" speech bubble only appears during game over.

The state variable — the remote control

The trick to making this work in Scratch is to have one variable — call it state — that holds the name of the current phase. Not a number. A word.

set [state v] to [title]
        

Throughout the game, scripts change the state:

• Press a key on the title screen → set [state v] to [play].
• Press P during play → set [state v] to [paused].
• Lives drop to zero → set [state v] to [gameover].

One variable. Four possible words. Every "what should the game do right now?" question is answered by reading state.

Every script gates on state

Here's the key technique. Every script that does something game-related begins with an if-then that checks the state. If it's not the right phase, the script does nothing this frame.

when flag clicked
forever
  if <(state) = [play]> then
    if <key [right arrow v] pressed?> then
      change x by (5)
    end
  end
end
        

Same for the score — it only increments during play. Same for the enemies — they only chase you during play. Same for the music — title music plays during title, play music during play.

Why this is better than stop-all

With state, nothing dies. Every script is alive in every phase, just doing different (or no) things. So when you flip state back to "play", the scripts resume immediately, with no restart, no lost score, no lost lives, no lost progress.

when [p v] key pressed
if <(state) = [play]> then
  set [state v] to [paused]
else
  if <(state) = [paused]> then
    set [state v] to [play]
  end
end
        

Worked Example — read these three games' state diagrams 12 min

No Scratch this lesson. Instead, we'll read the state design of three real games together. By the end, you should be able to spot the four phases on sight.

Step 1 — Catch-the-fruit (Hafiz's game)

Hafiz wants three phases: title, play, gameover. No pause.

• title: backdrop says "Catch the Durian — press space to start". The basket doesn't move. Durians don't fall.
• play: durians fall, basket follows mouse, score climbs by 1 each catch, lives drop by 1 each miss.
• gameover: backdrop says "Game Over! Score: ___". Durians stop falling. Basket stops moving. Pressing space resets the game and goes back to title.

Step 2 — Name the transitions

For Hafiz's game, the moves between phases are:

1. title → play: when player presses space during title.
2. play → gameover: when lives reach 0.
3. gameover → title: when player presses space during gameover.

Three transitions, three trigger scripts.

Step 3 — Aisyah's pong

Aisyah's pong has four phases:

• title: "PONG — press flag to begin".
• play: paddles move, ball bounces, score climbs.
• paused: ball freezes mid-bounce. Paddles freeze. Screen overlay says "PAUSED".
• gameover: one side has reached 5 points. "Player 1 wins!" or "Player 2 wins!".

Step 4 — Spot the gate-on-state script

Aisyah's ball sprite has this:

when flag clicked
forever
  if <(state) = [play]> then
    move (10) steps
    if on edge, bounce
  end
end
        

Step 5 — Aisyah's pause script

The P key toggles between play and paused — but only those two. Pressing P during title does nothing.

when [p v] key pressed
if <(state) = [play]> then
  set [state v] to [paused]
else
  if <(state) = [paused]> then
    set [state v] to [play]
  end
end
        

Step 6 — Daniel's platformer

Daniel's platformer has five phases. He invents a new one: level-complete.

• title: title screen.
• play: player runs and jumps.
• paused: standard pause.
• level-complete: player reaches the flag. Score tallies up. Player can't move. "Press space for next level" appears.
• gameover: player dies for the third time.

The lesson: you get to invent the phases your game needs. The pattern is the same — one variable, gated scripts.

Step 7 — What gets gated, what doesn't?

Not every script needs to be gated. Some scripts are cosmetic and should run all the time — for example, a background music loop that just keeps looping the title track, or a backdrop-changes-with-state script that itself reads the state.

when flag clicked
forever
  if <(state) = [title]> then
    switch backdrop to [Title v]
  end
  if <(state) = [play]> then
    switch backdrop to [Play v]
  end
  if <(state) = [gameover]> then
    switch backdrop to [GameOver v]
  end
end
        

What you just learned: the entire shape of a game lives in one variable. Change that variable, and the whole game changes its mind about what to do — without you touching any other script. That's the power of state.

Try It Yourself — three design drills 12 min

No Scratch open. Pen and paper, or a doc. Each drill is a thinking exercise.

set [state v] to [title]
set [state v] to [lobby]
set [state v] to [play]
set [state v] to [results]
        

when flag clicked
forever
  if <(state) = [play]> then
    if <key [up arrow v] pressed?> then
      change y by (10)
    end
  end
end
        

set [state v] to [title]
set [state v] to [play]
set [state v] to [paused]
set [state v] to [shop]
set [state v] to [gameover]
        

Mini-Challenge — Aisyah's stuck pause 5 min

"The pause that won't release"

Aisyah added a pause to her platformer. She wrote one script on the Stage:

when [p v] key pressed
set [state v] to [paused]
        

Pressing P during play freezes the game beautifully. Pressing P again does nothing — the game stays paused forever. Aisyah has to click the flag to escape. What's missing? Without writing any code yet, describe in words what her one-script design is missing.

when [p v] key pressed
if <(state) = [play]> then
  set [state v] to [paused]
else
  if <(state) = [paused]> then
    set [state v] to [play]
  end
end
          

Recap 3 min

Today's lesson had no Scratch project — just the idea. Real games have phases — title, play, paused, gameover, and sometimes others you invent (level-complete, shop, cutscene). Each phase has its own rules about what the player and the world can do. The trick that makes all those rules work is a single variable called state that holds the name of the current phase as a word. Every game-action script starts with if <(state) = [play]> then — gated, so it only acts during play. To move between phases, you write small trigger scripts that say "when X happens, set state to Y". One variable. Every script reads it. Whole game changes character without touching anything else. That's the foundation of every game you'll build for the rest of Level 3.

State

The current phase the game is in — usually held in a variable called state whose value is a word like "title", "play", "paused", or "gameover".

State machine

The whole design pattern: a fixed set of named states + the rules for moving between them. Your project's state machine is the map of all your set [state v] to [...] blocks and what triggers each one.

Gating

Wrapping a script's body in if <(state) = [play]> then so it only runs during the right phase. Almost every game-action script in a state-based project is gated.

Transition

The move from one state to another — like title → play or play → gameover. Each transition needs its own trigger script (a hat block that sets the new state).

Phase

Another word for "state". A distinct chunk of the game with its own rules. Title is a phase. Play is a phase. Game over is a phase.

String variable

A variable that holds a word instead of a number. state is the most useful string variable in any game — but you can use them for player names, level names, or anything else that's a word.

Homework 2 min

Design your dream game's state diagram. No code — just a drawing.

1. Pick a game idea — could be a remix of something you've played, or something brand new. One sentence describing what you do in it.
2. List every phase the game needs. Aim for at least 3, no more than 6. Give each phase a one-word name (title, play, paused, gameover, level-complete, shop, etc).
3. Draw a box for each phase on paper. Draw arrows between boxes for each transition. On each arrow, write what triggers it (e.g. "press space", "lives = 0", "timer hits 30s").
4. For each phase, write three things: what the player can do, what the enemies do, what the score does. (Often the answers are "nothing" — and that's fine.)

Take a photo of your diagram, or sketch it in a Google Doc.

Bring back next class:

• Your state diagram (photo or doc).
• Your answer to: "Which phase has the most rules? Which has the fewest? Why?"

Heads up for next class: SCR-L03-27 takes your diagram and turns it into real Scratch. You'll build a working three-state machine — title screen, play, game over — with three backdrops, a state variable, and a broadcast called start play. Bring your homework diagram — we'll use it.