French Toast

It started as a game we played out loud on holiday. The app came later, so we could keep playing once we'd gone home — without one person running the whole round by hand in a group chat.

There was a second reason to build it. I wanted to learn how a real-time multiplayer app fits together, and to get better at working with an AI assistant on something that had to hold up in use rather than a tutorial exercise, so I built this with AI throughout. A game your friends actually play turns out to be a good test of both — they tell you when it breaks, and the sections that follow are largely a record of the things I only understood after it did.

One player is the host and picks a secret noun. Everyone else is a guesser, and nobody may ask a direct question about it. The only legal move is a comparison:

“Is it more like French Toast or a pancake?”

Every round opens from the same place: the first comparison is always against French Toast, which is where the game gets its name.

The host answers by tapping one of the two options. That answer becomes the left-hand side of the next comparison, so the question drifts steadily toward the secret as the group narrows it down. Guessers can also request a free-text clue, guess outright, or collectively concede. Whoever guesses correctly hosts the next round.

Everything runs in a mobile browser with no install. One player opens the file, taps Create a room, and taps the six-character code to copy it; everyone else pastes it into their own browser to join. Two is enough for a game — a host and one guesser — and it stays comfortable up to about eight, past which the host spends the whole round answering. Nothing in the app enforces either end: a room holds as many people as join it. The screens below show a three-player round.

Create or join

Lobby · tap to copy

The whole app is french-toast.html — roughly 440 lines of CSS, 150 of markup, and 1,050 of JavaScript in a single <script type="module">. There is no package.json, no bundler, and no server code. It is also the file the game link serves, unminified and commented — open the game and View Source (Ctrl/⌘ + U) to read along with the extracts below. Two things load from a CDN at runtime: the Firebase modular SDK (v10.12.2, app + database only) and three Google Fonts.

The single-file shape was a deliberate choice. A party game gets opened cold, by people who just want to start playing — so the deploy story had to be “host this file anywhere,” and the cold-start cost had to be one HTML request plus one socket.

The shape suited how it was built, too. One file with no build step means the whole app fits in an AI assistant's view at once, so a question about the presence code could be answered with the rendering code still in front of it, rather than reasoned about across a tree of modules. It also means there is nothing between what you read and what runs. The cost of that is in the table below: no type checking and no test runner, so anything neither of us spotted stayed unspotted until a real round turned it up.

The one piece of genuinely stateful game logic is the subject — stored as inPlay. It seeds as the literal string "French Toast", and every answer the host gives overwrites it. This is what makes the game converge instead of producing a flat list of unrelated comparisons.

// Record the answer AND promote the chosen option to be the new subject
async function answerComparison(cid, answer) {
  await update(roomRef(state.roomCode), {
    [`comparisons/${cid}/answer`]: answer,
    inPlay: answer
  });
}

Two ways to win

A round can be won in two ways:

1. by typing the secret into the Guess box, or
2. by naming the secret as the other half of a comparison in the Ask box.

The second is possible because a comparison is free text, so a guesser can land on the secret as their option Y — sometimes by accident, sometimes on purpose. To catch wins entered that way, askComparison() checks the option against the secret before writing the comparison, and routes a match into the same win path a direct guess uses:

// If the asked option is actually the secret word, that's a win.
if (norm(y) === norm(secret)) {
  showToast("You named it! 🎉");
  await declareWin(y, secret);
  return;
}

A guesser's screen

Both entry points funnel into one declareWin(), which appends the winning guess to the shared feed and ends the round in a single update() — so there is exactly one place where “round over, and who hosts next” is decided.

There is no client-side state machine mirroring the server. Each player holds a single onValue subscription on rooms/{CODE}, and every change to any part of the room delivers the entire room object to render(data), which rebuilds the screen from scratch.

The host, mid-round

The cost is that every keystroke-sized change rebuilds the feed, but for a room of a handful of players with a few dozen entries that is free.

When Camille taps Ask, nothing appears on Camille's own screen yet. The comparison goes to Firebase, and Firebase sends the updated room back to everyone — Camille included — so the new card lands on every screen at the same moment. That costs the asker one round trip of waiting, and in return whole classes of bug never come up: nothing is ever drawn and then taken back, no screen keeps its own copy of the room that could drift out of step, and no “my screen says pending but yours says answered.”

Rendering the feed

Comparisons, guesses, and clues live in three separate collections but read as one chronological conversation. renderLog() flattens all three into a single array, sorts by server timestamp with the push-id as a stable tiebreaker, and dispatches each item to its own card renderer:

