TECH Signal 394
Making a game on a custom bytecode VM in 7 days and 3kB
↗
A developer created a shoot-em-up game in a week by building a tiny custom bytecode VM, a compiler, and a GLSL shader, ending up with a 3 kB Windows executable.
The project shows that a purpose-built VM can dramatically shrink the binary size of a game, which is useful for size-constrained platforms or demo scenes. It also demonstrates a live-reload workflow that lets developers tweak game logic and graphics instantly, cutting iteration time. However, the approach requires upfront work to create the language tooling and is limited to simple float-array based computation.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
A minimalist bytecode format using only float32 arrays and two statement types keeps the interpreter and compiled code extremely small.
Live reloading of compiled bytecode and GLSL shader enables rapid development without rebuilding the native C++ host.
The technique trades flexibility for size, omitting features like music, 3D rendering, and complex data structures.
THE READ
What the cluster adds up to.
The author tackled a seven-day game jam by first defining a tiny language, then compiling it to a bespoke bytecode that runs inside a C++ interpreter. The interpreter and the shader are packaged together, and the whole bundle is compressed to produce a sub-4 kB executable. This contrasts with typical game development pipelines that rely on larger runtimes and asset pipelines.
The bytecode design is deliberately sparse: every value lives in a float array, and the only operations are cell updates or jumps, optionally conditioned on a float threshold. By avoiding stacks, registers, and type tags, both the interpreter and the generated bytecode stay compact. The compiler maps each source variable to a slot in the shared array, and special slots are reserved for communication with the shader.
To keep iteration fast, the developer set up a live-coding loop where editing the source triggers the compiler to emit new bytecode, which the running interpreter loads each frame. The GLSL shader is also watched for changes and reloaded on the fly. This eliminates the need to recompile the native host binary for every tweak, dramatically speeding up creative experimentation.
Adopting this approach requires building a custom language front-end, a bytecode emitter, a C++ interpreter, and a minified shader, plus integrating a compressor. The resulting system is optimized for tiny binaries, so it omits features such as audio, complex geometry, or extensive libraries, which limits its applicability to larger or more feature-rich games. Maintenance overhead can be high because any new language feature must be reflected in the interpreter and the shader contract.
For engineers working on embedded devices, demoscene productions, or size-critical applications, the project provides a concrete example of how a focused VM can replace bulkier runtimes. The live-reload pattern also offers a template for rapid prototyping when the target platform permits dynamic asset loading. Scaling the technique would demand additional infrastructure to handle richer data types and larger asset sets.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER