Teach a 45-minute game-design lesson

Why this lesson works

Before the pedagogy, the constraints — because those are what usually kill a computing lesson before it starts.

• No accounts for children. You create a class and get a code. Students join with the code and a nickname. No email address, no password, no sign-up screen, nothing to reset on Monday.
• Nothing to install. It runs in the browser tab. Locked-down, managed Chromebooks are the target case, not the edge case.
• Everyone finishes with something playable. Six lines is a working game. The floor is low enough that the slowest writer in the room hands in a real thing.
• Their work stays out of the public feed. Class games are visible to you on the class page and to the class. They are not published to strangers.

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.

The 45-minute lesson

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.

Before the bell — 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.
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. Two reasons: pair programming beats one-kid-one-Chromebook for a first lesson, and a free class accepts 10 hand-ins. Thirty students in threes is exactly ten. If your students work alone, only the first ten hand-ins land on the class page — everyone still builds and plays in their own browser.

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

World "snow":

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

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

💡 Your game has no way to win yet — add `win` inside a choice, or a `Win when:` line.

✓ Looks good — click the game to play it.

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

What the children actually learn

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 win inside a choice, or a Win when: line." This is the expected state at the end of 10–20, and it is what drives the next twenty minutes.
• 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 will see the compiler report that it has auto-placed the item on the floor so the win is still reachable — 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

In one 45-minute lesson, pupils aged 10–14 write a short text script that builds a playable 3D game in the browser, then play each other's work. The script is plain indented English — a place, a character, some dialogue, an item, and a rule for winning — so no prior programming experience is needed by pupils or by the teacher, and nothing is installed. Pupils 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 English and literacy work: pupils must express a want and an obstacle explicitly, because the game only resolves if both are written as rules. The work maps to the sequencing, selection and debugging strands common to most computing curricula, and can be assessed without collecting books: before a game can be handed in, it is checked for whether it can actually be finished, so every pupil has to reason about — and be able to explain — the path that makes their own game winnable. Suggested follow-on: a second lesson adding a second location and a multi-step goal, or a cross-curricular version where the script retells a text pupils have studied.

Assessment

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 and a screenshot of their world, and because the Hand in button refuses a script that will not build, every card on that page has already cleared emerging on strand 1. For strands 2 and 3, click a card, then Remix this game — that opens the child's own script in the editor, where the status bar tells you in one line whether it can be won ("Your game has no way to win yet…" or nothing at all) and the say lines in front of you tell you whether a goal was ever named, which is 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 — a mark on the register 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, and the editor answers it for you in one line — which is why it is worth more of your marking attention than anything else on this page.
• 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 if a parent, a moderator or a head of department wants to see what a child actually wrote.

Troubleshooting: what breaks in a real room

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

1. "It says my game can't be won"

What it looks like: the child presses Play or Hand in and gets a message saying the game can't be finished, naming something — a missing goal, or an item nobody can ever pick up. The child reads this as "I failed".

Say this: "That's not an error, that's the computer telling you it played your game and couldn't finish it. Which means neither could a person. What are they supposed to do to win?"

Fix: walk three questions, in order.

1. Is there a Win when: line at all? A game with only wants: gives the player a job and a score, but there is no finish line, so it can never be won. This is the single most common one in the 20-30 minute stretch.
2. Does Win when: name exactly the same thing as the item line? Same emoji, same word. 👑 crown and 🌟 crown are two different things to the compiler.
3. Is the item line actually in the world? See problem 3 below.

The shape that always works:

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

If you are short on time, tell the whole room once: "Every game needs a last line that starts with Win when:." That one sentence prevents about half of these.

2. Nothing appears when they press Play

What it looks like: the world loads — ground, sky, they can walk — but there is no character, or nothing at all happens. Or the screen stays blank with a loading spinner.

Say this: "The world built fine, so your World line is good. Something under it isn't being read. Look at the line with the person's name."

Fix, in this order:

