How TETERI is built

Building a Game With No Dependencies At All

No engine, no framework, no library, no build step for the game itself. What that costs and what it buys.

TETERI has zero runtime dependencies. Not "a few small ones" — none. The browser loads a handful of JavaScript modules directly, and that is the entire delivery mechanism.

What that rules out

No game engine. No rendering library. No state management. No audio library. No networking library. No UI framework. No bundler, minifier or transpiler for the game code.

What it costs

Everything has to be written. Rotation tables, collision, the audio synth, the netcode, the layout system, the particle system. None of it was free.

No community solutions. When something is subtly wrong, there is no library issue tracker with someone else's answer in it.

Browser compatibility is yours. Modern browsers only, and the burden of knowing which features are safe.

What it buys

Size. The whole game is a few hundred kilobytes including icons. A comparable build on an engine is typically megabytes before any content.

Load time. Nothing to parse before the game can start. First paint is essentially immediate.

No supply chain. Nothing to audit, nothing to update for security, no transitive dependency that turns out to be unmaintained.

Comprehensibility. The entire codebase is readable in an afternoon. Every behaviour has one place it comes from.

Longevity. Nothing to break. A dependency-free static site written against stable web APIs will still run in ten years, which is emphatically not true of anything with a build pipeline.

When this is the wrong choice

For a large game with complex 3D, physics, animation blending and a content pipeline, writing everything yourself is a bad use of a life. Engines exist because those problems are genuinely hard and genuinely solved.

For a game whose entire state is a ten by twenty grid, the engine is mostly overhead. The interesting decision is recognising which situation you are in.

PLAY TETERI ALL ARTICLES