The engine
MicroGames Engine
Godot runs the games. MicroGames Engine is everything around it: it takes an idea all the way to a build for the browser, Windows, macOS, Linux and Android, and checks at every step that the game actually holds.
A game engine answers a precise question: how what happens on screen gets drawn, moved and heard. For that we use Godot 4, and we have no intention of rewriting it: rendering, physics, input and audio are its job.
MicroGames Engine answers a different question: how a game gets made — and kept alive after release — without every step depending on someone remembering it. It is the layer that writes and fixes the code, prepares the exports, tests the builds, saves the versions and ships.
What it adds to Godot
A document that becomes work
The design document does not stay a file to look things up in: it is broken into tasks, which the builder works through in batches. A task counts as done only when a verifier that can only read finds it in the code. “It compiles” is not enough.
Whoever writes is not whoever fixes
The builder writes scenes and GDScript. When the export or the startup test fails, the error goes to a separate fixer that makes the smallest possible change: up to five attempts, then the problem stops and stays on record.
Five checks before release
It compiles, it starts, it is coherent — main scene and win condition — it loads, it shows. The last one is not decided by the code: the game is opened in a real browser and we look at whether it draws anything.
Actually played, every night
An automated player opens every game, plays it for about twenty seconds and takes from it the poster and the clip you see on the site. Frozen screens — menus, pause, “you died” — get thrown away: a poster that lies is worse than no poster.
Every version stays
Every release saves the game's sources. Any version can be restored and exported again: a game here is not abandoned after release, it keeps changing.
Real material, missing sprites
Images, sounds and videos uploaded for a game enter the project already in the format Godot reads. If a game is missing a sprite, it gets generated and cut out, a few at a time.
One export, five destinations
The same pipeline produces the browser build and the packages for Windows, macOS, Linux and Android, with the version written in every file name. The browser build can also go to itch.io.
A studio, not a prompt
Research, design, build and release are split across 12 roles with one job each. Whoever wrote the code is not whoever judges it.
Who does what
Godot stays the engine. What changes is how much work reaches it already done, and already checked.
| Godot 4 | MicroGames Engine | |
|---|---|---|
| Drawing, physics, input, audio | Runs them | Leaves them alone |
| Game code | Executes the GDScript | Writes it, fixes it, verifies it |
| Export | Provides the templates | Prepares the presets, packages, puts the version in the name |
| Testing | Headless startup | Five checks and a real session in a browser |
| Versions | — | Saves the sources at every release and restores them |
| Release | — | Site, game page, poster, clip, itch.io |
Counted right now
Read from the database at every visit, like the ones on the home page.
Other engines
Today MicroGames Engine only talks to Godot: project scaffolding, agent instructions, export and tests are written for it. Adding a second engine means writing an adapter for each of those parts — it is not a switch.
We judge them by one criterion: an engine gets in if it can be built, tested and shipped with no hands on it. Command-line builds, text sources an agent can read and edit, and a browser export, because that is where every game gets tested before release.
| Engine | What it would bring | What holds it back | Where it stands |
|---|---|---|---|
| Godot 3D | Same pipeline, same checks, no adapter | It needs 3D art, which we do not produce today | The shortest road to 3D |
| Phaser, three.js, Babylon.js | Born for the browser: tests and captures already work | The desktop needs a wrapper such as Electron or Tauri | The most natural candidate for a second engine |
| Defold | Command-line builds, text Lua sources, web export | A second language and a second editor to teach the agents | Under evaluation |
| Unity | A huge ecosystem | A licence to activate, a heavy install, scenes an agent reads poorly | Not now |
| Unreal Engine | High-end 3D, where the studio wants to get to | No official browser export: “Play”, tests and automated captures would all go; tooling in the tens of gigabytes | On a dedicated machine, outside the automated pipeline |
When a second engine ships a game, you will read it in the devlog like everything else: with the numbers, and with what broke along the way.
