Twenty-eight children are let loose in a school hall with a grid of clues, and the answer to seven across is behind a code taped to the back of a chair. Within four minutes every phone in the room is pointed at the same square of paper, the school wireless has given up, and one code has been peeled off and pocketed.
A code-based game fails in ways a code-based menu never does, because a game concentrates scans in time and place and then depends on every single code working. The design problems are specific and mostly solvable in advance.
The crossword is the easiest version to get right
A crossword where each clue lives behind a code is the tidiest use of the idea, because the hunt is mental rather than geographic. All the codes sit on one sheet in a numbered grid, and nobody has to walk anywhere.
Two things make it work. Keep the payload short, because a sheet with twenty codes on it needs each one small, and a small code carrying a long URL has modules too fine to survive a photocopier. And consider putting the clue text inside the code instead of behind a link. A plain text payload shows the clue on the phone with no page load, no network and no chance that thirty simultaneous scans slow anything down, which removes the entire class of failure the rest of this post is about.
The trade is that a text payload cannot be edited after printing and cannot be counted. For a classroom sheet used once, that is the right trade. For a trail running all season, it is not.
Twenty codes on one sheet also means twenty margins. Each code needs its own four modules of clear space, and a grid packed tight enough that a camera sees two codes at once is a grid where the reader occasionally returns the wrong clue, or nothing at all. Number each code in type beside it so a player can tell which is which, and leave enough space that the finder patterns of neighbouring codes are never in the same frame.
Fifty scans in an hour on a network that was not built for it
A hunt is a load test. Everyone scans the first code within the first two minutes, and the pages behind the codes get hit in bursts rather than spread across a day.
Build the pages the way a walking tour stop is built: text first, one small compressed image at most, no video, no autoplaying anything, no web font delaying the first paint. A few hundred kilobytes in total, not a few megabytes. The walking-tour page budget is the same specification, written for the same problem of a phone on a bad connection standing in front of a physical object.
Then test it on the real network, at the real place, on the worst phone you can borrow, with data saver enabled. A school wireless network with forty devices on one access point, a gallery with stone walls, a park with one distant mast: none of these behave like the wifi the page was built on. If a stop has no usable signal at all, that stop's clue has to be a text payload or printed on the card.
Sequencing without letting anybody skip ahead
The obvious design is a chain, where each code gives the next location. It is satisfying and it is fragile, and the usual attempt to enforce it makes things worse.
Predictable URLs are the leak. If stop three sits at /hunt/3, stop nine is one guess away, and a clever player will have finished before anybody else reaches the fountain. Use unguessable paths with random identifiers rather than a counter, so the only route to a stop is finding its code.
Physical sequencing works better than technical sequencing anyway. A few patterns that hold up:
- Each code gives a fragment of a final answer rather than the next location, and all codes are findable in any order. Nobody can skip, because skipping means missing a fragment.
- Each code gives a clue to the next stop in words, so reaching it requires solving something even if the URL were known.
- Stops are grouped into rounds, and a round opens with a word found in the physical world rather than online.
- Teams start at different points on the same loop, which spreads the load across both the codes and the network.
That last one solves the crowd problem and the queueing problem together, and it costs nothing but a printed start card per team.
One missing code cannot end the hunt
Codes go missing. They get peeled off, rained on, covered by a poster, or taken as souvenirs. Design for it in advance, because a chain with one broken link is a hunt that stops dead with forty people standing in a corridor.
Give every stop page a way forward that does not depend on the next code existing: a written description of where the next stop is, a hint that reveals the answer after a delay, or a printed master sheet in the hands of whoever is running the event. Put a phone number or a room to go to on every card, because the fastest recovery is a person who can simply tell them.
And keep a spare printed set. Ten minutes of reprinting on the morning is worth more than any amount of resilience engineering, and taping a replacement to the wall is faster than fixing anything digitally.
Tape, walls and a week of weather
A code taped to a wall for a week is a manufactured object with a short service life, and what goes wrong is predictable.
Curling is the main one. A card taped at two corners bows away from the wall, and the code stops being a flat plane, which is enough on its own to stop a reader. Tape all four edges, laminate the card, or mount it on something rigid. Laminate has its own cost, because a gloss finish reflects overhead lighting straight into the camera, and gloss and lamination problems are worth reading before laminating a set of fifty.
Height is the other one. A code at adult eye level is out of reach for a child and for anybody seated, and a hunt aimed at children should be mounted at their height, which is also where the scuffing happens. Somewhere between a doorknob and a light switch suits more people than either extreme.
For anything outdoors, print on UV-stable stock and expect ordinary paper taped to a wall to last days rather than weeks. Walk the route on day three and again on day six, because something will have moved.
When a clue turns out to be wrong
This is the argument for a dynamic destination, and it is stronger in a game than almost anywhere else.
Clues have errors. A direction says left when it means right, an answer has two valid spellings, a stop closes for maintenance halfway through the week. With a static code the printed card is the destination, and the only fix is reprinting and re-taping every copy. With a dynamic code the wrong clue is a page edit and the cards on the walls never move. Changing a printed code's destination is the general version of this, and a live event is the case where the difference gets measured in minutes.
The counts help in one specific way. Scans per code over time show which stop people stop reaching, the same drop-off reading a walking tour gives you, and a sharp fall between two consecutive stops almost always means the directions between them are wrong. Museum trails run on exactly that measurement indoors.
Run it once with four people
Before printing thirty sets, build two stops, tape them up, and send four colleagues through on their own phones with no explanation. Ten minutes will tell you three things: whether the codes scan at the height you mounted them, whether the first page loads on the venue's network, and whether the clue means what you thought it meant.
Then scale it. For a classroom version, the classroom applications post has more ideas for what goes behind the codes, and the mechanics above are what keep any of them working with thirty players in the room.