items.sort((a, b) => (a.ts === b.ts ? (a.id < b.id ? -1 : 1) : a.ts - b.ts));

serverTimestamp() resolves at coarse millisecond granularity, so two players tapping at once will collide. When that happens the lexicographic push-id breaks the tie, and since it reads the same everywhere, the ordering comes out identical on every device.

Handling the clue input

Rebuilding the feed is free while every card is read-only text. The clue card is not: on the host's screen a pending request renders a text field and a Send button, so the DOM is holding state the room document has no copy of — the partly typed clue, the caret position, and an open keyboard.

Snapshots keep arriving regardless. Heartbeats (§07) deliver one every few seconds, and any other player asking, guessing or conceding delivers more. Each one wiped the log and built a fresh <input>. On iOS, losing the focused element dismisses the keyboard and the replacement re-presents it, so the keystrokes in between go nowhere — a keyboard that flickers and a field that intermittently ignores you.

So the feed reconciles, and nothing else does. Each item is keyed by its push id and cached against a signature: every field the card renderer reads, including which role is looking, flattened into one string.

function itemSig(item) {
  const d = item.data;
  const role = state.isHost ? "h" : "g";
  // …comparison, guess and clue each flatten their own fields
  return ["l", role, d.name, d.clue == null ? "" : d.clue].join(S);
}

reconcileLog() rebuilds a card only when its signature changes, then walks the desired order calling insertBefore only where a node is not already in the right slot. A card that has neither changed nor moved is never detached from the document, so focus, the caret and the half-typed clue survive any snapshot that doesn't concern them.

The field also carries autocomplete="off", autocorrect="off" and spellcheck="false", which suppress Safari's AutoFill and QuickType bars — the pill with a tick above the iOS keyboard, which players read as a third Send button alongside the real one and the return key. enterkeyhint="send" labels the return key to match. All three routes call one handler, behind a sending flag so a tap and a return in quick succession write the clue once.

One room is one subtree, keyed by its share code. Everything about a round lives under it, so resetting a round means clearing the four collections that fill up as it is played — comparisons, guesses, clues, and surrenders — while the room code, the players, and the host stay put. Writing null to a path is how Firebase deletes it, and all four go in a single update(), so no client can catch the room half-cleared.

rooms/
└── K4M2PQ
    ├── host          "p_8fk2ma91x7q"   // each winner — or an heir, if the host leaves
    ├── status        "lobby" | "active" | "ended"
    ├── word          "bGlnaHRob3VzZQ=="   // base64(secret noun)
    ├── inPlay        "a pancake"          // the current subject
    ├── winner        "Camille"
    ├── winnerId      "p_8fk2ma91x7q"
    ├── winnerWord    "lighthouse"         // plaintext, only once ended
    ├── endReason     "guessed" | "revealed" | "surrender" | "hostleft"
    ├── players/
    │   └── p_8fk2ma91x7q   { name, id, lastSeen }
    ├── comparisons/
    │   └── -NqA1x…         { x, y, askerName, askerId, answer, ts }
    ├── guesses/
    │   └── -NqA2y…         { name, id, guess, correct, ts }
    ├── clues/
    │   └── -NqA3z…         { name, id, clue, ts }
    └── surrenders/
        └── p_8fk2ma91x7q   "Camille"

Room codes

Six characters from a 31-symbol alphabet with the confusable glyphs removed — no I, L, O, 0, or 1. The code gets copied into a group chat and pasted back in to join, so it stays short, and dropping the look-alikes means it still reads cleanly on the rare occasion someone types it by hand. That is ~887 million combinations; createRoom() still probes for an unused code, retrying up to eight times.

const chars = "ABCDEFGHJKMNPQRSTUVWXYZ23456789"; // no easily-confused chars

status has three values and render() routes on it directly — the screen you are looking at is a pure function of the room document. Three different things can end a round, and only one of them moves the crown.

The reveal

The four collections from §05 are actually cleared twice, by two different functions writing the same fields. playAgain() clears them on the way back to the lobby, and startGame() clears them again as the next round begins. The second pass is the one that matters: it means a room arriving at active starts with an empty feed no matter how it got to the lobby, so nothing from a previous round can survive into a new one.

Joining mid-round needs no special handling: a player who enters an active room is routed straight to the game screen as a guesser by the same status switch. That is why the room code stays visible as a tappable chip during play.

