Demoscene Browser Games: The Art of Tiny Code

The demoscene is one of the oldest computer subcultures still active. It started on home computers in the 1980s, moved to the PC in the 1990s, and arrived in the browser in the 2010s. Demoscene browser games occupy a specific corner of the wider demoscene: productions that fit within strict size limits, render everything from math, and frequently include enough interaction to qualify as games rather than passive demos. The work is small in bytes and unusually large in ideas.

A short history of the demoscene

The demoscene started in the early 1980s on home computers like the Commodore 64 and Amiga. The earliest demos were “cracktros” — title screens added to pirated software by crackers boasting about their releases. Over time, the boasts became their own art form. Coders competed to produce graphics and sound that the host hardware shouldn’t have been capable of.

The scene matured into a structured community: parties (Assembly in Helsinki, Revision in Saarbrucken, Demosplash in Pittsburgh), competitions with formal categories (4K, 64K, intro, demo), and a recognized canon of seminal productions. The “Second Reality” demo by Future Crew in 1993 is one of the most cited examples — a PC demo that pushed the era’s hardware in ways nobody had thought possible.

By the 2000s, the scene was producing the famous .kkrieger demo by .theprodukkt — a complete 3D first-person shooter that fits in 96 kilobytes. .kkrieger procedurally generates every texture, every sound, and every level from a tiny seed of math. It set a benchmark that nobody has cleanly matched.

The browser demoscene

JavaScript and the Canvas API opened the browser to the same kind of size-constrained creativity. The watershed contests were JS1k (founded in 2010 by Peter van der Zee, 1024-byte JavaScript limit) and Js13kGames (founded in 2012 by Andrzej Mazur, 13-kilobyte HTML5 limit). Both attracted demoscene veterans who applied decades of size-coding tradition to a new platform.

The browser scene developed its own house style. WebGL shaders rendering procedural geometry. WebAudio generating synthesized music from code. Compact entries that look impossible until you see them work. The genre is small but devoted, with a steady stream of new productions every year.

Js13kGames and the playable demoscene

Js13kGames is the most active browser-demoscene contest with a game focus. The 13-kilobyte limit (measured as a zipped bundle) is generous enough to allow complete games while still requiring procedural techniques to fit everything in. Entries from the contest have included:

• Platformers with hand-tuned levels and procedural music.
• Roguelikes with multiple character classes and unlockable items.
• Twin-stick shooters with bullet-pattern bosses.
• Puzzle games with hundreds of levels packed into compact level descriptions.
• 3D demos that render entire scenes via raymarching shaders.

The contest’s annual themes (“offline,” “lost,” “death,” “404”) push entrants toward inventive interpretations. The winners are archived on js13kgames.com and remain playable years after submission.

The .kkrieger legacy in browsers

.kkrieger’s success on PC raised an obvious question: could the equivalent work be done in a browser? The answer is yes, with caveats. Modern WebGL shaders can produce 3D scenes comparable to mid-2000s desktop games, and browser WebAudio can synthesize music procedurally. Several Js13kGames entries have demonstrated this — small 3D first-person experiences with procedural everything that run smoothly in any browser.

The “spirit of .kkrieger in the browser” remains a recurring goal in the scene. Each year produces new entries that push closer to the original’s audacity. The constraints differ — JavaScript and WebGL impose different cost structures than C++ and DirectX — but the philosophy is shared.

Common techniques

Demoscene browser games share a recognizable set of techniques:

Procedural graphics

Instead of loading textures, demos generate them at startup from math. Perlin noise produces clouds, terrain, and cave walls. Voronoi diagrams create cell patterns. Layered sine waves drive shader-based effects. Once you have a small set of procedural primitives, you can paint any scene.

Procedural audio

WebAudio’s oscillators and filters let demos generate music and sound effects from code. A handful of oscillators, a noise generator, and an envelope shape are enough to produce drum sounds, leads, basses, and pads. Trackers like soundbox and tools like Bytebeat have made compact audio synthesis approachable.

Bitwise level encoding

Level data eats bytes. Demoscene entries encode levels as strings, bitmaps, or even into the source code of the game itself. A 32-character string can describe an entire 5×5 level grid; a single integer can describe a complete platformer level layout. Combined with procedural variation, a tiny seed can produce a large game world.

