Writing a 3D game with AI assistance is not as easy as it is made out to be
We have been building a co-operative 3D game that runs in a browser, written with heavy AI assistance. It works, and it is nothing like the demonstrations. The machine is a superb pair of hands and a poor imagination, and knowing which is which is most of the skill.
What it is built from
- Three.js for rendering, driving WebGL directly in the browser.
- Native ES modules with no bundler and no build step — the files that are written are the files that run, which turns out to matter enormously when a machine is writing a lot of them.
- A small Node.js room server for co-operative play, holding session state and relaying between players.
- Electron for the eventual desktop package, wrapping the same code that runs on the web.
- Plain JavaScript throughout. No engine editor, no scene format, no asset pipeline: every object in the world is constructed in code.
The no-build decision is the one worth stealing. When generated code goes wrong it usually goes wrong subtly, and a stack trace that points at a line you can open and read — rather than at a transpiled bundle — is the difference between a ten-minute fix and an afternoon.
What the machine was genuinely good at
Volume, consistency and the tenth version of something. Geometry maths, collision edge cases, the fiddly work of making a camera behave when a player backs into a wall — all of it is the kind of exacting, repetitive engineering where a machine does not get bored on the fourth attempt and a person does.
It is also very good at holding a convention. Given a rule that one particular file must never be edited and that new behaviour arrives through optional hooks instead, it will keep to that rule across months of work far more reliably than a human team will.
What it could not supply
The idea. Every time the design direction was left open, what came back was competent and completely forgettable — the average of everything that has been built before, which is exactly what you would expect and exactly what nobody wants to play. The imagination has to come from the designer, stated specifically, and then the machine will build it beautifully.
It cannot feel a thing either. Whether a jump is satisfying, whether a space feels large, whether a section is ten minutes of interest or four minutes of interest stretched thin — none of that survives being described in text. It has to be played, by a person, on the hardware the audience actually owns. We hold to a deliberately modest laptop as the floor, and roughly a third of the work is making things fit inside it.
The honest summary: AI did not remove the hard part of making a game. It removed the slow part, which is not the same thing, and then made the hard part more obvious.
Why this matters beyond games
A 3D engine written this way is a fair preview of where tooling is going. The traditional argument for a heavyweight engine is that nobody can afford to write the plumbing themselves. If the plumbing is cheap, the argument weakens, and what is left is a much smaller, much stranger set of engines built exactly around one game's idea rather than around everybody's.
The same reasoning is why this company exists. The analysis behind a website's growth was always worth doing and almost never worth paying a person to do continuously. Once the doing becomes cheap, the question stops being whether to do it and becomes which of it is worth money — which is a judgement call, and judgement is the part that still belongs to a person.
What to do about it
- Choose a stack where the code that runs is the code that was written. Debugging generated work is where the time goes.
- Write your conventions down as rules a machine can follow. It will keep them better than a team will.
- Never leave the creative direction open. Vague briefs produce the average of everything.
- Test on the weakest hardware you intend to support, early and constantly. No description of performance is a substitute.