How to Build a Full Game with Blender and GPT-6 Astra (Not Just a Demo)

I built a full game with GPT-6 Astra, and the demo video found an audience on X. What started as a single one-shot demo became, four days later, a complete playable game: PaperRoute, a Paperboy-style delivery game set in an American neighbourhood. Astra wrote the code, Blender made the models, and the whole thing was built over a handful of sessions.

The impressive one-shot is real, and it is also beside the point. Building an entire game is a different job, and getting it to look styled rather than merely generated takes more than prompting a model once. This is the run book behind a game that works, looks good, and is more than a one-trick pony, in the order it actually happened. Every hour and every token was tracked, so the numbers below are what it took rather than what it felt like. A full devlog covering every turn, every screen and every stat lives on the game site.

Background: the July attempt that stalled

Back in July the same idea was handed to Fable. A brief was written for a modern take on Paperboy: a week of deliveries from Monday to Sunday, subscribers and non-subscribers, dogs, cars, the diagonal camera. The goal was a native iOS build as well as a web version.

It reached a grey-box street and a rider, and then it stalled. The most Fable managed was a sideways bicycle. The honest read is that it was not a failure of the model so much as a failure to get to the intended place: Fable was impressive, the progress was real, but it never became the game in the head.

Step 1: start with a brief you already believe in

The concept did not come from Astra. When Astra launched and the OpenAI demo was watched, it looked like a perfect fit for this brief, so the brief was rewritten rather than reused.

The prompt itself was simple. In plain English it described the original game and some of its mechanics, then described what the new version should do. At this stage the focus was mechanics only, plus one perspective-view reference image: the original Paperboy camera angle.

The aim was never to clone Paperboy. It was to take the concept and give it a new spin. But if you hand a model a starting point, hand it the best one that exists, and for a bicycle delivery game the best basis is the original. Get the mechanics right first, then spin it once it is playable.

Step 2: dial in game direction

Two things were separated here, and both ran in the same thread: art direction and game direction.

After the first one-shot there was something demo-able. The isometric view and the game style it produced were worth keeping; the game direction, the mechanics, the camera, the look and the feel were not. That first pass looked like most of what circulates on X: one shot, looks good, genuinely interesting, an opinionated art style, and essentially the same GUI as every other posted demo.

At that stage the only things that mattered were the concept and the game mechanics. A large pile of art direction on top would have diluted both.

That decision paid for itself on the first evening. Astra built a browser version with a deterministic simulation, aimed ballistic paper throws that land where the dotted arc says they will, mailbox scoring, and a route ending in a park course, in six commits before midnight. It wrote the tests as it went, which mattered more than expected, because every art change after that had a suite to run against.

Step 3: dial in art direction

With the angles and the feel of the game settled in a first pass, art direction could be dialled in alongside prompts that kept improving the mechanics and the paper toss.

The concept art came from GPT. While the game was compiling, the work jumped out of Astra and into ChatGPT with a few reference images to produce concept art and a moodboard. It was not the "Ghibli" style, and that word was never used once. What was given instead was a descriptive reference: a cool Japanese summer's breeze film with a painted texture effect. GPT returned a style-reference moodboard, which then became the basis for dialling the game in.

Deliberately, the prompt was not yet crowded with detail about exactly how the game should look.

Two workstreams, one thread

Usually these would be forked off into separate threads. With the new workflow and a customised T3 code form, staying in one thread looked like the right opportunity, and Astra handled it better than Fable had. It can be interrupted mid-task and it does not seem to drop the ball.

Both streams iterated prompt by prompt: art direction and game at the same time, the MacBook burning while Blender ran invisibly in the background, and random deliveries of quite impressive renders and passing tests. Throughout all of it the demo stayed live on its URL and was pretty much playable.

The engine stream is the boring, repetitive one, and it is the one that would be repeated exactly the same way. Steering that stops when you let go. A crash recovery window so the same bin cannot eat three lives. Dogs that actually chase and can be outrun or distracted with a paper. Mobile controls where you drag to steer, hold to pedal and tap to throw. Each of those was one prompt, one look at the result in the browser, one commit.

Blender driven by Python, not by MCP

The style stream was Blender. Astra does not open Blender; it writes Python that Blender runs headless, not through an MCP server. Every house, tree, fence and mailbox in the game is a script that builds the mesh, splits the materials and exports a GLB.

The first pass was a standalone summer art study: a page of house silhouettes, tree shapes and street props rendered on their own, before any of it touched the playable world. Then the house families went in, then denser gardens, then the painterly surfaces. Seven house families existed by ten in the morning on day two.

Keeping the two streams apart is the part worth copying. When a house looks wrong, the last thing wanted is an argument with the model about throw physics in the same thread.

Step 4: custom models, where Meshy earns its place

Astra is good at houses and at fairly simple things, but making them look good requires attention and prompting on each individual house. The main rider was another matter: it looked like a wooden puppet, Astra could not do much better, and it certainly could not create a face.

Two options exist at that point. Either download free Blender assets, or, if a specific character is in mind, generate images in ChatGPT and send them to Meshy. Eight dollars bought roughly 300 image generations, and the quota is still nowhere near used up.

The workflow is direct: upload images to Meshy, get back a 3D model to download, drop it into Astra and ask it to simplify the polygons. The result is a custom 3D model in the game that holds up visually. Iterating on the rider with Astra alone burned a large number of tokens and went nowhere; the model stayed poor until the Meshy workflow was used.

