Build a classroom review game in an afternoon

At the end of an afternoon you will have a review game your class plays from their phones: you host it on the projector, students join by typing a short code, questions come from your own material, and the scoreboard updates between rounds. No app, no accounts, no logins.

You do not write any code. You describe what you want, test it, and tell the assistant precisely what broke. The prompts below are the real ones — copy them, change the bracketed parts.

Before you start

Use an assistant your college provides, with code execution, not a personal paid subscription. If you are going to require students to use AI for something, Chancellor's Office guidance is that it should run on institutionally supported tools — and the same logic applies to you building the thing in the first place.

Set aside two to four hours for the first one. The second one takes about forty minutes, because the hard part is learning the loop, not the game.

Step 1 — Make it design before it builds

Paste this and then actually have the conversation. Do not skip to building.

You are helping me build a browser-based classroom review game. Before writing any code, talk me through the design and then summarise it back for my approval.

Requirements:

— I host it on a projector from my laptop. Students join from their own phones by typing a short room code. No accounts and no app install.
— Between 2 and 40 players.
— I supply my own questions: multiple choice, four options, one correct.
— Each round: the question appears on my screen and on their phones, they tap an answer, there is a timer, then the correct answer and the scoreboard.
— Scores carry across rounds, with a final scoreboard at the end.
— It has to work on an ordinary phone browser on cellular data.

Ask me about anything ambiguous, one decision at a time. Then summarise the rules, the screens and the data flow before building anything.

Answer its questions out loud as they come. When it summarises, read the summary properly and fix what is wrong before you say go. This is the cheapest minute in the whole project: a misunderstanding caught here costs a sentence, and the same misunderstanding caught after the build costs an hour.

Step 2 — Get the smallest version running

Build the version we agreed. Get the core loop working first — join by code, one question, answers collected, scoreboard — before any styling at all. Run it locally and give me a URL I can open in my browser to test.

You will get back an address like http://localhost:5173. Open it. That runs on your laptop only — nobody else can reach it yet, which is fine for now.

Step 3 — Test it as two people

Open the game twice: a normal window as the host, and a private window as a player. Better still, host on the laptop and join from your own phone. Play two rounds and write down everything that is wrong. Do not fix anything yet — noticing and fixing are different jobs, and people who fix while they test stop noticing.

In this kind of game, these are the things that are actually wrong, in rough order of likelihood:

• A player who joins mid-round sees a blank screen until the next question.
• Clicking "next" twice skips a question.
• The timer keeps running after everyone has answered.
• The scoreboard shows last round's scores.
• A phone that sleeps and wakes cannot rejoin, or rejoins as a new player with zero points.
• Two players answering at the same instant produce one score, or three.
• A second game uses the same room code as the first.

Step 4 — Describe each bug in one sentence

One bug per message, in this shape:

When I did [exactly what you did, and in which window], I expected [what should have happened], but instead [what actually happened]. Fix that and keep the change small.

A real one from this build:

When I joined from a second phone while round 2 was already running, I expected to see the current question with the timer, but instead the phone showed an empty screen until round 3 started. Fix that and keep the change small.

Vague reports get vague fixes. "It's broken" produces a rewrite of something that was working. The precision is the whole skill, and it is the same sentence structure you would use filing a ticket at work.

Expect several passes. If a fix breaks something that previously worked, say exactly that, and ask it to restore the earlier behaviour while keeping the new fix.

Step 5 — Load your own questions

Let me load my own questions instead of the samples. Add a way to paste a plain list, one question per line, in this format:

question | option A | option B | option C | option D | correct letter

Validate what I paste and tell me which line numbers are malformed rather than failing silently. Keep the questions in the browser — do not send them anywhere or store them on a server.

Now paste in fifteen real questions from your own course. This is the moment the thing stops being a demo. Write the questions in a plain text file first so you can reuse them next term.

Step 6 — The accessibility pass

Generated interfaces ship with unlabelled buttons and colour-only feedback by default. This is not optional polish — if it is course material, accessibility applies to it from the first day of class, not when a student requests it.

Do an accessibility pass on this. Every control must be reachable and operable by keyboard alone with a visible focus indicator. Every button and input needs an accessible name. Do not signal correct or incorrect by colour alone — add text or a shape as well. Check that text contrast meets WCAG 2.1 AA. Make sure the timer does not trap keyboard focus, and that a screen reader announces the question and then the result. Tell me what you changed, and what still needs me to check by hand.

Then check three things yourself, because the assistant cannot: unplug your mouse and play a full round with the keyboard only; turn on VoiceOver or Narrator and listen to one question and one result; and look at the projector from the back of an actual classroom, which is where small grey text dies.

Step 7 — Make it look like something

Restyle it and keep the game logic exactly as it is. Mood: [e.g. late-night quiz show]. Colours: [two, plus one accent for buttons]. The host screen is on a projector, so the question needs to be readable from the back of a room. The phone screen should be one question and four large tap targets, nothing else. Apply it to every screen.

Saying "keep the logic exactly as it is" matters. Restyling and fixing at the same time is how you break something you already tested.

Step 8 — Publish it and test it cold

Get this ready to publish, with whatever small backend it needs. Walk me through publishing it step by step, and give me the live URL.

Then open the live link on a device that was never part of the build — ideally your phone on cellular, with wifi off. Hand it to a colleague and watch them join without saying anything. Ninety seconds of that tells you more than an hour of your own testing, because you know where everything is and they do not.

Running it in class

• Test on the room's wifi, in the room, before class. Thirty phones on a crowded access point is a different situation from two devices at your kitchen table, and it is where this breaks.
• Use nicknames, not real names. A leaderboard with student names on a projector is a privacy problem you do not need. If the game is graded, it is a bigger one — so don't grade it, or score it privately.
• Plan for students without a usable phone. Pairs work and are often better anyway, because they argue about the answer.
• Have a paper backup. Print the questions. If the room's network fails you teach the same fifteen minutes without it and nobody notices.
• Put the room code somewhere permanent on screen, not just on the join screen. Someone always arrives late.

When it breaks mid-class

It will, once. Stop playing, finish with the paper version, and write down exactly what happened while it is fresh — what you did, what you expected, what happened instead. That sentence is the first message of your next build session. It takes ten minutes to fix afterwards and nothing at all during class, where fixing it is not an option.

Doing it again

The second game is a different beast. Keep the conversation, change the requirements at the top, and you are mostly reusing a working build. Variants worth making: a sequencing game where teams put steps in the right order, a diagnosis game where a scenario appears and teams pick the next step, a vocabulary speed round, a two-truths-and-a-lie round where students write the items.

The game is not the valuable part. The valuable part is that you now know what it feels like to specify something, watch it fail, describe the failure precisely, and get it working — which is the same loop whatever you build next, and the thing worth putting in front of students.

Companion pieces on this site: the workflow Building a working thing you could not build alone for the general version of this loop, and the lesson Assigning an AI build if you want to turn it into a graded student project with outcomes and a rubric.