When the Game Reaches Into the Room
Our garage-lab platformer escaped its screens — onto an LED strip, a robot, a printer, and the lights. Here's the safety doctrine that came with it: thermal budgets, actuation consent, device-reported state, fail-safe postures — and rules that attach to devices, not to the software that uses them.
We built a video game that leaves its screens. The avatar walks off the last monitor onto a physical LED strip, gets waved through by a robot spider, traps itself in a laser printer, charges a laser that lights a real bulb, and wins by switching on a lamp that once belonged to a tortoise named Leo.
The fun writes itself. What doesn't write itself — and what this note is about — is that every physical device a game touches inherits real-world failure modes, and each one needs an explicit safety answer before it becomes a toy.
The doctrines that emerged
1. Thermal budgets, not timers. One of our game-controlled lights runs hot. The naive rule — "max 10 minutes on" — fails the moment play gets rapid: many short activations accumulate heat that no single-session timer sees. We model it as a thermal ledger: heat accrues second-for-second while the light is on and drains at half rate while it's off (one minute lit costs two minutes of cooling). The game may only switch the light on while the ledger is under budget, a hard cutoff fires mid-glow if the budget is reached, and — critically — the ledger survives game resets. A player mashing "restart" cannot launder heat.
2. Actuation consent is a hard gate. Nothing with a motor moves without a human explicitly approving that motion, in that conversation, with the exact movement described first. Our robot's wave was choreographed with a person spotting it, on wall power, after its own strain telemetry taught us that a dying battery makes servos brown out silently — a command that returns "ok" while nothing moves is the most dangerous kind of success.
3. Robots keep their own reflexes. The spider's firmware carries a strain watchdog that detects a blocked leg and eases off. When our choreography tripped it falsely, the temptation was to silence it. We didn't: performance moves got an exemption from the narration only, while real obstruction detection during locomotion stays armed. A safety system you disable to make the demo smooth is a safety system you no longer have.
4. Consumables get rate limits backed by durable logs. The printer prints at most once per cooldown window — and the limit is enforced from a persistent job log, not process memory, so a service restart can't double-fire it. The same log records how long each job actually took and whether the printer was cold, so timing estimates come from evidence rather than guesses.
5. Ask the device; don't assume. The printer reports its own state — a cold fuser announces itself before the game commits to timing. The spider reports rail voltage per move. The rule generalizes: when hardware can tell you its state, reading it beats modeling it.
6. Every physical surface has a fail-safe posture. The LED strip blacks out on game start, reset, and mode change (the controller latches its last frame otherwise — a crashed game must not leave a ghost on the wall). Screens that get taken over revert on their own via TTLs. Lights default to off at every reset so a victory lamp means something. The failure posture of every device is dark and quiet, reached automatically.
7. Nothing recovers silently. Every trigger, suppression, forced cutoff, and heal writes a log line with its reason. A cooldown that swallows a valid action says so. A forced thermal cutoff announces itself. The one bug that cost us the most this week was a command that failed while reporting success — the antidote is a system that narrates its own restraint.
8. Rules attach to devices, not to the software that uses them. (Added after the first playtests.) Our thermal ledger began life inside the game — and that was the flaw. Fire prevention associated with a game is fire prevention that vanishes when the game isn't running, when a phone app flips the same switch, when a service restarts and forgets its arithmetic. The rule moved to where it belongs: a standalone guardian bound to the socket itself, watching whoever switches it, persisting its ledger to disk on every tick, waking conservatively (an unknown gap with the light found on counts entirely as burn time), and — as a last line — programming the smart plug's own countdown timer with the remaining budget, so even the death of the machine running the guardian cannot leave the bulb cooking. The game became just another customer that asks and accepts the veto. Every future consumer — voice control, automations, guests — inherits the protection without knowing it exists. The rule expires only when the physics changes: the day that light moves off the wooden shelf.
None of this made the game less fun. Most of it made the game better — the thermal budget became a visible charge indicator, the printer's cooldown became a "trap" mechanic, the robot's consent choreography produced a more expressive wave than the vendor's preset. Safety engineering and game design turned out to be the same discipline wearing different hats: both are about knowing every state a system can be in, and deciding on purpose what happens in each one.
— TLC AI Lab · Digital Brains. Real Execution.