Building Agoro Road in public

A working log of a game that is not finished. What we decided, what it cost, and the things that came out wrong — including the ones we had already told ourselves were fine.

Updated 20 September 2026 Newest first In development
The standard this page holds itself to

Everything here was true on the date above it. Concept art is labelled as concept art and screenshots are labelled as screenshots, because on this project the difference between them has been the whole problem. Where a decision reversed an earlier one, the earlier one stays on the page.

Where the road stands

The short version, kept in one place and updated with the log. Every other page and every post we write starts from this list.

Status 21 September 2026Every surface, with its state
Play free in the browserLiveThe complete Hearthland region, co-op by private code, no account.
Reservations · Wave 1 editionsOpenFree, email only, nothing charged. Digital €12.99 · Supporter €19.99 · Collector's €99 / €149 (500 places) · Founder's €250 (20 places).
iOS · App StoreIn preparationThe app identifier is registered with Apple. The store record and the first build are being prepared now; the date is announced here when the build is submitted.
Android · Google PlayIn preparationSame build. No Play listing exists yet; it follows the iOS record.
The road in 3D (web and desktop)In preparationHolds 60 frames a second. Eleven of its objects are still stand-ins, so it is not switched on for players yet.
Figurines, printed hereIn preparationFirst travellers printed 14 September on the studio's own printer. A 10 cm figure takes two to three hours to print.
RevenueCat Shipaton 2026In preparationWe build in public for it and this log is the hub for those posts. Submissions close 30 September.
Tripothon S1RegisteredRegistered on 14 September. Submissions run 15 September to 5 October; ours is the road in 3D.
IndiegogoIn preparationA campaign page is being prepared. Indiegogo starts a campaign no earlier than seven days after its review, so the date is announced here first.

Epic says you need a PC. We ran their editor on a MacBook — and then hit three walls that had nothing to do with the Mac.

Unreal Editor for Fortnite is Windows-only. The documentation is blunt about it: to use UEFN, you will need a PC. We do not have one here. So Windows went into a virtual machine on the laptop, and the editor opened, and Verse compiled, and our travellers, the cart, a tree and a watch-post stood in a Fortnite island that we then played on a tablet.

That part worked. The three things we learned next are the useful part, and none of them is about hardware.

You cannot be your own character. The player in Fortnite is a Fortnite avatar. The realistic-human system is allowed in the editor, but the licence permits it only for characters you meet, never the one you play. A game whose whole subject is the traveller you are cannot put its traveller in the player's hands there.

The game will not run where the editor runs. Fortnite needs a security feature the virtual machine cannot provide, so the editing happens on the Mac and the playtesting happens on a tablet, by code. That loop works, and it is slower than it sounds.

And the photographed world could not come in. We had rebuilt our rest camp from eight generated views — as a cloud of points it is genuinely good, the best look at this place we have. Converted to the kind of surface a game engine wants, it is confetti: over a million fragments that do not simplify. Cutting it by more than ninety-nine per cent removed a third of them. It is a picture you can stand inside, not geometry you can build on.

What changed — we now ask whether a platform can host our thing before we spend a day making our thing fit the platform. Every one of these three walls was published, or measurable, before we started. The detour was not wasted — we came out with a working Windows lane and a reusable route for our own models — but the question that would have found the walls costs an afternoon of reading, and we did it in the wrong order.

The 3D view holds sixty frames a second. It still is not something you can look at.

The second renderer is finished. Same game underneath, two ways of drawing it: the original flat view and a real-time 3D one, sharing one simulation that neither of them is allowed to touch. Both replay an identical recorded run to an identical result — the proof that the 3D view is a view and not a second, subtly different game.

On the test deployment it draws a frame in about 16.7 milliseconds, and the slowest one in a long run took 16.8. That is a locked sixty frames a second with forty travellers walking and roughly seven hundred thousand triangles on screen. Seventeen of seventeen checks pass.

And it is still not shippable, because eleven of the objects standing in it are placeholders — the ones described in the entry below, generated from written descriptions instead of from the concept art. The renderer is done. The thing the renderer draws is not.

What changed — "the renderer is finished" and "the game looks right" turned out to be independent, and we had been quietly treating the first as evidence for the second. A performance number cannot see art direction. We now report them as two separate states, because a green build that draws the wrong objects at sixty frames a second is still the wrong objects.

