How to build a full game with Blender and GPT 5.6 Astra (not just a demo)
I built a full game with GPT-6 Astra, and it kinda blew up on X.
Initially it was just the demo, but 4 days later we have the full playable Okay, not just a crappy one-run demo.
Check PaperRoute out at paperroute.lol.
It's a Paperboy-style delivery game set in an American neighbourhood, and the whole thing was built over a handful of sessions with GPT-6 Astra writing the code and Blender making the models.
The thing is, for the very impressive one-shot, building an entire game is an entirely different story, and getting things to look styled and impressive is more than just prompting it once.
this is the run book I used to get a polished (as polished as possible in four days) game that works, looks great and is more than a one trick pony and it actually wasn't even 4 days - Having had the video blow up on X, the rest of the time was pretty much spent dialling in the website, getting it ready for you guys.
Every hour and every token was tracked, so I can tell you what it actually took rather than what it felt like. This is the full approach, in the order it happened. I've also done a full entire devlog of every step.
Read the full dev log here
every turn, every screen, every stat
Background
Back in July I wanted to give Fable a shot at Building paperboy. But a modern take - so I wrote a brief
A week of deliveries from Monday to Sunday, subscribers and non-subscribers, dogs, cars, the diagonal camera. I also wanted it to be a native iOS build. As well as web. But only got as far as a grey-box street and a rider before it stalled in July. More on that later.)
It didnt go very well and i Gave up
All fable could msuter was a sideways bike
AGI? nah mate, ngmi (yet)
Ok it wasnt that bad. Fable was pretty impressive and I did get somewhere but just not where I wanted to get to.
Step 1 - Start with a brief you already believe in
The concept didn't come from Astra.
When astra launched and I watched the OpenAI demo, I thought it could be a perfect fit.
So I rewrote my original brief rather than reusing it.
Honestly, the prompt was super simple.
In plain English, described the original game, some of the mechanics, and then I gave it a description of what I wanted it to do.
We just focused on the mechanics at this point and gave it a perspective view image reference. The original paperboy perspective.
The idea was never to clone the original Paperboy game. It was to take the concept and give it a new spin. But if you're going to hand a model a starting point, hand it the best one there is, and for a delivery game on a bike the best basis is the original.
Get the mechanics right first, then spin it once it's playable.
Step 2 - Dial in game direction
At this point im separating out two things
I gave Astra Two separate tasks.
- Art direction
- Game direction
Both in one thread.
After the first “one shot” astra gave me something demo-able. The isometric view and game style it gave me, I was going to keep, I was just going to change the game direction and the mechanics, changing the camera and how it looked up and felt. See, originally the first demo it gave me was pretty much the type of thing that you see on Twitter.
One shot, looks good, really interesting, and it has its own opinionated art style, and pretty much the same GUI that you've seen on every other demo posted.
At that stage all I cared about was the concept and the game mechanics, and a big pile of art direction would only have diluted that.
That decision paid for itself 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 that ends in a park course, in six commits before midnight. It wrote the tests as it went, which mattered more than I expected, because every art change after that had a suite to run against.
Time to dial it in.
Step 3 - Dial in art direction
After I got the first pass with the angles and how I wanted the game to feel. I could now work on dialling in the art direction alongside prompts improving the game mechanics, the paper toss etc.
I generated a bunch images with GPT.
I actually jumped out of Astra at this point while the game was compiling and I worked with Chat GPT, giving it a few reference images to come up with some concept art and a mood board.
No it wasnt the “Ghibli” style neither. I never used that word once.
Instead what I gave it was a descriptive reference of cool Japanese summer's breeze film with a painted texture effect.
GPT then produced me a style reference mood board which I would then feed and use as the basis to dial in.
I didn't want to overwhelm the model or the prompt with detail about exactly how the game should look yet.
Running the workstreams, In one thread
I don't usually do this, I usually fork things off, but with my new workflow and my T3 code form, which I've customised, I felt like this would be the perfect opportunity to stay in one thread. And it seems that Astra can handle this more than Fablecap, you can interrupt it, and it seems to not drop the ball, which is amazing.
I iterated both prompt by prompt, on both art direction and game - watching it burn my MacBook while blender was invisibly running in the background and getting random deliveries of pretty impressive renders and tests. All the time, the demo was live on the URL and was pretty much playable throughout the whole thing.
The engine stream running the game engine - which I was dialling in as I was playing it in real time was the boring repetitive one and the one I'd do again exactly the same way.
Steering that stops when you let go. A crash recovery window so the same bin can't 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.
Running blender via Python.
The style stream was Blender. Astra doesn't open Blender, it writes Python that Blender runs headless, Not via the mcp.
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 and 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 by ten in the morning on day two.
Keeping the two streams apart is the thing I'd tell anyone to copy. When a house looks wrong you don't want to be arguing with the model about throw physics in the same thread.
Step 4 - Custom Models
When things get challenging use Meshy
I'll be honest, as good as Astra is at making models of houses and quite simple things BUT making them look good requires a lot of attention and prompting on each individual house.
My main rider Was looking like a wooden puppet and to be honest Astra couldn't do much better - And it certainly couldn't create a face.
So the best thing to do is either go and download some Blender assets for free, or if you have a specific character in mind I did, use meshy, create images in chatGPT
Send them to meshy for $8. I essentially got 300 image generations and I'm still way below the quota.
You can literally upload images to meshy and it will make them into a 3D model that you can download Drop them into Astra and ask it to simplify the polygons And boom, you've got a 3D custom model in your game that doesn't look like shit Iterating with Astra, burnt a load of tokens and I got nowhere
The model was absolutely crap until I used this meshy workflow.
Mashing the model onto the other bike that I made was a little bit of a challenge and took some back and forth but I got there in the end and certainly got to a result that was passable. Not perfect but passable. I could probably burn a load more prompts here dialling it in.
Top tip : if you rig properly SKUs the limit
Step 5 - add details
One shot games lack details.
One shot games lack effort.
Sure, they may in-build the novelty, but custom animations, better UI make games fell real.
that's not to say what we are witnessing is undeniable. it's insane what can be done.
But taste is still the moat for now (and patience)
I spent 80-% of my actual session time and agent turns polishing, fixing bad mesh and prompting details. Not building the game
For paper route - the 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, rebuild the sleeves and arms so skin couldn't poke through the shirt, separate the shorts hem from the legs, fit the whole thing to the existing bicycle with proper hand grips and pedal contacts, and rig it with 23 bones including three for the hair and three for the shirt hem so they move with speed.
I've got about 30 commits that read back like a bloody 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.
Tip : Set up review loops
Review renders are the actual job.
I only understood this partway through.
Early on I prompted and built a harness in for always looping through and reviewing the work. I would get it to self-look at what was wrong with the model, do isolated renders of that model, and then send it back to me for review, and then I would prompt 60-70% of all the improvement from Render 1 to Render 2 Done by 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's off you point at the frame, say the cap doesn't cover the hair, and that's the prompt.
Step 6 : Add Taste and flourishes
Everything above is process. Process gets you a game that works. It doesn't get you one anyone wants to play twice, and that gap is taste, which is the bit you have to bring yourself.
You cant one shot your way to a good looking and full game. You’ll end up with slop
Some of the taste here was throwing things away.
The original models went, pretty much all of them, replaced with completely custom characters. (Or would be)
You can see it in how the game art translated into the old man and the kid with the remote control. If I was going to spend more time, that's where I'd spend it. More characters, and making the ones I have come to life a bit more, so the street feels dynamic and has some personality.
Then the flourishes.
The smashing window effect got a whole other branch of its own. So did a rainy day. Again, within one stream, but two separate subagent threads. New work trees and new versions of the game to test in isolation, ready to merge in.
I even spent a chunk of time dialling in the fall.
Tip : run experiments and game branches To test ideas of functionality before folding them in.
I wanted the window smash - But I wasn't sure if it was going to work, so I tested it in its own branch.
Just the window smash, with a completely separate camera that zooms to the window, holds on the impact and swings back to the rider. After the first pass I elongated the skate park at the end and made it more of a training ground, so the route finishes on something fun instead of just stopping.
As I went on I built bigger mansions and dropped them along the street to give it some dynamism. And most importantly I made a whole new weather system. Little things first, splashes and tyre marks coming out of puddles, and then a whole day that's just a pure rainy day.
These are the things that bring a game to life and add dimension.
This one could easily have been a flat road you play once on repeat to a maximum score. Mixing these things up gives it a new dimension, and that's where taste really matters.
The website was the same. The thing that stopped me getting this live instantly was making the website 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. I think I've done an okay job at that.
What it cost
DevClocked tracked the lot. From the first planning commit on 1 July to 12 September, four days past the hosted launch:
Presence tracking only started on 6 September. Before that, tracked time counts me as present by default. After it, two thirds of tracked time had didn't have me at the keyboard.
Eight commits, then a two-month gap. The browser rebuild in September took four days of building and a fifth to launch, and that's the game people are playing. I don't fully regret July, because the brief and the simulation design survived it, but if I'd started in the browser I'd have had something playable on day one.
Also unresolved, and I'd rather say so than pretend. Sustained 60fps on a phone isn't proven. One controlled run held it, another averaged 58. The Meshy rider is 88,550 triangles because I kept the face, and I haven't benchmarked that on a real handset yet.
TLDR : The order, if you want to do this yourself
Then put it on a domain.
This one is on paperroute.lol, and the devlog there has every checkpoint, render and hour behind it.
@MeshyAI cough cough, ahem