• Missing colon. Character "Mara" with no : at the end. Every World, Character and Enemy line ends with a colon.
• Missing or curly quotes. If a child pasted a name from a document, the quotes may be the slanted kind. Delete them and retype straight quotes on the Chromebook keyboard.
• Nothing is indented. The say line must sit further right than the Character line. If everything is flush left, the character has no lines to speak and stands silent.
• Blank spinner, no world at all. That is the network, not the script. Wait fifteen seconds. Then reload the page once — their text is still there. If it happens on more than three machines at once, it is the school wifi and you should switch to the projector plan (see problem 8).

3. The item is written but isn't in the world

What it looks like: the child swears they wrote the star. They can walk the whole world and there is no star. No error appears — and that is what makes this one nasty.

Say this: "Look at how far right your item line starts. It's tucked under Mara, so the game thinks it's something about Mara instead of something in the world. Push it all the way left."

Fix: item lives at the far-left edge, level with World — never indented under a Character. Indented under a Character it is silently ignored, which is why nothing complains. Correct version:

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

Worth saying to the whole room once, around minute 22: "item goes hard left. Items belong to the world, not to a person."

4. The enemy has a silly name

What it looks like: a monster wandering around called Raider kind: raider. The class finds this extremely funny, which is fine, but the trait didn't apply.

Say this: "Everything after the name has to go on its own line underneath, indented. One idea per line."

Fix: split it.

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

5. The class code doesn't work

What it looks like: "Class not found", or the page just sits there. Usually one or two children, occasionally the whole room.

Say this: "Read it back to me one character at a time." Nine times in ten they read it correctly and have typed it wrong.

Fix:

• One or two children: it is character confusion. Zero versus letter O, one versus letter I, five versus S. Write the code on the board in big, well-spaced capitals and say the ambiguous characters out loud ("that's a zero"). Also check for a space at the start from a copy-paste, and check they are on vxlverse.com/class and not a search results page.
• The whole room: you are probably reading yesterday's code, or a code from a different class. Open your class page on the projector and read the code off it live.
• "We're having trouble right now": that is the server being briefly busy, not a wrong code. Wait a minute and press try again. Do not regenerate the code — you will invalidate the one that is already on the board.

Prevention: leave the code on the board for the entire lesson, not just the first two minutes. Late arrivals and reloads both need it.

6. A Chromebook is slow or the 3D is choppy

What it looks like: the world moves in slideshow steps, or the fan is audible, or Play takes twenty seconds. School Chromebooks are usually the culprit and it is almost never the game's fault.

Say this: "Close every tab except this one. Right now, all of them."

Fix, cheapest first:

1. Close all other tabs. Children accumulate fifteen tabs by second period; this alone fixes most cases.
2. Come out of fullscreen. A smaller picture is much less work to draw.
3. Press Play, don't keep it running. Ask them to stop the game while they are writing, and only Play when they want to check something.
4. If it is still bad: keep the world small. One World, one or two characters, one enemy. Tell them enemies cost the most.
5. If a specific machine is hopeless, pair the child with a neighbour. Two children on one script is a good lesson, not a compromise — one types, one reads the story aloud, swap at the halfway point.

7. A child finishes in eight minutes and is bored

What it looks like: "I'm done." They have a working, winnable game and thirty minutes left. Left alone they will start narrating other people's screens.

Say this: "Good. Now make it so I can't guess what happens. Give me a choice where both answers are tempting."

Fix — hand them one of these, in escalating order. Do not hand them all four.

• Add a real choice with if choice is, where neither option is obviously the right one.
• Add an Enemy, then make them justify it in the story — why is it here, what does it want.
• Add a second character who disagrees with the first. Two people who want different things from the player is the fastest route to an actual story.
• Play a neighbour's game and write down one honest sentence about what confused them. This is the best one: it is peer review, it costs you nothing, and it makes the arcade at the end much better.

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

8. A child freezes and writes nothing

What it looks like: an empty editor at minute 18. The child is not being difficult — they have been asked to invent a world from nothing, in public, and that is genuinely hard.

Do not say "just write anything" or "use your imagination". That is the thing they cannot do right now.

Say this: "Don't invent anything. Copy this exactly, press Play, and then change three words: the place, the person's name, and the thing they want."

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