Compressor-aware coding

Js13kGames entries are measured after compression. That changes how coders write — repeated structures compress better than novel ones. Demoscene programmers structure their code to feed compressors well, sometimes using template metaprogramming-style tricks to maximize repetition that the compressor then collapses.

Notable browser demoscene productions

Specific landmark entries are best discovered by browsing the archives, but the categories are well-defined. The JS1k archive at js1k.com hosts the kilobyte category’s history. The Js13kGames archive at js13kgames.com hosts the larger contest. Each contest year has a top-ten roundup worth browsing.

Outside the contests, the demoscene proper has produced standalone web productions hosted on community sites like Pouet (pouet.net), which is the canonical demoscene archive. Many of the most acclaimed productions are also reposted to YouTube as captures, with notes pointing to source for those who want to run the original.

How demoscene games differ from regular games

A regular browser game prioritizes player experience. A demoscene browser game prioritizes technical achievement, often with player experience as a secondary consideration. The audience for a demoscene production includes a substantial fraction of fellow coders who appreciate the technique as much as the play.

This isn’t a knock — the work is genuinely beautiful, and many demoscene productions are also enjoyable to play — but the priorities are different. A demoscene game might have unforgiving difficulty because nobody wanted to spend bytes on a difficulty selector. It might lack tutorials because the introduction is the show, not the explanation.

Why the demoscene matters

The demoscene is a living archive of computing creativity. Productions from forty years ago are still played, studied, and preserved. The skills developed in size-coding propagate into mainstream practice — many techniques pioneered by demoscene programmers eventually became standard in graphics programming, audio synthesis, and procedural generation.

UNESCO has recognized the demoscene as an intangible cultural heritage in Germany, the Netherlands, and Finland. The recognition reflects something true: the demoscene is one of the few computing subcultures with a defined aesthetic, a continuous community, and a multigenerational tradition.

How to get started

If you want to play demoscene browser games: browse the Js13kGames winners gallery and the JS1k archive. Several entries take fewer than fifteen minutes to enjoy, and many will surprise you with what they pack into kilobytes.

If you want to write demoscene browser games: read source from past contest entries. Js13kGames source is publicly browsable. Pick a small idea (Pong, Snake, a one-screen platformer), implement it normally, then optimize for size — first easy wins like minification, then harder ones like procedural assets.

For a simple browser game with more conventional code that you can use as a baseline for “normal” sizing, the Chrome Dino game embedded here uses Canvas in a straightforward way. The Wikipedia demoscene article covers the broader culture. For more games with extreme constraint, see our no-graphics games roundup.

Frequently asked questions

What is the demoscene?

The demoscene is a computing subculture, dating from the early 1980s, focused on producing audiovisual programs that demonstrate technical and artistic achievement under tight size or hardware constraints. It originated on home computers and now spans every major platform, including the browser.

Are demoscene productions games?

Not always. Many are passive audiovisual demos with no interaction. Demoscene “games” are productions that include playable mechanics — input, state, win or lose conditions — in addition to the technical demonstration.

How can demoscene games run in a browser?

WebGL allows full GPU programming including shaders, and WebAudio allows synthesized sound at sample-level precision. Combined with Canvas for 2D and clever JavaScript code, the browser is now a capable demoscene platform.

What’s the size limit for browser demoscene work?

It varies by contest. JS1k capped entries at 1024 bytes of JavaScript. Js13kGames allows 13,312 bytes for the full zipped bundle. Smaller “tweet-cart” works fit in under 280 characters. The demoscene tradition treats each new limit as a new creative space.

Where can I see demoscene browser games?

The Js13kGames archive at js13kgames.com hosts thousands of entries. The JS1k archive at js1k.com hosts the kilobyte category’s complete history. The general demoscene archive at pouet.net catalogues productions across all platforms including web.

The takeaway

Demoscene browser games are tiny, dense, and consistently inventive. They represent a forty-year tradition adapted to a new platform and continued by a community that still cares about what code can do when it’s stripped to essentials. The work is short to play and long to think about — exactly the trade most demos aim for.