And — the asset work moved off a person clicking through a web tool and onto something the build can run directly. That removes an entire class of mistake we had been making: the settings in that tool silently reset between steps — privacy, detail level, which animations get exported — and three separate sessions lost work to it. The replacement is not cleverer, it just cannot forget a checkbox.

The obvious setting did nothing. So we measured where the supports actually touch.

Yesterday's two prints (below) failed on one quantity: material left on the figure. Our slicing checks had passed both files, because none of them measured that. So the first thing built this morning was the missing instrument: a script that reads the finished toolpath and reports how many square millimetres of support tips touch the model, in how many spots, and whether any support trunk grows out of the figure itself.

Then the setting everyone reaches for. "Supports on the build plate only" sounds like the fix for residue. On Daniel's file it changed 191 mm² in 1,083 spots to 184 mm² in 1,040 — because every one of the seven trunks was already standing on the plate. The residue was never the trunks. It was the tips under the bag, the hands and the chin, and the branches brushing the walls on the way up.

What did move it: thinner trees with a single wall, a wider gap to the walls, a taller gap under the model and a steeper threshold. Daniel 191 → 127 mm² (with the soles cut flat so nothing sits under the feet). Amara 178 → 45 mm², with no struts, no posts and no block — the two curls that still started in mid-air got a hidden 1 mm bridge into the hair mass, two millimetres long, that never has to be removed. Twelve small tilts of each figure were sliced and measured; every one was worse than standing upright. Layer height turned out to be a lever too: at 0.14 mm instead of 0.2 mm the tips on Amara fall to 8.5 mm², for 27 more minutes of printing — sliced and measured, not yet printed.

The printed 80 mm Amara figurine seen from behind: purple PLA, six short post stubs at the nape below the hair, rough support residue between the legs under the dress hem
What the instrument was built to measure. Photograph of the first Amara print: the posts at the nape and the block residue under the hem.
The printed 97 mm Daniel figurine lying on a wooden table: purple PLA covered in fine strings, with rough patches on the shoulder bag and along the walking staff
The same day, Daniel at 97 mm. Photograph. Fine strings over the torso, tree scars on the bag and the staff.

What changed — a print is judged by residue on the figure, measured from the toolpath, not by the share of support in the file. And "find a way" means a different approach on the table next to the tuned one: today's plan is both figures at 120 mm on a base plate (sliced: 5 h 07 and 6 h 17), a support lane that grows its own thin pillars from the plate with pin-point tips instead of the slicer's interface layers, two research passes on how other figurine printers handle supports and layer heights, and the first print of the reworked Amara.

We printed the first two travellers on our own printer. The supports won.

Two figures came off the desktop printer for the first time: Amara Sol at 80 mm and Daniel at 97 mm, in the one purple filament we have loaded. Each carried a different answer to the same question — how to hold up hands, a pot, a hem and hair curls while they print.

Amara used our own answer: thin struts and pegs fused into the model, snipped off afterwards, plus a solid block under the hem. Daniel used the slicer's tree supports. Both answers were wrong at this size. The pegs behind Amara's hair and under her earrings cannot be reached with cutters at 80 mm. The block under the hem left rubble between her legs. Daniel came off the plate covered in fine strings, with scars where the trees had held the bag and the staff.

Around the print, the pieces that let people watch it went live the same day: a browser view that replays the toolpath as the printer reports its progress, a post every five per cent to the community server, and a "wake the printer" walkthrough for the stream. None of that changes what the prints look like; it changes who can see them.

The printed 80 mm Amara figurine lying on its side on a wooden table, purple PLA, with thin support rods still attached from the dress to the hands and pot
Amara at 80 mm, first print. Photograph. The rods from the dress into the hands were our design — and they do not come off cleanly at this scale.

What changed — struts and pegs fused into a figure under 100 mm are retired; whatever holds the print up has to stand on the plate and touch the figure as little as possible. And every check that said these files were ready is now paired with one that measures what the checks had missed.

We put the renderer's own screenshot next to the concept art. Nobody had ever done that.

