Your class writes stories. It plays them as 3D games.

One lesson, one room, no prior coding. Students write a short story in a plain-language script called VXLScript; a 3D game builds live next to the text as they type. Nothing to install, no student accounts, no email addresses collected. Every game is handed in to your class page, and the last seven minutes are the class playing each other's games.

Before they arrive — 5 minutes, once

1. Go to vxlverse.com/class, sign in with Google (teacher only), name the class (e.g. Tuesday P4) and press Create class. You get a code that looks like ZEUS-K7M2Q.
2. Write the code on the board, large. It is the only thing students need. (Or put vxlverse.com/class/YOUR-CODE/board on the projector — it shows the code and the three joining steps at back-row size.)
3. Open a second tab at vxlverse.com/studio-live on the projector machine. Click into the code panel, press Ctrl+A then Backspace, and type (or paste) the six-line hook game below. Leave it there. Do not play it yet.
4. Plan groups of three. Pair programming beats one-kid-one-Chromebook for a first lesson: they argue about the story instead of typing in silence, and three keeps everyone within reach of the keyboard. A free class holds 30 hand-ins, so thirty students in threes leaves you plenty of room — and if your students work alone, thirty of them still fit.

The six-line hook game

Title: The Lost Crown
World "forest":
Character "Mara":
  say I lost my crown somewhere in these woods. Find it for me!
item 👑 crown
Win when: player has 👑 crown

That is a complete, winnable 3D game. Read it downward: where (World), who (Character), what she says (say), what is out there (item), how you finish (Win when).

Timing

Stage 1 — 0–5 min: the hook

The projector tab already has the six lines in it. Do not show the code first.

Say: "Nobody touch anything. Watch this for one minute."

Click the 3D world on the right. You are now in the game. W A S D walks, hold the left mouse button and drag to look around, E talks to whoever you are standing in front of. Walk to Mara, press E, let her line finish, then go and find the floating crown. Take it. The win screen appears.

Say: "That was a 3D game. Somebody guess — how many lines of code is that? Hands."

Take three guesses. They will say hundreds. Now point at the left-hand panel.

Say: "Six. And here they are. Read them with me."

Read each line and say what it does, in these words:

• World "forest": — "where it happens."
• Character "Mara": — "who is in it."
• say … — "what she says when you talk to her."
• item 👑 crown — "a thing lying in the world that you can pick up."
• Win when: player has 👑 crown — "how you finish. Without this line it is not a game yet — hold that thought."

Now the concept question. Click into the code and change forest to volcano. Do not press anything else — the world rebuilds by itself in about a second.

Ask: "I changed one word. What just happened to the world? … So what is the code actually for?"

You want someone to say out loud that the text is the game, not instructions about the game. Change it back to forest and move on. Do not explain anything else.

Stage 2 — 5–10 min: joining

Read these five steps to the class, one at a time, and wait for hands down after each. Point at the code on the board every time you say it.

1. "Open Chrome. Go to vxlverse.com/class — that is v-x-l-verse dot com slash class."
2. "On the left there is a box that says I have a class code. Type ZEUS-K7M2Q — it's on the board. Press Join."
3. "You should see our class name at the top. Press the big dark Make your game button."
4. "It asks for a nickname. Not your real name. A game name — Astronaut, Pancake, Ravenclaw. That is the name your game shows up under on our class page."
5. "Press Let's go. You should now see writing on the left and a little 3D world on the right. Thumbs up when you're there."

Say once, plainly: "There is no password, there is no account, and nobody is asked for an email address. If you close the tab your work is still here when you come back on this same computer."

Then clear the decks:

Say: "There is some example code already in there. Click on it, press Ctrl and A together, then Backspace. Make it completely empty. We start from nothing."

The three things that go wrong here, and the fix in one sentence each:

• "Class not found" — the code is mistyped; the dash matters, the letters are not case-sensitive.
• Sharing a Chromebook with a partner who joined earlier — tap the nickname in the yellow 🎒 chip at the top to switch to a different student.
• Nothing on the right-hand side — the editor is empty, which is correct at this point. The world appears with the first line.

