Two games in one day
Sonar and Tether went from nothing to playable on the same day. That isn't a boast about speed — it's what happens when a game is allowed to be exactly one idea.
On 14 July we shipped two games. Sonar, where the cavern is pitch black and you ping to see it, and Tether, where you swing on a grapple and the only control is when to let go.
They have nothing in common mechanically. What they share is that each one is a single sentence, and everything in the game exists to serve that sentence.
One idea, ruthlessly
Tether's sentence is: hold to grapple, release to fly, and the rope pumps itself. Sonar's is: you can't see, and the thing that lets you see also wakes what's hunting you.
Once you have a sentence like that, most design questions answer themselves. Should Tether have a boost button? No — that's a second way to gain speed, and the whole game is about getting speed from the swing. Should Sonar have a torch upgrade? No, obviously not; that deletes the game.
The speed comes from that. We weren't making a hundred small decisions and evaluating each on its merits — we were checking each one against the sentence and discarding most of them in a second. Nearly everything you could add to a game is a distraction from whatever made it interesting, and having the sentence written down makes that easy to see.
The shared skeleton
The other reason two games in a day is possible is that by this point we'd built the same scaffolding often enough that it wasn't a decision any more.
Every game on this site has: a canvas that scales to its container, a fixed-timestep update loop, a state machine with menu, play and game-over, a score submission that goes to a signed session, a leaderboard panel, a mute toggle, and generated audio rather than sound files. None of that is interesting, and none of it needs designing again.
So a new game is genuinely just the middle bit: what's on the screen, what the input does, and what kills you. That's a day of work if you know the answer to all three before you start, and weeks if you don't.
What one day doesn't buy you
Both games were playable that day. Neither was finished, and it's worth being honest about the gap.
Sonar shipped with an ambient glow that let you dimly see the cavern walls without pinging. It seemed kind. It was actually fatal to the design — with permanent faint visibility, the ping stopped being how you navigate and became a way to spot pearls. Removing it, later, is what made the game work. We'd built the right game and then softened it on the same day.
Tether had the opposite problem: nothing in it explained that the rope pumps itself. Players felt themselves speeding up and assumed the game was ramping difficulty. The single best mechanic in the game was invisible, and it took writing the game's page — months later — for us to notice.
Both fixes are small. Neither could have happened on day one, because both required playing the finished thing enough to notice something was off. Building fast is a good way to get to the point where you can find out what's wrong; it is not the same as being done.
Scope as a feature
The temptation with a mechanic that works is to build it out — more levels, more enemy types, an upgrade tree, a story. Sometimes that's right; Strata is a deliberately large game and needed to be.
But most one-idea games are best left as one idea. A three-minute game you replay eleven times is a better experience than a twenty-minute game you finish once, and it is enormously cheaper to make well. The failure mode we watch for is a game that grows features because we enjoyed building it, rather than because playing it demanded them.
Sonar and Tether are still roughly the size they were on day one. They're both better than they were, and neither is bigger.
→ Play Sonar · → Play Tether · → Designing a game you can't see