The 3D view had passed everything we asked of it. The same inputs replay to the same frame over six hundred frames, the frame times are fine on a phone, the fourteen finished meshes stand on the right rings. All of that is true and all of it was verified.

What nobody had done was put a capture of it beside the picture it is supposed to look like. When we finally did, the distance was not small. The ground is one flat green plane with no horizon. The road is a beige ribbon. The carved stone rings — the hero element of every frame in this game — are translucent pale discs at thirty per cent opacity.

None of that is a bug. Every one of those is something that was never built, passing a test that never looked.

The Agoro Road 3D view on 13 September 2026: a flat green ground plane, a beige road ribbon, translucent pale discs for the rings, and the finished meshes standing along the road
The build, 13 September. A capture from the real renderer, at the game’s locked camera.
The concept frame: Lantern Bend at dusk, a winding earth road through an upland valley with carved rings, a watch-post, a lantern post and a garden bed
The concept frame it is judged against. Lantern Bend at dusk.

What changed — the look is now part of acceptance. A capture goes beside the concept frame and gets judged the way an art asset gets judged. A test suite that does not include the look will happily certify a build that does not look right.

Eleven props came out wrong. We are redoing all eleven, not the six that failed.

The buildings and props were generated from written descriptions. The concept art for most of them already existed, in the same folder, and was not used.

The drum came back as a black cast-iron cauldron. The lantern came back as a Victorian street lamp. The goods cart came back as a wooden barrow. Judged one by one against the cards they were meant to match: four were the wrong object or the wrong palette, two had no card to judge against, and five were close enough to ship at map scale.

The tempting call was to redo the four and keep the five. Daniel ruled the other way.

we need consistent look across the concept art and props and images and trailersDaniel, 13 September 2026

So all eleven are being made again from the art, not from descriptions of the art. The five that were individually acceptable were not acceptable as part of a set, because a set is the thing we are actually making.

Correction, 20 September. Two of the three examples above are right and one is not. When we finally rendered the delivered drum and looked at it, it is a drum — a standing drum on a stand, the correct object. What is wrong with it is the material: lacquered orange, where the card is hide, rope and weathered wood. The "cast-iron cauldron" line came from a written note that nobody checked against the model, and it then travelled through three of our own documents as though it were an observation. The mistake it describes is real; the example was wrong. We are leaving the original sentence above rather than quietly editing it, because the failure it caused — asserting about an image without opening the image — is the same failure this entry is about, and we made it while writing the entry.

The concept card for the Echo Drum: a large standing drum with a hide head and rope tensioning on a carved wooden stand, two beaters on the rim
The Echo Drum as designed. This card existed before the model was made. The model came back a cast-iron cauldron.

What changed — "acceptable in isolation" is not a pass when the job is one art direction. And we inventory the concept art before generating anything, because the picture is a better brief than any description of the picture.

We ran a bake-off that reversed our own recommendation.

Earlier in the week we had recommended one of the AI image providers we use for making reference plates. That recommendation had a caveat written into it by the person who made it, and the caveat was the honest part: nothing had ever been compared against the alternative. It said this provider is good enough on our art. It did not say this provider wins.

So we closed the gap: the same jobs through two providers, seven configurations, three runs each — twenty-one images for about forty-seven credits, roughly what a single wrong 3D asset costs to make.

The other provider won, and the plate work moved. We had been about to standardise on the recommendation without ever having tested it.

What changed — a recommendation that has never been measured against an alternative is a preference. If we cannot name what it beat, it has not been decided yet.

Three travellers that came out right, and why they did.

These three went a different route than the eleven. The concept card was turned into a clean standing plate, and the plate — not a description — was turned into the model. Rigged, with idle and walk.

The same person survives all three stages. The scarf, the satchel and the head wrap are still there at the end. The roped bundle on the carrier's back came out as real geometry rather than a painted-on suggestion.

That is the entire argument for driving this pipeline from art instead of from text, and it is why the eleven are being done again.

Concept card for the road walker: a traveller in a hooded cloak over an indigo tunic, with a satchel and a walking staff
1 · The concept card. A drawing.
The finished road walker game asset: the same character as a rigged 3D model
2 · The finished game asset. The same man — the grey-flecked hair, the undyed wool cloak, the indigo tunic, the satchel and the staff all came through. Only the pose changed.