Stage 3 — 10–20 min: your first world

Type on the projector one line at a time and have the room type it with you. Pause after every single line and look at the right-hand side.

Say: "Line one. Where does your story happen? Type World, space, then the place in quotes, then a colon."

World "snow":

Say: "Look right. You are standing in it. Try a different word — desert, jungle, dungeon, volcano, beach, city. Ten seconds. Go."

Let the room shout out the worlds they found. Then:

Say: "Line two. Somebody has to be in there. Type Character, space, a name in quotes, colon."

Say: "Line three matters — watch my fingers. Press space space first, so the line starts further in than the one above it. Then say and whatever they say. The indent is how the computer knows this line belongs to that character."

World "snow":
Character "Bo":
  say Hello! Who are you?
  say I have been standing in this snow all morning.

Say: "Click the world. W A S D to walk, hold the left mouse button and drag to look, walk up to Bo and press E. Somebody you invented is talking to you. Go."

Give them four minutes. Circulate. Then bring them back for the question that makes the concept land.

Ask: "Everyone look at your two say lines. If I swap them over — put the bottom one on top — what will change in the game? Say it before you do it."

Take a prediction, then have them do it and talk to their character again. Confirm it out loud: "The computer does your lines in the order you wrote them. Top to bottom. Nothing clever, nothing hidden — the order on the screen is the order it happens. That has a name: sequencing, and it is true of every program ever written."

They will notice a message at the bottom of the editor saying the game has no way to win yet. Do not fix it. Say: "It's right. This isn't a game yet. That's the next ten minutes."

Stage 4 — 20–30 min: make it a game

Say: "You have a world and a person. Why is that not a game? What is missing?"

Push until someone says something like you can't win or there's nothing to do. That is the whole idea of the stage.

Say: "A game needs three things: something you have to get, someone who wants it, and a rule that says you've finished. Three lines. Watch."

Type these on the projector, in this order, saying what each one is:

World "snow":
Character "Bo":
  say I have been standing in this snow all morning.
  say My dog ran off. Bring me a bone and I will call him back.
  wants: 🦴 bone
  gives: 🐕 puppy
item 🦴 bone
Win when: player has 🐕 puppy

• wants: — "Bo will ask you for this and won't stop asking until you bring it."
• gives: — "what he hands you when you do."
• item 🦴 bone — "the bone actually exists in the world now. Notice this line is all the way to the left, not tucked under Bo. It belongs to the world, not to him."
• Win when: — "the finish rule."

The deliberate mistake — do this, it is the most valuable 60 seconds of the lesson. Before you type the last line, stop with only wants: and gives: in place and point at the status line under the editor:

💡 Your game has no way to win yet — add a `Win when:` line at the far left, or `win` under a choice.

Say: "Nobody has played this. Nobody has tested it. The computer has already read it and told me it cannot be finished. That is what a compiler is — a machine that reads your work and finds the hole before your player does."

Now type the Win when: line. The message flips to:

💡 Add a second `World "…"` and a glowing portal links the two.
✓ Looks good — click the game to play it.

Say: "Now go and win yours. Talk to your character first — the thing they want only appears once they've asked you for it."

While circulating, the two errors you will actually see:

• The item is indented under the character. If item 🦴 bone sits under Character with spaces in front of it, it belongs to the character and quietly disappears from the world. Symptom: the status line says it "auto-placed" the item. Fix: delete the spaces so the word item starts hard against the left edge.
• The Win when: line is indented. Same cause, same fix — it is a rule for the whole game, so it lives at the left edge.

Say this to whoever you help, every time, because it is the transferable idea: "Where the line starts tells the computer who it belongs to."

Stage 5 — 30–38 min: make it yours

This block is theirs. Write three prompts on the board and then stop talking.

