Context
Every typing app looks the same: grey text, a WPM counter, a results screen. They measure you — they don't give you a reason to come back.
KEYKEEP swaps the genre. Instead of transcribing a paragraph, you defend a fortress: enemies march down lanes carrying words, and typing a word is what kills it.
The problem
A typing test wants calm — nothing moving near the text. A tower-defense wants legible chaos — dozens of things moving at once. Here both are true, because the words are the enemies.
Design decisions
Two colours, no exceptions
Ink on paper, plus one orange. Orange means exactly one thing — this matters now — so there's no colour vocabulary to learn mid-run.
No menu
The game cold-opens into wave one. Instructions are handwritten margin notes that dismiss themselves once read. The first enemy is the tutorial.
DOM + SVG, not canvas
The words are real text nodes — selectable, accessible, properly kerned. DOM holds sixty entities at 60fps; canvas would have meant re-implementing text.
Juice is spec, not polish
Fourteen feedback details, each with a written timing. Letters arc to their target; kills scatter ink dots. This is the gap between a game and a typing test.
Words adapt to you
The picker quietly weights toward letters you've recently mistyped — drilling your weak keys without ever announcing it.
One seed a day
Everyone gets the same run each day; results share as a Wordle-style grid. The cheapest retention in games — it costs a hash function.
The whole visual system is three values:
Outcome
Live and playable. The two-colour rule was the highest-leverage decision — it made every later visual question have exactly one answer available.
The DOM-over-canvas call is the one I'd revisit at scale: correct at sixty entities, but a three-hundred-entity mode would need a hybrid.