GANDER: our own game engine, and no human will write a line of code for it

We built our own game engine. It's called GANDER, it runs in the browser and on desktops, and no human will ever write a line of game code in it. That isn't a slogan. Nobody on our side writes GANDER games. The studio's agent writes all of them, and the engine, its language and its tools were designed around that one reader.

GANDER sits beside Godot and Unreal in the studio as a third engine. Your Godot games don't change. This post covers why we made it, how it works, what six games built in it look like, and how one of our own Godot games did when we ported it across and measured both.

What is GANDER?

GANDER is vbgnt's own game engine, made for an AI agent to write games in rather than for a person to click around in. A game is plain source code in Goose, a brand-new compiled language from Wouter van Oortmerssen, the author of FlatBuffers and Lobster. GANDER turns that into C, then into WebAssembly for the browser and into native builds for desktops. There's no editor, no scene files and no project settings to keep in sync. The game is its code and its assets folder, and that's all.

Underneath is a compact C engine: a 2D renderer, a 3D renderer with shadows, fog, sky and terrain, glTF models with skeletons and blendshapes, talking faces with lip sync, first-person arms, 3D physics with a full vehicle model, 2D physics, audio, UI, touch controls, online play and capture. In the browser it draws with WebGPU and falls back to WebGL2. On desktops it uses Metal on Mac, Direct3D 11 on Windows, and Vulkan on Linux and Steam Deck, with an OpenGL fallback.

Why would a game studio build its own engine?

Because the engines we use were built for people, and the person using ours isn't one.

Godot is excellent, and it's still the engine behind most vbgnt games. But a lot of Godot is an editor: scenes, inspectors, node trees, import settings. An agent has to drive all of that through text files that were meant to be saved by the editor, not written by hand. Most of the time it works. When it doesn't, the failure is often a node that exists in a scene file but not in the code, or a setting buried three menus deep that the agent never knew to check.

We kept a list of what actually slowed the agent down, turn after turn, and designed GANDER against it:

• One reference to read. The whole engine API is one document the agent reads in full at the start of a turn. If it isn't in there, it doesn't exist.
• No hidden state. The game draws what it wants every frame. There's no scene tree to keep in step with the code, so a whole class of "it's in the scene but not in the script" bugs can't happen.
• Errors in a second. gander check type-checks a game in about a second and reports problems as file, line and fix. A build takes seconds, not minutes.
• The agent can play its own game. gander test runs the real web build headless with scripted input (hold W for two seconds, tap here, press Enter), takes screenshots at the frames it asks for, and reports values the game exposes, like the car's speed or the number of enemies left. The agent looks at the shots before it tells you anything works.
• Small downloads. A GANDER game ships only the engine it uses and its own assets, compressed for the web.

How does a GANDER game get built?

The same way any vbgnt game does. You describe it, in the studio or through the MCP from your own assistant, and pick GANDER as the engine. The agent writes the game in Goose, generates or reuses art, music and sound, checks and builds it, plays it with gander test, fixes what it sees, and publishes it to your arcade. Art reviews, saved build versions and the Files pane all work the same as for Godot games.

Under the hood a turn goes like this:

1. The agent reads the engine reference and your brief, and writes Goose source files.
2. gander check catches mistakes before anything compiles.
3. gander build compiles the game to C, then to WebAssembly, links the prebuilt engine and packs the assets. Textures too big for the web are shrunk on the way out; your originals stay as they are.
4. gander test plays it in a headless browser, on a cloud GPU when the game is 3D, and hands back screenshots, logs and probe values.
5. The studio publishes the build to the same address a Godot web build would have.

Why Goose, and what happens when it changes?

Goose is small, fast and compiles ahead of time to plain C, so the same game code runs in the browser and natively with nothing interpreted. It's also brand new, and that turns out to suit an agent better than it would suit a person. A human team would wait for a new language to settle. The agent doesn't need a decade of tutorials; it needs one accurate reference, and we write that reference.

A new language moves fast. Goose had 17 commits the day after we first pinned it. So GANDER keeps up with it the same way it improves everything else, without a person in the loop:

1. A tracker lists every Goose commit since the version GANDER is pinned to, sorted by what it touches: the runtime, the code generator, the command line, the language itself.
2. An agent builds the new compiler beside the pinned one and runs both over every starter and regression game, in the browser and natively. Any build or test that fails, or any value that comes out differently between the two compilers, stops the upgrade.
3. When everything matches, GANDER moves to the new version and the reference the game agents read is updated with whatever the language added, so the next game can use it.

That has already happened once. On 26 October GANDER moved to a Goose release with 17 new commits, among them a new fused multiply-add in the maths library and a change to how method calls resolve, after every starter and regression game passed on web and native. Your game picks up the new compiler on its next build.

What can you make with it?

To find out, we gave the agent six briefs on a test account and built each game through the MCP, one turn at a time, reading every turn's log as it went. We asked for games that would push different parts of the engine.

None of these was a one-shot. Most took two or three turns, the three-game port took five, and every turn's log told us something about the engine. More on that below.

How does it compare to Godot?

We measured it two ways, in Chrome on an Apple M2 MacBook with a cold cache, each run twice, at normal speed and with the processor slowed four times as a stand-in for a phone.

The same game in both engines. The agent ported one of our own Godot games, a first-person mech idle game, to GANDER: every formula, number, sprite and sound carried over. This is the closest thing to a fair fight on download size and load time, because the game is the same.

Two similar 3D games. For frame rate a 2D idle game proves nothing, so we put the rally game against a Godot 3D game with a lot in common: a third-person trail run up switchback mountains, with terrain, pines and a chase camera. They're different games, so read this as a comparison of two real 3D games of the same kind, not a lab test. We measured each while driving or running, in a laptop window, a high-density window and a phone-shaped one.

What that says, and what it doesn't:

• Downloads are the clearest win. A GANDER game carries only the engine it uses. The idle game shrank by four fifths and the 3D game by half.
• Both hit the frame-rate ceiling. On this laptop both 3D games ran at the screen's 120 frames a second with steady frame times. Neither engine was the bottleneck, so this test can't tell you which renders faster.
• GANDER leaves the browser more room. It does about half the main-thread work per second at full speed. That's the headroom a slower phone will need.
• The 3D load time evens out on a slow processor. The rally game builds its 2 km terrain when it starts, and with the processor slowed four times that takes as long as Godot's whole start-up. That's on our list.

What did the first week teach us?

That an engine built for agents gets better fastest when you read the agents' logs. Every turn records each command the agent ran, every failure and every workaround it announced. We read all of them. In the first week that turned up:

• Missed key taps. A tap that went down and up between two frames, which happens on a slow phone, never registered. Now every press counts, and a click or tap shorter than a frame shows up as one too.
• Keys going to the wrong page. In the studio preview, clicking into a game didn't give it the keyboard, so your keys went to the page around it. Fixed in the engine for every game.
• Faces that never moved. A talking captain's model stored her expressions in a compact format the engine read as blank. The agent spotted it and rebuilt the model; we fixed the loader so it can't happen again.
• Inside-out walls. Walls an agent built by hand were facing the wrong way and vanished. The engine now turns triangles to face the way their normals say.
• Pixel art in a postage stamp. Pixel games only scaled by whole numbers, so a game made for 640 by 360 sat small in the middle of most browser windows. Now it fills the window and stays crisp.
• Phones running hot. A 3D rally game was fine on a laptop and slow on a folding phone. Phones now render a sensible number of pixels with smaller shadow maps, and the car's motion is smoothed between physics steps.

Each fix went into the engine, not into one game, so every GANDER game picked it up on its next build. That's the other half of the design: when the agent hits an edge, we move the edge.

What doesn't it do yet?

Plenty. GANDER is at version 0.1. There's no visual editor and there won't be one. It doesn't have Godot's years of add-ons, its shader graph or its huge community, and an agent that knows Godot well still has more to draw on there. Big open-world 3D games with heavy streaming are a better fit for Godot or Unreal today. Console builds are a hand-off of C sources and a porting guide, not a button.

If your game is already a Godot game, keep it there. GANDER is for new games where a fast, small build that loads in seconds matters more than an ecosystem.

How do I try it?

Pick GANDER as the engine when you start a new game in the studio, or pass engine: "gander" to create_game through the MCP. Describe the game as you would for any other. The agent will tell you what it built, show you what it tested, and publish it to your arcade.