Keyboard Defense is live. After eight development blocks, a wave system that got rewritten twice, and more time debugging Godot's JavaScriptBridge than I expected, the game is now available at blockzerointeractive.com/games/keyboard-defense and on Itch.io.
This is the first public release from Block Zero Interactive. I want to use this post to document what the actual build looked like — not the polished version, but the real sequence of decisions, dead ends, and things that worked better than expected. These posts are as much for me as they are for anyone reading.
8
Development blocks
4
Game modes
7
SFX built from scratch
What Keyboard Defense actually is
The concept came from a simple intersection: Missile Command's tension mechanics combined with typing practice. Letters, words, and sentences fall from the sky as missiles — you type them to destroy them before they hit your three bases.
What started as a "typing game with arcade feel" ended up being two things in one product: a genuine arcade experience and a functional typing trainer. The Typing Trainer mode — with Practice, Run, and Test submodes, an on-screen keyboard, and a printable result certificate — wasn't in the original plan. It grew out of a late-stage decision to make the game usable in classroom settings. That turned out to be the right call.
"The game mechanics are the lesson. Students don't read about typing — they practice it under pressure, with real feedback."
What the build actually looked like
The architecture decision that saved the project
The single best technical decision was defining all Autoloads — GameManager, WaveManager, InputManager, AudioManager, and ContentLibrary — before writing a single line of gameplay code. In Godot 4, these are global singletons. Having them in place from day one meant every system could operate independently, and when something broke (and things broke), the failure was always isolated.
ContentLibrary as the single source of truth for all game content — letters, word lists, sentences — was particularly important. The typing trainer, the arcade modes, and the difficulty progression all draw from the same library. Changing a word list updates everything at once.
The visual approach: no sprites
Every visual in Keyboard Defense is drawn procedurally with Godot's _draw() method. The CRT monitor bases, the missiles, the particle explosions on impact, the scanline overlay — none of it uses external image assets. This was partly a practical decision (no art team, faster iteration) and partly intentional: the retro 1980s aesthetic called for something that felt constructed, not illustrated.
The tradeoff is that _draw() requires you to think in immediate-mode graphics. Every visual state has to be derived from the current game state on each frame. It slows down prototyping but produces results that are trivially scalable and easy to theme.
What broke
The wave system got rewritten twice. The first version used a flat difficulty curve — it just increased speed linearly. It wasn't interesting to play. The second version introduced content type mixing (letters → words → sentences) as the primary difficulty axis, with speed as a secondary variable. That's the version that shipped.
The JavaScriptBridge integration for web persistence took longer than expected. Godot's HTML5 export handles localStorage through a bridge that behaves differently from both native Godot file access and standard JavaScript. The dual persistence system — using localStorage on web and FileAccess on desktop — required careful conditional logic to avoid breaking either platform.
What comes next for Keyboard Defense
The immediate priority is listening. The game is live, which means real people are playing it, and the first two weeks of feedback will shape what gets fixed and what gets built next. A few things are already on the list:
- Mobile layout improvements — the current build is optimized for keyboard input, which means touch-only devices have a degraded experience
- Additional word sets and sentence banks for the Typing Trainer
- Teacher dashboard integration — syncing Test results to the BZI platform for classroom use
- A Spanish language variant, consistent with the bilingual approach across BZI products
The teacher dashboard integration is the highest-value item from an educational standpoint. Right now the Test mode produces a printable certificate, which works for informal use. Connecting it to the platform would let instructors track student progress without requiring students to self-report.
What I'd do differently
I'd plan the Typing Trainer from day one. It emerged organically, which meant it was built in the margins of the arcade development. It works, but a more intentional architecture from the start would have made the two modes feel more integrated and would have reduced duplication in the input handling code.
I'd also set up a formal playtesting session earlier. I have good intuition for difficulty curves, but the first people to play the game — who don't have two months of muscle memory from building it — were slower in Levels mode and faster in Survival than I expected. The calibration is close, but not perfect.
Free to play in the browser. No account required for the arcade modes.
If you play it and have feedback — about difficulty, the trainer, anything — the best place to reach me is studio@blockzerointeractive.com. I read everything.
Next post will be a deeper look at the procedural art system — specifically why drawing in code was the right call for this project and what the tradeoffs actually looked like in practice.