The Show Floor Build: A Festival Demo That Survives Ten Hours of Strangers

Hour three of a two-day festival. A player sits down, mashes past a menu they did not read, walks into the second room, opens the inventory, and cannot get out because the close button is bound to a key the previous player remapped. They shrug and leave. The four people behind them in the queue watch the whole thing and drift toward the next table.

That is not a bug report. That is forty minutes of booth time and five potential wishlists gone, and it will happen again at the next event unless you treat the show build as its own deliverable.

A festival build is not your Steam demo with a shorter level. The player is standing in a loud room with no idea what your game is, no patience for a settings screen, and a friend waiting. You are not there to explain — you are there to watch. Everything has to work without you.

The show build is a different product

Write down the constraints before you cut anything, because they drive every decision that follows.

Constraint	Normal demo	Show floor build
Session length	20–40 minutes	5–8 minutes, hard cap
Who starts it	The player, at home	A stranger, mid-conversation
Who explains it	Your tutorial	Nobody, including you
Audio	Headphones, quiet room	85 dB of crowd noise
Failure recovery	Reload a save	Reset the whole thing in seconds
Reads per session	One player, repeated	50–80 different players per day

The last row is the one people underestimate. Over a ten-hour day, at five minutes a session plus turnover, one station gives you 50 to 80 complete first-time sessions — more cold-player data than most small teams collect in months of friends-and-family testing, if the build is set up to produce it.

Budget the session in minutes, not content

Pick a number and design to it. Six minutes is a good default: long enough to teach one verb and deliver one payoff, short enough that the queue keeps moving and the player leaves wanting more.

Then build backwards from that number:

• 0:00–0:20 — no logo, no splash, no studio card. Controls are on screen or on a card taped to the table.
• 0:20–1:30 — teach exactly one verb. One. If your game is a grapple-hook platformer, they grapple. The crafting system does not exist today.
• 1:30–4:30 — one escalation and one payoff: a bigger room, a chase, a small boss.
• 4:30–6:00 — a deliberate ending: a results screen, a "thanks for playing" card with a QR code to your store page, then back to the attract loop.

Cutting to six minutes is where the hard calls happen. Keep a running list of what you removed and why — a decision log is a reasonable home for it, because you will re-argue every one of those cuts before the next show.

Build a loop, not a level

The single biggest difference between a festival build and a demo is that a festival build has no idle state. It is always either being played or inviting someone to play.

Attract mode. After 45 seconds with no input, drop into a 60–90 second loop: gameplay footage, your title, and the words "press any button". This is what pulls people out of the aisle. A captured session rendered to video and looped is fine, and is more reliable than running the game in a demo-AI mode.

Hard reset. Any button press from the attract loop starts a new session from a known state. Nothing carries over: no save file, no unlocked upgrades, no remapped keys, no volume setting, no camera inversion from the person who flipped it twenty minutes ago. Ship one ResetToShowDefaults() path and call it on every session start, not on quit — the build will crash, and the next player still needs a clean run.

Reset in under five seconds. Time it with a stopwatch. If a reset means alt-tabbing, killing a process and relaunching, you lose a minute of booth time every time — while talking to someone.

No way out of the game. No quit-to-desktop, no exit on Escape, no window border. Borderless fullscreen, with OS notifications, updates and sleep disabled. An update dialog in the middle of your boss fight is a real failure mode.

The five things that break on a show floor

These are the ones that reliably bite small teams, and they are all cheap to fix in advance:

1. Soft locks in menus. Anything a player can open, they can open at the worst moment. The fix: delete the menus. One pause screen with "resume" and "restart", nothing else.
2. Text too small to read standing up. You tested at 60 cm from a monitor. They are 90 cm away and leaning back. Bump body text until it reads from two metres, then test it from two metres, standing.
3. Audio that disappears. Crowd noise eats your mid-range. Mix a separate show preset with music down, impact and UI confirmation sounds up, and use over-ear headphones if the venue allows them.
4. Second controller chaos. Keyboard and a plugged-in pad will both drive the player, and a pad bumped on the table can push a stick and ruin a session. Pick one input device and disable the others.
5. State bleed between players. Difficulty, mute toggles, remapped keys, accessibility options, a tutorial-seen flag. All of it must die on reset. See above.

Instrument it, because nobody will fill in a survey

A loud room is terrible for questionnaires and great for counters. Log events to a local file keyed by session — not to a server you are not sure the venue's wifi will reach — and keep the list short enough to read on the train home:

• session_start and session_end, with duration and how it ended (timer, death, quit, walked away)
• first_verb_used with the timestamp — the single most useful number you will get
• room_reached at each gate
• death with location and cause
• pause_opened, attract_entered

With 60 sessions a day, those counters give you a real funnel. If 55 players enter room two and 12 reach room three, you do not need an opinion about room two — you need to fix it. Put the build hash in the filename and keep that build tagged where you track builds, so Saturday's data is not quietly mixed with the hotfix you shipped on Sunday morning. If you log playtests in GameDesignerX, file the whole event as one session group against that build — it keeps the funnel attached to a version instead of to "the convention".

Watch, don't coach

The hardest discipline at a booth is silence. The moment you say "you can double jump", you have destroyed the only honest reading of the day. Hand over the card, say "it's about five minutes", then watch their hands and shoulders.

Two questions when they stand up, asked the same way every time:

• "What were you trying to do right there?" (asked about one specific moment you saw)
• "What would you expect to happen next if you kept playing?"

Write the answers on an index card between sessions. You will not remember them.

Table checklist

Two weeks out

• Six-minute build branches off main and is feature-frozen
• Attract loop, hard reset, show audio preset, large text pass
• Event logging to a local file, build hash in the filename
• Run it for a full hour without touching it

The day before

• Two identical machines or one machine plus a tested spare
• Controllers: one per station plus one spare, all charged, cables taped
• Printed controls card, A5, one per station
• Sign with the game name and one sentence that says what you do
• OS notifications, updates, screensaver and sleep disabled
• Build copied to two USB sticks

Each morning

• Clean install from the stick, not yesterday's patched folder
• One full playthrough before the doors open
• Yesterday's logs backed up off the machine

After the show

Process the logs and the index cards within 48 hours, while you still remember the body language. Sort findings into three buckets: fix before the next event, real design problem, and one person's taste. The middle bucket is the valuable one, and it evaporates unless each item becomes a task on the board with the playtest note attached.

Then keep the six-minute build. It is now your festival build, your press build, your publisher-meeting build, and the thing you hand a stranger at a meetup. It takes two weeks to make and it does that job for years.