1. Change the place. Change the word in World and see what you get.
2. Add an enemy. Three lines, and the second and third are indented:

   Enemy "Frost Wolf":
     kind: wolf
     tier: 2
   

   Say this out loud when you write it up: "kind: goes on its own line, indented. If you put it on the same line as the name, you get a monster called Frost Wolf: kind: wolf — the computer thinks that whole thing is its name. Try it if you don't believe me." Kinds worth knowing: wolf dog bat spider skeleton zombie ghost slime robot drone golem raider wyrm. tier: is difficulty, 1 to 50 — start at 2.

3. Give the player a choice. The say lines under each choice are indented one more step:

     if choice is "I will find him":
       say You are a good one. Hurry!
     if choice is "It is too cold out there":
       say ...Then I will wait a little longer.
   

Put together, a finished 38-minute game looks like this — this is the version to leave on the projector while they work:

Title: Bo and the Frost Wolf
World "snow":
Character "Bo":
  say My dog ran off into the storm.
  say Bring me a bone and I will call him back.
  wants: 🦴 bone
  gives: 🐕 puppy
  if choice is "I will find him":
    say You are a good one. Hurry!
  if choice is "It is too cold out there":
    say ...Then I will wait a little longer.
Enemy "Frost Wolf":
  kind: wolf
  tier: 2
item 🦴 bone
Win when: player has 🐕 puppy

Two things to say to the room during this block, and nothing else:

• At 34 minutes: "If you have not played your own game in the last two minutes, play it now." (Iteration. They forget.)
• To anyone stuck: "Read the message at the bottom of your editor to me." (Not "what's wrong?" — make them read the compiler. By the third time they do it without you.)

For fast finishers, point at the What can I add? chip above the editor (or ⌘K / Ctrl+K) rather than teaching anything new — it lists everything you can put in a game and drops the words straight into the story. Examples opens finished games they can take apart, and Guide in the toolbar opens the whole command list in a second tab.

Stage 6 — 38–45 min: hand in, then the arcade

Call it firmly at 38. Nobody is finished; that is fine and is in fact the point.

Say: "Hands off. Everyone press the 🎒 Hand in button at the top. Confetti means it worked. You can press it again later from this computer — it updates your game, it does not make a second one."

If a game cannot be finished, Hand in says so instead of taking it. The child gets a card — "Almost there! Your game needs a way to win before your class can finish it." — with one button: Add a finish line. One tap writes the missing goal into her script and hands the game in. Tell the room once: "If it says Almost there, press the yellow button — that is the computer giving you the last line." It is the reason nothing on your class page is a game nobody can finish.

A child who has handed in is not left staring at a message. Confetti, then a card with See your class → on it — one tap and she is on the class page playing what her classmates made. Inside a classmate's game the button reads ▶ Next classmate’s game, so she keeps moving through the class on her own, with no adult retyping a URL.

The class arcade

Then, on the projector, go to vxlverse.com/class/YOUR-CODE. Every handed-in game is there as a card with the author's nickname and the award their game earned. (These pages are not listed in search and student games never appear in the public gallery — the code is what opens the page.)

Press Start the arcade. The page goes full screen and plays the class's games one at a time: Next game moves on, Back returns, ✕ leaves. The order is the same on every screen in the room, so "everyone go to game four" means the same game on the projector and on a Chromebook at the back — which is what makes this a whole-class activity rather than a demo.

For the projector itself: vxlverse.com/class/YOUR-CODE/board is the broadcast screen — the join code at a size the back row can read, the three joining steps under it, then the class's games cycling by themselves with each child's nickname and award. Arrow keys change the game, space pauses. No nav, no sign-in, nothing to mis-click while thirty children watch.

The awards

Each game carries an award: Storyteller, World Builder, Cast Director, Quest Weaver, Boss Maker, Maze Maker, Path Weaver, Monster Maker or Game Maker. Read it out with the nickname as each game comes up — "Pancake, Cast Director". It costs four seconds and it gives every child one sentence to take home.

The award comes from the game, never from the class: how many characters she wrote, how much they say, how many worlds she built, whether she invented a boss. Nothing counts plays, votes or who was most popular — no such number exists on the page — and no child is ranked above another. Two children who both wrote a cast both get Cast Director, and a child whose game is still six lines is Game Maker, which is a true thing to be called. Every child gets one.