Mashing the new model onto the existing bicycle took some back and forth, but it reached a passable result. Not perfect, passable, and more prompts could still tighten it.

The tip that follows from this: rig properly, and SKUs become the limit rather than the models.

Step 5: add details

One-shot games lack detail, and they lack effort. Novelty is built in, but custom animations and better UI are what make a game feel real. What is happening with these models is genuinely remarkable, and it is also true that taste, plus patience, is still the moat.

Roughly 80 percent of actual session time and agent turns went into polishing, fixing bad mesh and prompting details, not into building the game. For PaperRoute that finesse turned out to mean a lot.

Astra wrote Blender scripts to reduce the body to a game budget polygon-wise while keeping the original face, hair locks and cap seam; to rebuild the sleeves and arms so skin could not poke through the shirt; to separate the shorts hem from the legs; to fit the whole thing to the existing bicycle with proper hand grips and pedal contacts; and to rig it with 23 bones, including three for the hair and three for the shirt hem so they move with speed.

About 30 commits read back like a tailor's notebook: repair rider garment geometry, rebuild rider arms and sleeves, preserve the shorts hems, give the bicycle straighter BMX handlebars.

The same loop then ran for the grumpy man with the newspaper who comes out of his house, and the boy with the toy controller. Concept in ChatGPT, mesh from Meshy, scripts in Blender via Astra, rig, review renders, into the game. Once the pipeline exists, the second character costs a fraction of the first.

Review renders are the actual job

This only became clear partway through. Early on a harness was prompted and built for always looping through and reviewing the work: have the agent self-inspect what is wrong with the model, produce isolated renders of that model, and send them back for human review. Somewhere between 60 and 70 percent of all improvement from render one to render two came from the agent doing this.

You review 3D work from a model by looking at renders. Astra set up capture scripts that put the actual Three.js rider through steering, throw, sprint and fall poses and saved front, side, rear and clay turnarounds every time. Every checkpoint in the devlog has those renders next to it. When something is off, you point at the frame and say the cap does not cover the hair, and that is the prompt.

Step 6: add taste and flourishes

Everything above is process. Process gets you a game that works. It does not get you one anyone wants to play twice, and that gap is taste, which has to come from the person holding the brief. You cannot one-shot your way to a good-looking, complete game; you end up with slop.

Some of the taste here was throwing things away. The original models went, pretty much all of them, replaced by completely custom characters. The game's art direction is visible in the old man and the kid with the remote control. With more time available, that is where it would go: more characters, and making the existing ones come alive so the street feels dynamic and has some personality.

Then the flourishes. The smashing window effect got a whole branch of its own, and so did a rainy day. Both ran inside one stream but as two separate subagent threads, with new worktrees and new versions of the game to test in isolation, ready to merge in.

A chunk of time also went into dialling in the fall.

The pattern is worth stating plainly: run experiments and game branches to test ideas before folding them in. The window smash was wanted, but it was not clear it would work, so it was tested on its own branch, with a completely separate camera that zooms to the window, holds on the impact and swings back to the rider. After the first pass the skate park at the end was elongated into something more like a training ground, so the route finishes on something fun instead of just stopping.

As the work continued, bigger mansions were built and dropped along the street to give it dynamism. Most importantly a whole new weather system went in: small things first, splashes and tyre marks coming out of puddles, and then an entire day that is purely rain.

These are the things that bring a game to life and add dimension. Without them this could easily have been a flat road played once on repeat towards a maximum score. Mixing it up is where taste actually matters.

The website followed the same logic. What stopped an instant launch was making the site believable and wrapping the whole concept in it. The landing page is a newspaper, the results are a newspaper, the league table is a newspaper.

What it cost

DevClocked tracked all of it. From the first planning commit on 1 July to 12 September, four days past the hosted launch:

• 39 hours of tracked coverage, split 25.2 human and 13.8 agent-only
• 1.56 billion tokens, 1.53 billion of those cached reads
• $2,175 of API value, which is not the actual bill
• 90 commits across 11 days

Presence tracking only started on 6 September. Before that, tracked time counts the human as present by default. After it, two thirds of tracked time happened with nobody at the keyboard.

Eight commits, then a two-month gap. The browser rebuild in September took four days of building and a fifth day to launch, and that is the game people are playing. July is not fully regretted, because the brief and the simulation design survived it, but starting in the browser would have produced something playable on day one.

Two things remain unresolved, and it is better to say so than to pretend. Sustained 60fps on a phone is not proven: one controlled run held it, another averaged 58.3. And the Meshy rider is 88,550 triangles because the face was kept, which has not been benchmarked on a real handset yet.

TLDR: the order, if you want to do this yourself

1. Write the brief in your own words first, and pick the one reference closest to what you want, even if it is the thing you are not allowed to clone.
2. Give the model the brief and two or three rough images, and hold the art direction back until the mechanics are playable.
3. Run the engine and the look as separate conversations.
4. Build props in Blender from Python so every asset is reproducible.
5. When a character needs a face, make the concept in ChatGPT, get the mesh from Meshy, and hand it to Astra to reduce, rig and fit.
6. Get review renders on every change, and keep a day for the flourishes: the weather, the window smash, the park at the end, because that is what makes it worth a second run.
7. Track your hours and tokens, because you will want to know.

Then put it on a domain. This one is at paperroute.lol, and the devlog there carries every checkpoint, render and hour behind the build.

Source: How to build a full game with Blender and GPT 5.6 Astra (not just a demo) — Emm Tee (@builtbysketch). Game and devlog: paperroute.lol.