Leaving mid-round mostly needs none either — a guesser who quits is just a name that stops heartbeating. The host is the exception, because the round cannot continue without the one person who can answer it, and it cannot simply be handed on either: the secret word travels with the crown, and every candidate heir is someone still trying to guess it. So the fourth exit edge takes the round to ended with endReason: "hostleft", reveals the word to everyone at once, and leaves the new host holding “Play again” for a fresh round with a word of their own. Who that new host is, and how the room agrees on them without a server to decide, is §07.

This took more iterations than the rest of the app combined. The naïve approach — Firebase's onDisconnect() to remove your player record — is correct on desktop and wrong on a phone, which is where the game is actually played.

The problem: iOS Safari fires pagehide and visibilitychange when you merely switch apps or lock the screen. Glance at a text message mid-round and you would disappear from everyone's roster. Meanwhile the opposite failure also existed — genuinely quitting the app doesn't reliably close the socket promptly on mobile, so players who had left lingered in the list.

Both are solved by not trusting lifecycle events at all. Presence became a heartbeat: a player is “here” while their lastSeen timestamp stays fresh, with three thresholds doing three different jobs.

Clock skew

Freshness checks compare your clock against their server-stamped lastSeen, which breaks on any device whose clock is off. The app subscribes to Firebase's measured offset and corrects for it everywhere:

onValue(ref(db, ".info/serverTimeOffset"), (snap) => { state.serverOffset = snap.val() || 0; });

function serverNow() { return Date.now() + (state.serverOffset || 0); }

Records with no lastSeen at all are always treated as present, so player rows written by an older version of the app never vanish mid-game.

Handling a page reload

A reloading player is disconnected for a moment, and the app used to treat that as leaving: the player id was made up fresh on every load, so you came back a stranger with the same name while the seat you had just vacated sat in the room going stale.

On a phone that happens by accident. The lobby is short enough to sit at scroll-top, where a stray downward flick becomes iOS Safari's pull-to-refresh — so players were being dropped out of rooms by a gesture they had not meant to make, and a host making one left everyone else stranded.

Two independent fixes. overscroll-behavior-y: contain on the root stops pull-to-refresh firing where it is supported; the rest covers the browsers that ignore it, and deliberate reloads.

Identity moved into sessionStorage, which is scoped to the tab and survives a reload but not a close. Refresh and you return to your seat; close the tab and you are gone. A second tab is still a second player, which is what lets one browser play both roles while the game is being worked on — localStorage would have persisted identity just as well and broken that.

const state = {
  // Same tab, same player — a reload keeps the id, a new tab mints one.
  playerId: (restored && restored.playerId) || randomId(),
  playerName: (restored && restored.name) || storageGet(localStorage, NAME_KEY) || "",
  // …
};

The room code is stored in the same record, so resumeSession() re-stakes the seat and reattaches the room listener before anything else reads the roster. The status switch of §06 does the rest: a reload lands you back in the lobby, the game or the reveal screen according to the room, with no separate resume path per screen. The crown needs no special handling — data.host === state.playerId is the same comparison as always, and the id came back with the tab.

Every storage call is wrapped in a try: Safari throws on sessionStorage access in Private Browsing rather than returning null, and a game that cannot remember you is better than one that will not start.

When the player who goes is the host

Presence answers “who is here”. It took a real round to notice that nothing was reading the answer back against host. That field is only a player id, so a host who closed their tab left it pointing at somebody who was no longer in the room — and nothing in the app ever looked. The lobby stayed up with the roster ticking along and not one phone showing a Start button; a round in progress kept accepting questions that would never be answered. There was no way back short of everyone leaving and starting again, because becoming the host was not something a player could do.

The fix has to work without a server to arbitrate, and without every remaining phone reaching a different conclusion at the same moment. Two paths cover the two ways a host can go.

A clean leave hands the crown over on the way out. The leaver still has the room in front of them, so handOverBeforeLeaving() picks the successor and writes it in the same trip that removes them. If there is nobody to hand it to, they delete the room instead — the last player out closes the door, which is also the one case of an abandoned room this app now cleans up after itself.

A closed tab cannot hand anything over, so the room elects. Every remaining client already receives the same snapshot and already computes presentPlayers() from it, so all of them can see the host is gone at roughly the same time. What stops that becoming a scramble is that the election rule is arithmetic rather than a race: the heir is the lowest-sorting present player id, which reads identically on every device. Everyone works out the same answer, and only the one client that recognises itself in it writes anything.

// Deterministic successor: lowest-sorting present id that isn't the outgoing
// host. Every client computes the same answer from the same snapshot.
function successorHost(ids, outgoingId) {
  return ids.filter(id => id !== outgoingId).sort()[0] || null;
}