Closing the lesson

The arcade decides the order for you, so you can watch the room instead of the mouse. One rule makes this part work:

Say: "Author does not touch the keyboard. Author sits there and says nothing. I play it. If I can't work out what to do, that's information."

Play for 60–90 seconds each. Then ask the author one question — always the same one:

Ask: "What did you have to fix to make it finishable?"

That question closes the lesson on the right idea. Everybody hit something that did not work, everybody read a message, everybody changed a line and tried again. That is the thing you are actually teaching, and it is worth naming in the last thirty seconds:

Say: "Nobody in this room wrote a working game first try. You all wrote a broken one and fixed it. That is not the bad part of programming. That is programming."

If the room falls behind

• Joining ate 12 minutes. Cut Stage 5 to five minutes and keep the arcade. The arcade is the part they remember; the customisation is the part they will do again at home.
• Half the class hasn't got a win by minute 30. Put the finished eight-line Bo game on the projector and leave it there. Copying it and then changing the names is a legitimate route through — most of them will diverge within two minutes anyway.
• No time for the arcade. Hand-in still takes ten seconds; do it, and open the class page at the start of the next lesson. The games do not expire.

What was actually taught

Named honestly, without dressing it up: sequencing (lines run top to bottom, and Stage 3's swap proves it), selection (if choice is — the program takes one path or another), state (the player either has the bone or does not, and the win rule reads that), decomposition (a game is a world, plus characters, plus things, plus a rule), and debugging as the normal case (the compiler reports, the student reads it, changes one line, re-tests). This maps onto the sequencing and selection strands of most computing curricula; check the wording of your own scheme of work rather than trusting a number quoted by a website.

You write the story. The computer builds the 3D world while you type. If your game can't be finished, the checker tells you before you hand it in.

The six lines that make a game

World "forest":
Character "Mara":
  say Find the lost star!
  wants: 🌟 star
item 🌟 star
Win when: player has 🌟 star

That is a whole game. A world, someone in it, something they want, something to find, and a way to win. Everything else you learn today is a change to one of these six lines.

Indent = inside. The two spaces before say mean "this belongs to Mara". Lines with no spaces in front belong to the game itself.

What each word does

Worlds you can ask for: forest, beach, desert, snow, jungle, swamp, volcano, dungeon, city-night, canyon, cemetery, mushroom, crystal. Enemy kinds: skeleton, zombie, wolf, raider, robot, slime, bat, spider, ghost, wyrm, golem.

The three things that always break

1. An item hiding inside a Character

This one is nasty because nothing turns red — the star just never appears in the world, and the quest can never be finished.

Wrong (the item is indented, so it belongs to Mara):

Character "Mara":
  wants: 🌟 star
  item 🌟 star

Right (the item starts at the far left, so it belongs to the world):

Character "Mara":
  wants: 🌟 star
item 🌟 star

Rule of thumb: item lines live at the left edge, not tucked under a person. If you press Play and the thing you need is nowhere, check this first.

2. Squashing an enemy onto one line

Wrong — the computer thinks the enemy's whole name is "Sandclaw": kind: raider:

Enemy "Sandclaw": kind: raider

Right — the colon ends the line, the details go underneath:

Enemy "Sandclaw":
  kind: raider

3. A quest with no way to win

wants: gives you points when you deliver the item. Points are not winning. If there is no Win when: line and no win inside a choice, your game runs forever and nobody can finish it. Add one line at the left edge:

Win when: player has 🌟 star

Now try — three challenges

Challenge 1 — Make it yours

Change the world, rename the character, and swap the item for something you invented. Read it out loud after: does the story still make sense?

World "volcano":
Character "Ash":
  say My lantern fell in the lava. Find me another!
  wants: 🏮 lantern
item 🏮 lantern
Win when: player has 🏮 lantern

Challenge 2 — Add danger

Add an enemy that guards the thing you need. Remember: kind: goes on its own indented line. tier: is how tough it is — start at 3, not 30.

World "desert":
Character "Rin":
  say Something is out there. Bring me the star and we run.
  wants: 🌟 star
Enemy "Sandclaw":
  kind: raider
  tier: 3
item 🌟 star
Win when: player has 🌟 star

Challenge 3 — Give the player a decision

A choice means two players can play the same game and have different endings. Notice there is no Win when: here — the win inside the first answer is the way to win.

World "snow":
Character "Frost Guard":
  say The gate is locked. Do you have the key?
  if choice is "Here is the key":
    say Then the mountain is yours.
    win
  if choice is "Not yet":
    say Come back when you find it.
item 🔑 key

Going further: make the second answer lead somewhere too, add an Ally who follows you, or use if player has key: so the guard reacts differently depending on what you are carrying.

Before you hand it in

1. Press Play and actually finish your own game. If you can't, nobody can.
2. Check every item line starts at the left edge.
3. Check you have a Win when: line or a win the player can reach.
4. Read your say lines. Would you want to read them in someone else's game?

Then hand it in. A card pops up with a button to your class page — press it and play what everyone else made.

Everything below is written to be handled standing up, in about 30 seconds, without leaving the child's desk. Each entry gives you the symptom, a sentence you can actually say out loud, and the fix.

Two rules that will save you most of the lesson:

• Never take the keyboard. Point at the line. The child types the fix. It takes ten seconds longer and it is the whole point of the lesson.
• Broken is normal. If you treat a red message as a disaster, thirty children will treat it as a disaster. Treat it as the game talking to them.

Fast lookup

World "forest":
Character "Mara":
  say Find the lost crown!
  wants: 👑 crown
item 👑 crown
Win when: player has 👑 crown

World "cave":
Character "Rook":
  say I dropped my lantern somewhere in here.
  wants: 🔦 lantern
item 🔦 lantern
Win when: player has 🔦 lantern

World "desert":
Character "Sam":
  say The raiders took my water key.
  wants: 🔑 key
Enemy "Raider":
  kind: raider
item 🔑 key
Win when: player has 🔑 key

World "forest":
Character "Mara":
  say The crown is lost. Will you help me look?
  wants: 👑 crown
  if choice is "I'll help":
    say Try the tall rocks past the river.
  if choice is "Not today":
    say Then the forest stays dark a while longer.
Enemy "Thorn":
  kind: raider
item 👑 crown
Win when: player has 👑 crown

World "forest":
Character "Mara":
  say Hi! Bring me a star.
  wants: 🌟 star
item 🌟 star
Win when: player has 🌟 star

Before the lesson: five-minute check

Do this at the actual teaching machine, on the actual school network, in the room you will teach in. A check done at home on your own wifi proves nothing about the Chromebooks.

1. Make your class and write the code down. Put it on the board in large, well-spaced capitals now, not during the lesson. Say the ambiguous characters to yourself: is that a zero or an O?
2. Join your own class as a student from a second window or a spare Chromebook, using a nickname like TEST. Type the six-line game, press Play, win it, press Hand in. This is the single most valuable ninety seconds of preparation — it proves the code, the network, the 3D, the winnability check and the hand-in in one pass. The TEST card can stay; class games are saved under your account, so you can delete it later from your profile page.
3. Check one real student Chromebook, not the good one at the front. Press Play and walk around for ten seconds. If that machine is smooth, the room is fine. If it is choppy, plan to pair children up and say so at the start rather than discovering it at minute 15.
4. Set up two projector windows — /class/YOUR-CODE/board on the projector, everything else on your own screen. The board is built to be read from the back row, so the code needs no zoom; the editor text does, so raise the browser zoom in the projector window before you demo in it.
5. Have the six-line game on the board or on paper. It is your answer to the frozen child, your fallback if the projector dies, and your demo script. Do not rely on being able to remember it while thirty children watch.

Optional, worth it if you have another two minutes: press Start the arcade once on your own test class, so the full-screen swap holds no surprises in front of thirty children. The arcade fixes the order for you, but thirty games still will not fit into seven minutes — decide in advance where you will stop.

Four strands, four levels. Every cell describes something you can see on a screen — a missing star, a message in the status bar, a child changing a line and pressing Play again. Nothing here needs you to read code you don't understand.

The strands name concepts rather than standard codes: strand 1 is sequencing and structure (order and indentation change the result), strand 2 is goal state and decomposition (what has to be true for this to be finished, and what has to exist for that to happen), strand 3 is narrative design plus selection (a goal, an obstacle, a branch), strand 4 is debugging. They map cleanly onto the sequencing/selection and debugging strands of most computing curricula — map them to your own scheme rather than trusting a code printed by someone who has never seen your syllabus.

The rubric

What "secure" looks like on screen

Secure on strands 1, 2 and 3 at the same time — six lines, a named goal, a reachable win:

Win when: player has 🌟 star
World "forest":
Character "Mara":
  say Bring me the star and the forest wakes up.
  wants: 🌟 star
item 🌟 star

Extending on strand 3 — the item is not lying about, an enemy is holding it, and the ending answers the goal:

Title: The Cave Star
Win when: player has 🌟 star
Ending: The forest wakes up.
World "cave":
Character "Mara":
  say A raider took our star. Get it back!
Enemy "Raider":
  kind: raider
  drops 🌟 star

Extending on strand 2 — the win is behind a condition and there is a real failure branch, so the player can be turned away:

Title: The Bridge
Ending: You crossed the bridge before dark.
World "forest":
Character "Toll Keeper":
  say Nobody crosses this bridge for free.
  if player has 🪙 coin:
    say A coin! Cross, friend.
    win
  else:
    say Come back when you have a coin.
item 🪙 coin

Marking thirty of these in ten minutes

Open your class page at /class/ plus your class code and mark straight down the grid: each hand-in is one card with the child's nickname, the title they chose, a banner drawn from their world and the award their game earned. Hand in refuses a script that will not build and a game that cannot be finished, so every card on that page has already cleared emerging on strands 1 and 2 — which is exactly why the interesting question is whose finish line it is. For strands 2 and 3, click a card, then Remix this game: that opens the child's own script in the editor. A win rule in her own terms — an item her character asks for, a win inside a choice — is secure. A bare Win when: player has star at the very end of the script is the line the Add a finish line button writes, so that child took the offer and the reasoning was the machine's; mark developing and ask her, in the room, what her game asks the player to do. About fifteen seconds a child. Strand 4 is the one the class page cannot show you, so tick that one in the room during the 20-30 and 30-38 blocks — the moment you watch a child read a message, change one line and press Play again — and you walk out with the whole grid marked.

If you only have time for one judgement

• Can it be won? That single question separates a piece of writing from a game. The editor answers it in one line and Hand in enforces it, so the question left for you is the better one: can the child say, in words, why her game can be won?
• Keep the evidence cheaply. The class page URL is the whole set of work; the script behind any card is one click away via Remix this game if a parent, a club organiser or a moderator wants to see what a child actually wrote.

This is one 45-minute lesson, so the claim is deliberately modest: children do not leave fluent in anything. They leave having met six ideas in a context where the ideas mattered — because getting them wrong meant the game did not work, and getting them right meant it did. Below, each concept is given in one plain sentence, then the exact minute of the lesson where a child meets it, then what a child who has understood it can do afterwards.

1. Sequencing

What it is: instructions run in the order you write them, and where a line sits (indented under something, or at the left margin) decides what it belongs to.

Where they meet it: 10–20, FIRST WORLD. The child types three lines and presses Play. The two say lines come out of the character's mouth in the order typed — swap them and the conversation is nonsense. The indentation is doing real work: those say lines are indented under Mara, so they are Mara's lines.

World "forest":
Character "Mara":
  say Welcome to the forest.
  say I have lost something precious.
Win when: talk to Mara

A child who has got it can: predict what will happen before pressing Play, and fix a conversation that comes out in the wrong order without being told which line to move. They can also explain why a line indented under a character belongs to that character — the first step towards understanding scope.

2. Selection (conditionals)

What it is: a program can test something and then take one path or another, so not every player sees the same thing.

Where they meet it: 30–38, MAKE IT YOURS, when they add a choice. This is the first moment the game stops being one fixed track. One branch ends the game; the other does not.

World "forest":
Character "Mara":
  say A wolf blocks the path. What do you do?
  if choice is "Share my bread":
    say The wolf steps aside and lets you pass.
    win
  if choice is "Run away":
    say You are back where you started.

A child who has got it can: trace both paths on paper and say which one wins; write a branch deliberately so that one option is a dead end and one is progress. The strongest signal is a child who tests both options rather than only the one they wrote first — that is the beginning of thinking about coverage.

3. Variables and state

What it is: a program remembers things while it runs — what you are carrying, how many coins you have — and can make decisions based on what it remembers.

Where they meet it: twice. At 20–30 the inventory is state: Win when: player has 🌟 star is a question the game asks about something it is remembering. At 30–38, faster groups meet a named counter that goes up during play and is tested at the end.

World "forest":
Character "Mara":
  say Help me and I will pay you in coins.
  if choice is "Fetch the water":
    coins + 10
    say Thank you!
  if choice is "Chop the wood":
    coins + 10
    say Warmth at last!
Win when: coins is 20

A child who has got it can: answer "how many coins do you have right now, and how do you know?" and — the real test — work out that a win set to coins is 30 with only two ten-coin jobs in the game can never happen. That is arithmetic reasoning about a running program, which is exactly what a variable is for.

4. Decomposition

What it is: a big thing ("make a game") is built out of small parts that each do one job.

Where they meet it: 0–5 and again at 20–30. The hook does this in one move: the teacher plays a finished game, then shows the six lines behind it. The class can see the whole made of parts — a place, a person, a thing, a rule. By 20–30 they are assembling those parts themselves.

World "forest":
Character "Mara":
  say Find the lost star!
  wants: 🌟 star
item 🌟 star
Win when: player has 🌟 star

A child who has got it can: point at any line and say what job it does, and answer "which line would you delete to break this?" They can plan the next thing they want by naming the part it needs ("I want a locked door, so I need an item and a character who gives it") instead of asking for a general "how do I make it harder".

5. Debugging

What it is: when the program does not do what you meant, you read what it actually says, form a guess about the cause, change one thing, and test again.

Where they meet it: everywhere, but sharpest at 20–30. The compiler runs as they type, and its messages are written as sentences a child can act on rather than error codes. Three they are likely to hit in this lesson:

• No way to finish. "Your game has no way to win yet — add a Win when: line at the far left, or win under a choice." This is the expected state at the end of 10–20, it is what drives the next twenty minutes, and it is the one thing Hand in will not accept: pressing it offers Add a finish line, which writes the missing goal for her.
• A name that does not exist. If a child writes a win rule about talking to a character they misspelled, the build stops with "I don't know anyone called ...". This is the only failure in the language that stops the build outright, and it is a good one: it teaches that names must match exactly.
• The item put in the wrong place. item belongs at the left margin (or directly under a World), not indented under a character. A child who indents it sees the compiler say it auto-placed the item out in the world so the player can find it and win — a visible cue that the line was not doing what they thought. Worth putting on the board at the start: items live at the edge of the page.

A child who has got it can: read the message before putting their hand up, change one thing rather than rewriting everything, and re-test. The habit to praise out loud in this lesson is "read it, change one thing, press Play again".

6. Narrative goal and obstacle

What it is: a story only holds attention when somebody wants something and something is in the way — and in a game, both of those have to be written down as rules, not implied.

Where they meet it: 20–30 supplies the goal (wants: and Win when:); 30–38 supplies the obstacle (an enemy, or a choice that can be got wrong).

World "cemetery":
Character "Mara":
  say Something is moving between the graves.
Enemy "Bone Rider":
  kind: skeleton
  count: 4
Win when: defeat all

A child who has got it can: state their game's goal and its obstacle in one sentence each, and see why "a nice forest where you walk around" is not yet a game. This is the same want/obstacle analysis they do in English lessons, applied somewhere the answer is testable — the story either resolves or it does not, and the machine will tell you which.

A note on the enemy block: each trait goes on its own indented line. Writing Enemy "Bone Rider": kind: skeleton all on one line folds the trait into the enemy's name and the creature comes out wrong. It is the most common formatting slip in the lesson and worth pre-empting on the projector.

The compiler's winnability check as an assessment signal

This is the part that makes the lesson assessable in 45 minutes, so it is worth being precise about what it does and does not do.

Before a game is handed in, it is checked for whether it can actually be finished — not whether it is good, but whether a route to the ending exists. If nothing in the script can ever produce a win, the child is told so in plain language. If the win depends on holding an item that no player could ever pick up, that is reported too. The check is not a grade and it is not a style opinion; it is a reachability question, and the child has to answer it by reasoning about their own game.

That reasoning is the assessment evidence. To clear the check a child must hold two things in their head at once — "here is what my game asks the player to do" and "here is the path that makes it happen" — and notice when the second does not exist. A child who has a star in the world, a character who asks for it, and a win rule that tests for it has demonstrated that they can trace a path through a system they built. A child whose game says "no way to win yet" and who then works out, unprompted, that they wrote a wants: but never a Win when: has demonstrated something better.

Practically, this means you are not marking 28 games at home. Walking the room, the screen tells you where each child is: still typing, warned and puzzling, or clean and playable. The teacher-facing signal to collect is not "did it build" (almost everything builds) but "can this child say, in words, why their game can be won?" Ask three or four children that question in the last ten minutes and you have your formative assessment for the lesson.

At a glance

For a scheme of work or a club session plan

In one 45-minute session, children aged 10–14 write a short text script that builds a playable 3D game in the browser, hand it in to a shared class page, and play each other's work in a class arcade. The script is simple indented lines — a place, a character, some dialogue, an item, and a rule for winning — with names and dialogue in the children's own language and only about a dozen keywords in simple English, so no prior programming experience is needed by the children or by the adult leading, and nothing is installed. They meet sequencing (the order of lines and what indentation groups together), selection (a branching choice where one path ends the game and one does not), variables and state (the player's inventory, and a counter tested by the win rule), decomposition (a game broken into place, character, object and rule), and debugging (reading a plain-language message from the compiler, changing one thing, and re-testing). It also sits alongside literacy work: a want and an obstacle have to be written explicitly, because the game only resolves if both are stated as rules. The work maps to the sequencing, selection and debugging strands common to most computing curricula, and can be assessed without collecting books: a game cannot be handed in until it can actually be finished, so every child has to reason about — and be able to explain — the path that makes their own game winnable. Suggested follow-on: a second session adding a second location and a multi-step goal, or a version where the script retells a text the group has read. In a coding club or a holiday camp, this same paragraph is the session description parents read.

The mechanism, stated plainly

A child writes a sentence in near-English and presses Play. Three seconds later they are standing in a forest and a character they named is talking to them.

World "forest":
Character "Mara":
  say Find the lost crown!
Win when: talk to Mara

That is the whole trick: the gap between an idea and its consequence is seconds, not a marked-in-a-fortnight worksheet. Children debug because the world is wrong in front of them, not because a teacher told them it was wrong.

The second half of the lesson does the harder work. Once they add a goal, the compiler checks whether the game can actually be finished — and refuses to pretend. A child who asks for a star that no world contains is told so. To fix it they have to reason about their own logic: what does the player need, where does it come from, what counts as winning? That is the sequencing and selection strand of most computing curricula, arrived at by argument with a machine rather than by definition.

What this lesson is not

It is not learning Python, and it will not teach syntax that transfers to a text language. It is computational thinking through authoring: decomposition, sequence, state, conditions, and debugging — practised on something a ten-year-old wants to finish. Treat it as the lesson that makes the Python lessons land, not a replacement for them.