How TETERI is built

A browser game with no engine, no libraries and no asset files. How the rendering, the synthesised audio, the peer-to-peer netcode and the CPU opponent actually work.

12 articles

• Building a Game With No Dependencies At AllNo engine, no framework, no library, no build step for the game itself. What that costs and what it buys.
• Rendering: Sprite Caches and Layer BakingDrawing four hundred glowing blocks per frame is slow. Drawing four hundred cached bitmaps is not.
• Every Sound Is Generated, Not RecordedOscillators, filtered noise and a reverb impulse built from decaying random numbers. No audio files anywhere.
• The Soundtrack Is a Sequencer, Not a FileA four-bar progression with drums, bass, arpeggio and a lead, whose tempo and arrangement climb with your level.
• Online Play With No Server At AllWebRTC connects the two browsers directly; a public relay handles only the introduction.
• Seeded Randomness: Why Both Players Get the Same PiecesA small deterministic generator, one shared number, and two identical bags on different machines.
• How the CPU Opponent SearchesEnumerate every placement, score the resulting board on four weighted features, take the best.
• Testing a Game Without Opening a BrowserKeeping the rules engine free of DOM references means the whole ruleset is testable from a terminal.
• One Layout Engine, Four ShapesSolo widescreen, solo portrait, split screen and a focus view, all produced by the same function.
• Telling a Flick From a DragTwo gestures that differ only in speed, and why measuring velocity at release is the only reliable answer.
• Making It Work Offline ProperlyCache the shell, revalidate in the background, and never serve a mix of old and new modules.
• Keeping Inside a Sixteen-Millisecond BudgetSixty frames a second means 16.7ms for everything. Here is where it goes and how it was measured.