Our companion is a bird, and the animation library turned out to have no birds in it.

Kofa is the Sankofa bird. He was built for Agoro Camp and he belongs to the studio rather than to one game — the same bird, the same look, different abilities in each — so bringing him to this road costs us nothing to design. His loop is retrieve, reveal, scout, and scout only unlocks on ground whose past you have already retrieved. The future is not visible until the past is known. That rule is the character, not a flavour text.

The gold egg he carries is the read-out for it: empty means this place's past is still lost. That works because the egg came out of the mesh as a genuinely separate object, so the game can actually light it rather than just imply it.

The mesh is finished — textured, with a fifty-six-bone rig. Then we opened the animation library we had planned to take flight cycles from and found it classes a two-legged bird as avian, and its avian section is empty. Not thin. Empty.

So every clip he has will be hand-authored. That is a real cost and it is now in the plan rather than in a surprise.

Update, 13 September. When we went to pose him, he shredded. The rig was not merely missing its animations — its skeleton was in the wrong place. We measured each bone against the flesh it actually controls: the bones sat, on average, most of a body-length away from it, and the beak's bone was further from the beak than the bird is tall. Two human characters rigged by the same tool measured twenty-five times better, which is how we knew it was the rig and not our ruler.

The weights — which vertex follows which bone — were fine. So we kept those and moved every bone back inside its own body, working out each joint from the region where two bones share influence. That got him standing. The picture below is the first one that has ever existed of this character.

Then the second fault: pieces of the gold egg were tied to a toe, a quarter of their weight each, on the far side of the body. At rest that is invisible, because at rest every bone agrees. The moment his head swung, the egg tore into shards. Both faults hid in the one pose anybody ever looks at.

Kofa standing: a tall blue-and-gold bird with adinkra patterning across its neck and body, a long curved neck, and a gold egg held in its beak
1 · Standing, for the first time. The same mesh that had been unusable all week. Nothing was resculpted — only the skeleton was put back where it belonged.
Kofa performing the sankofa look-back: the neck arcs up and back over the spine, the head reversed, the gold egg carried with it
2 · The move he exists for. The neck arcs back over the spine, the head reverses, the egg comes with it. Go back and fetch it.

He now has three hand-authored clips — a walk, an idle, and the look-back above. They live in the character file; he is not in the playable build yet.

What changed — we now check that a tool can do the specific thing before the asset depends on it. "It has an animation library" and "it has an animation library for this" are different sentences.

And — our first look-back passed every check we had written and was still unusable: the neck tied itself in a knot and the head finished buried in a wing. The checks measured whether the beak reached its target and whether anything intersected. Neither of them could see a silhouette, which is the entire point of that pose. We now test the outline for crossing itself, and every edge of the mesh against its original length — and we look at the picture. A check that cannot observe the way a thing fails will certify it as fine.

What players have already changed

Two of these came from our released games rather than from Agoro Road — but they changed how this one gets built, so they belong here.

The shop that would not sell anything

“Wieso kann ich die nicht kaufen?”

A tester in Germany sent one line about Agoro Bounce: why can't I buy these? The shop was showing coming soon on everything.

The shop was not broken. The public test link was still handing out the very first build — made before the shop existed. Every newer build had gone to the private group only. He was right, and he was looking at something ten builds old.

What changed

We stopped assuming the public link serves what we last uploaded. It has its own build and it has to be pointed at the new one deliberately. Now we open the link a tester actually gets.

The name field that ate the letter S

Type “Sam”. Get “am”.

Daniel hit this on the live Agoro Bounce site. The game's keyboard shortcuts were still listening while the name box had focus, and s was a shortcut — so the letter went to the game instead of into the field.

We fixed it that morning. Eleven hours later he reported it still broken, and it was. The fix was in the code and not on the site: a later publish had gone out from an older copy of the project and quietly put the old version back.

What changed

Fixed is not shipped. We load the real page and confirm the fix is in what the server is actually serving before anyone says it's done.

About this log

Agoro Road is in development and free to play in the browser while it is made. This log is part of how we build in public during Shipaton 2026; our released apps are Agoro Pocket, Agoro Bounce and Lanternlight, and each is its own entry. Nothing on this page is a release announcement.

See the rest of what we make →