C5 · Week 6: A game

A small game gives tests and human judgement different jobs.

build a tiny browser game — one mechanic is usually enough — obvious in ten seconds, still interesting at five minutes, no tutorial in sight

Last week’s instrument had no way to be played wrong; this week that’s exactly the point. A game has rules, stakes and an ending: a player can fail, and play finishes somewhere.

Interpret game as broadly as you like: an arcade loop, a puzzle, a Twine-style narrative experience — if it invites play, it counts. The twist is the no-tutorial rule. Bushnell’s law says the best games are easy to learn and difficult to master; here the learning half has to happen without words. No how-to-play modal, no instructions page, nothing in the README standing in for either: name the game if you like, but the opening screen itself has to make the first move obvious (game designers call this affordance — World 1-1 of Super Mario Bros. is the canonical worked example), and play teaches whatever comes next. Depth is what makes the five minutes work: something that needs no explaining and holds attention that long has something under the surface, a skill that sharpens or a choice that matters or a thread worth pulling. One mechanic is usually enough to get there, and two that interact is the harder, better move if you can keep a stranger finishing inside five minutes.

Put one rule under a focused automated test, then play the finished game at both marking viewports. A test can establish that a collision ends the round; only playing can tell you whether the collision feels fair. Keep it static: a client-side game or a Twine-style branching story needs no backend, and it ships straight to GitHub Pages.

Your pod plays it cold, the same as C4 — but this week you stay quiet until someone has finished it or given up. The no-tutorial rule is the one thing here you can’t put under test and can’t fake, and four people’s hands on the keyboard settle it in about ten seconds.