Here's the unpopular part: banning the cheap trick cost us real time and money, and we'd do it again without hesitation. Most AI game builders fake 3D — a tilted canvas, some perspective math, done in an afternoon. We tried it too, and it worked exactly as well as it sounds like it would.
The tell came the day we put a canvas fake next to a build rendered by an actual engine. It wasn't a matter of taste or polish. One looked like a game. The other looked like a spreadsheet that had gotten ambitious. So we wrote a hard rule into the builder guidance: real-engine rendering or nothing. Web games run a bundled three.js and physics stack. Anything claiming native quality goes through the Unity Lab, where agents write actual C# against Unity 6 and compile WebGL builds you can play in a browser tab.
The part nobody warns you about: assets
Banning the fake renderer was the easy half. The hard part is that a real engine only renders what you feed it, and code-only agents left to their own devices produce programmer art — lumpy spheres with good intentions, nothing you'd want a player to look at. The fix wasn't a better renderer. It was reordering the pipeline: concept first, geometry second. An agent paints concept art before it touches a mesh. Then a modelling agent writes a Blender script aimed at that concept, renders it headlessly, and a visual-audit loop compares the render against the concept and kicks the script back for revision until the two actually match.
That loop is slow and it burns compute arguing with itself. It's also the only thing that got us past programmer art. Every piece page in the lab publishes its audit rounds, so you can watch it converge rather than take our word for it. Here's the newest piece, an organ loft, at round one and round four:
And once it's sitting inside the engine with lighting and materials actually doing work:
Sound was the same argument in a different key
The audio equivalent of a canvas fake is a bare oscillator beep, and for a stretch our games were full of them — cheap to generate, instantly recognizable as cheap. Same diagnosis, same cure: a hard rule plus real tooling. Everything now comes from sampled instruments, 84 of them in an in-house library, plus recorded ambience. A harbor level gets water and gulls that sound like water and gulls. A puzzle game's success chime is played by something, not computed by something.
Why put the whole mess online
A demo reel shows your five best minutes. A lab shows everything, including the rounds where the model looked wrong.
The lab holds 83 published build pages now, and the Blender Studio shows the asset side on its own terms — scripts, turntable renders, the full audit history warts and all. We publish the failed rounds on purpose. Anyone can cherry-pick one good screenshot; that proves nothing. Showing every iteration, including the ugly round-one geometry, is much harder to fake, and that's the entire point of doing it this way.
Now the concession, because the critics of this approach aren't wrong about the cost. A canvas fake ships in an afternoon; our pipeline takes an audit loop, a modelling agent, and real engine compile time before anything is playable. For a quick prototype or a throwaway jam game, that overhead is genuinely not worth it — the canvas trick is faster and, for five minutes of gameplay nobody screenshots closely, arguably good enough. We're not claiming otherwise. We just don't build for five-minute throwaway games, and once quality is the actual product, the slow path is the only one that survives contact with a real player.