Two guards sit in front of that write. A grace window of HOST_GRACE_MS (10s) has to elapse with the host still missing before the heir acts, and the heir re-reads the room immediately before writing, in case the host reappeared inside the window or another client got there first. Ten seconds is deliberately generous, because the two things the window has to tell apart look identical from outside: a host who has quit, and a host whose page is reloading. Both drop the socket, and onDisconnect clears the seat for both. Promoting into that gap is the destructive mistake — it ends the round and reveals the word to a room that was still playing — so the window is sized to sit out a page load rather than to be quick. Both are cheap, and both fail in the harmless direction — the worst case is that nothing happens on this snapshot and the next one tries again.

What the new host does not inherit is the round. The secret word is in the room document, so promoting a guesser mid-round would hand them the answer to the question they were still working on. hostHandoverFields() therefore ends the round in the same write as the handover — the word is revealed to everybody at once, which is the same outcome as the host pressing Reveal, and the new host starts a fresh round with a word of their own. In the lobby and on the reveal screen there is no round to protect, so the crown moves on its own.

function hostHandoverFields(data, newHostId) {
  const fields = { host: newHostId };
  if (data.status === "active") {
    fields.status = "ended";
    fields.endReason = "hostleft";
    fields.winner = null;
    fields.winnerId = null;
    fields.winnerWord = decodeWord(data.word || "");
  }
  return fields;
}

A player looking at their phone needs to know the host answered. Every obvious mechanism for that is unavailable on at least one target platform, so notify() fires several in parallel and relies on whichever ones the device supports.

Two of those channels are easy to mix up. A Web Notification is handed to the operating system, so it can surface on a lock screen or in a notification centre while the tab is hidden. An in-app toast is drawn by the page itself — the dark pill that slides up from the bottom of the screen, sits for a couple of seconds and fades on its own — so it only lands if the player is already looking. That is why the table below has them firing in opposite situations.

Sound is the channel that has to work on iOS — the platform this game is mostly played on — but WebAudio requires a user gesture to unlock. That gesture is harvested from the only two taps guaranteed to happen before any game activity:

$("create-btn").addEventListener("click", () => { unlockAudio(); requestNotifyPermission(); createRoom()… });
$("join-btn").addEventListener("click",   () => { unlockAudio(); requestNotifyPermission(); joinRoom()…   });

The beep is a two- or three-note motif rather than a single tone, pitched by event class: rising thirds for a win, a bright pair for an answer, a plain fifth for routine pings — so you can tell them apart without looking.

Not spamming the room

Two mechanisms keep cues from becoming noise. Routine feed events pass quiet: true, which suppresses the visual toast while keeping the sound — the feed itself is already the visual signal. And every counter is resynchronised on the first render after joining or reconnecting:

// On first render of a game (join / (re)connect / start) just sync the
// counters so we never replay history as fresh cues.
if (!state.synced) {
  state.synced = true;
} else {
  /* … diff counts against last render, fire cues … */
}

Without that flag, a player reconnecting to a busy room would get a burst of beeps for twenty things that happened while they were away. Cues are also role-aware: the host is told “new question to answer,” guessers are told “the host answered a comparison,” and neither is notified about their own guess.

Anything a player types stays text

Names, comparison options, clues and guesses are all typed by one player and then drawn on everyone else's phone. So suppose Margot joins the room under the name <b>Margot</b>. On every other screen that has to appear exactly as typed, angle brackets and all — it must not turn the roster bold, and if someone typed a <script> tag instead, it must not run.

The app never builds a page by gluing strings of HTML together. Every piece of player text goes through one small helper, el(), which makes the element and then puts the text in with textContent:

function el(tag, opts = {}, children = []) {
  const node = document.createElement(tag);
  if (opts.class) node.className = opts.class;
  if (opts.text != null) node.textContent = opts.text;
  …
}

textContent hands the browser characters rather than markup: a < stays a < on screen instead of starting a tag. That is the whole defence, and it means there is nothing to escape and no list of banned characters to keep up to date. The one place the app does write raw HTML is innerHTML, which appears three times — all three inserting the same fixed mascot drawing, with no player text anywhere near it. There is also an escapeText() helper, but despite the name it escapes nothing: it only turns a missing value into an empty string.

Judging a guess the way a person would

In the round in the screenshots, the secret was lighthouse and Camille typed a lighthouse. That has to count — nobody refereeing in person would rule it out on the strength of one article. norm() does that judging before the two strings are compared: it trims the ends, lowercases, squashes runs of spaces down to one, and drops a leading the, a or an. The article is only removed when something is left over afterwards, so a secret that is the word “the” still works:

v = v.replace(/^(the|a|an)\s+(?=\S)/, "");

When the last two players give up at once

A round can also end by everyone conceding. Say Camille and Margot are the last two guessers left and both tap Céder in the same second. Each vote reaches Firebase before the other one has come back, so neither player is ever looking at a room where everybody has given up — and without a fix the round would sit there, ended by nobody.

Two things prevent that. First, whoever concedes adds their own vote to the copy of the room they are already holding before checking whether the vote is unanimous, rather than waiting for it to come back from Firebase. Second, the host checks the same thing on every render, as a backstop:

// Host safety net: if everyone has given up, reveal (covers a simultaneous
// last-two-votes race where neither voter saw the other's write).
if (state.isHost && guesserIds.length > 0 && gaveUp === guesserIds.length && data.status === "active") {
  revealFromSurrender(data).catch(() => {});
}

Both routes call the same function, which checks the round is still active and then writes a fixed set of fields. If both fire, the second one writes exactly the same values as the first, so the room ends up in the same state either way — which is why nothing here needs a lock or a queue.

Errors that say something

Firebase's own errors are unhelpful the first time you set the game up — you get a raw code where you wanted to know what to do about it. errMsg() looks for the two failures that actually happen at that point and swaps in a sentence naming the fix:

Three things cannot be taken back once done — leaving a room, revealing the word, and conceding — so each one puts up the browser's own confirm() box first. A mis-tap on Reveal the word would end the round for everybody. The plain browser dialog is not pretty, but it is the one thing that comes out correct on every device without any styling of its own.

Every one of these was a conscious call for a game played by a group of friends who know and trust each other — not strangers on the internet. The app uses Firebase's free tier and its test-mode database rules on purpose: it costs nothing to run, rather than coming with a backend to maintain, a bill, and an account system nobody wants to sign up for.

So read the fixes below as what this would need if it were ever opened up to strangers, not as a list of outstanding work. None of them are worth doing for the group it was built for, and several would make it worse — a login screen between a friend and a party game is a cost, not a feature.

Where I'd start on a version for strangers

1. Turn on anonymous sign-in and write proper database rules. Firebase can sign players in behind the scenes, without anyone creating an account, and the rules can then stop a player writing anywhere except their own room. Nobody playing would notice, and the database would no longer be open to anyone who finds the address.
2. Move the winner check off the player's phone, so a Cloud Function compares the guess against a word the browser is never sent. This is the only one that costs money — Cloud Functions need a paid Firebase plan — which is why it has stayed on the list rather than getting done.
3. Keep score between rounds. The crown moves to whoever wins, but nothing is written down, so a counter per player would be enough to see who is ahead over an evening.

You need a Firebase project with Realtime Database enabled, and any way to serve one file over HTTPS. HTTPS is important: copy-to-clipboard and the sound only work on a page served over HTTPS, or over localhost, which browsers treat as safe. Opening the file directly with file:// is fine for a look around but not for a real game.

1 · Create the database

In the Firebase console, create a project, then Realtime Database → Create Database. Start in test mode to get playing; see §10 for why you should not leave it there if you intend to play more than a few rounds, or open up to a wider audience.

2 · Paste your config

Register a web app under Project settings → Your apps and replace the firebaseConfig block near the top of the module. databaseURL is required and Firebase sometimes omits it from the snippet:

const firebaseConfig = {
  apiKey:            "…",
  authDomain:        "<project-id>.firebaseapp.com",
  databaseURL:       "https://<project-id>-default-rtdb.firebaseio.com",
  projectId:         "<project-id>",
  storageBucket:     "<project-id>.firebasestorage.app",
  messagingSenderId: "…",
  appId:             "…"
};

3 · Serve it

python3 -m http.server 8000
# then open http://localhost:8000/french-toast.html

For a real game, any host that can serve a plain file over HTTPS works — there is nothing to compile first. Netlify is the easy one: drag the folder onto the dashboard, or point it at a repository, and it serves the file over HTTPS on a free plan. This game runs there, at frenchtoastgame.netlify.app. Open it on a phone, create a room, and join from a second device to test both roles.

Testing multiplayer alone

Two ordinary tabs are enough: each tab makes up a new player id when it loads, so one browser can host and guess at the same time. Some behaviour only appears on real hardware, though — the iOS backgrounding that shaped §07 cannot be reproduced on a desktop, and neither can the spread of notification behaviour in §08.