Fix: the unblock is always a working thing to modify rather than a blank page. If they still stall, ask two closed questions instead of an open one — "forest or desert?" and "who's in it, a person or an animal?" — and type nothing yourself. Once one word is theirs, the rest follows.

9. Two children pick the same nickname

What it looks like: two Dragons on the class page, and at the arcade nobody can tell whose game is whose. Usually it is not a collision at all, it is two friends doing it deliberately.

Say this: "You need a name I can read out at the end and everyone knows it's yours. Add something."

Fix: ask one of them to add a couple of letters — Dragon becomes DragonJK. There are no accounts, so nothing is broken and nothing is lost; the only cost is ambiguity on the class page. If it happens after they have handed in, sort it at the arcade by asking "whose is this?" rather than making them redo anything.

Prevention: say the rule once at join time — "your nickname must be one I can read out loud to the class, so no real surnames and nothing rude". Getting in front of it takes ten seconds; unpicking it later takes five minutes.

10. The projector shows the wrong thing

What it looks like: your class code page is showing while you are trying to demo, or your email is showing, or you are mirroring a child's screen and their half-written game is on the wall.

Fix: use two browser windows from the start, not two tabs — tabs are one keystroke from disaster.

• Window one, on the projector: your class page. This is what is up during joining, and again during the arcade.
• Window two, on your laptop screen only: everything else. Email, register, notes.

If you are demonstrating, do it in the projector window and then go back to the class page. Never open your email in the projector window "just for a second".

For the arcade: you open each child's game from the class page on the projector. That is the whole mechanism — there is no separate arcade tool to set up or fail. Open, play for sixty to ninety seconds, name the person, move on. Decide your order in advance and start with a quiet child, not the loudest game.

If the projector fails entirely: the lesson still runs. Skip the demo and read the six lines out while children type them. The arcade becomes children walking to each other's desks in pairs for two minutes.

11. "I handed in but my game isn't on the class page"

What it looks like: the child is certain they pressed Hand in; the class page doesn't show it.

Say this: "Reload the class page. If it's still not there, press Hand in again — nothing bad happens if you do it twice."

Fix: reload the class page first (it does not update by itself while you leave it open). If it is genuinely missing, have them press Hand in again from their tab. Handing in twice updates the same entry rather than creating a duplicate. If their tab is gone entirely, see the next one.

12. A child closed the tab or the Chromebook slept

What it looks like: panic. "It's all gone."

Say this: "Go back to the class page, put the code and your nickname in again."

Fix: rejoining with the same code and the same nickname is the recovery path, and anything already handed in is safe on the class page. Work done since the last Hand in may not be. This is the practical reason to say, at minute 25 and again at minute 35: "press Hand in now, you can always hand in again later." Treat Hand in as a save button, not a final submission. Say that to the class explicitly, or they will hoard their work until the last minute and one of them will lose it.

13. Thirty laptops playing music at once

What it looks like: the room becomes unusable around minute 20 when the first games start playing.

Fix: get ahead of it. Before anyone presses Play, say: "Volume all the way down, or headphones if you have them. Sound comes on at the arcade." Then have sound on the projector only, at the end. This is a two-second instruction that saves the second half of your lesson.

14. A child writes something rude

What it looks like: a name or a line of dialogue that you would not want on the wall. It is a text editor and they are eleven; expect one per class.

Say this, quietly and without an audience: "This is going on the projector at the end. Change it now and we won't discuss it again."

Fix: the deterrent that actually works is announced in advance, at minute 5: "Everything you write, I read out on the projector at the end." Say it once, lightly, and most of it never happens. When it does, handle it at the desk. If it is still there at arcade time, skip that game and deal with it after the lesson — do not put it on the wall to make a point.

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 and the hand-in in one pass. Delete or ignore the test entry afterwards.
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 page on the projector, everything else on your own screen — and check the projected text is readable from the back row. The editor text is small; increase the browser zoom on the projector window now.
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: decide in advance which five games you will open at the arcade and in what order. Thirty games will not fit in seven minutes, and choosing under pressure means you pick the loudest.

VXLScript — Desk Card

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 — and get ready to play everyone else's on the big screen.