Built to say no
written 2026-09-02Before a machine can make the models in a game, something has to be capable of telling you when it has failed. So we asked the one question that could have ended the whole idea, answered it on 6 models, and then went looking for the places our own code was quietly covering things up.
Chapter one was about taste. We asked a 3D-generation service to make the same 3 subjects in every art style it offers, and found out that a style name changes the paint and not the shape. That was the cheap question.
This is the expensive one, and it is not about art at all. Bannerfall's units are not statues. Each one is a shell of geometry with a skeleton threaded through it, and every point on that shell is tied to the bones nearest it, so that when a bone swings the right piece of the model swings with it. The game already owns its skeletons and its walk cycles. Nobody knew whether a shape a machine had invented — which has never heard of any of that — could be threaded onto one of them and made to march.
If the answer was no, the plan was over: the models would go on being bought from a library and the interesting half of this project would quietly stop. So it was asked first, on as few models as would answer it honestly, before anything at all was built on top of it.
Anything set like 0.0665 was measured by a machine and generated into this page from the committed results. Everything else was written by a person.
One question, asked before anything was stacked on top of it
There is a version of this project where the machine makes lovely scenery and cannot produce a single soldier, because a soldier has to move. Everything else in the plan sits on the assumption that it can. An assumption that load-bearing is not something to find out about at the end.
So the whole thing was staked on 6 models, chosen to be awkward rather than flattering: a plain spearman, an archer, a robed spellcaster, a four-legged beast, and a rider and a horse ordered as two entirely separate models to be joined afterwards. The robe was deliberate. A floor-length robe is the case everyone warns you about, because the sleeves tend to come back fused to the body and the legs fused to each other, and there is nothing underneath to separate. Between them they had to fit 4 different skeletons the game already uses.
What counted as a pass was fixed before the first order and left nothing to negotiate: every point of every surface attached to a bone, every instruction in the walk cycle still landing on a bone that exists, and nobody allowed to fix anything by hand. That last clause is the one that matters. Attaching a stubborn model to a skeleton by hand is the normal rescue, and it is slow, skilled, one-model-at-a-time work — so a pass that needed it was a fail, because this project needs far more models than anyone is going to hand-finish.
The number that came back was 0. Out of 77,983 points of surface across every model, 0 came out unattached, and there were 0 re-orders — nothing was quietly cast again until it behaved. The rider and the horse, two unrelated orders on two unrelated skeletons, joined into a single file in which one walk cycle drives all 91 of their bones together.
It is worth saying plainly what the other answer would have meant, because a test you would not have believed is not a test. It would have meant writing that down, stopping, and going back to buying models. This build log would have ended at one chapter.
A photograph of a broken model looks exactly like a photograph of a working one
The obvious way to check is to look at it. Put the model on the board, press play, take a picture. That does not work here, and why it does not work is the most useful thing in this chapter.
The game slides a unit across the map by moving the whole model, which has nothing to do with any animation playing inside it. And when a walk cycle asks for a bone a particular model does not have, the game drops that one instruction and plays the rest without complaint — sensible behaviour, arrived at for good reasons, and lethal here. Put the two together and a model whose surface was never attached to its skeleton stands perfectly still while gliding across the board in the right direction, at the right speed, arriving exactly where it should. It photographs as a pass.
So the check reads the file instead of the picture. Does the skeleton inside carry exactly the bones the game is going to address, under exactly those names? Is every point of the surface attached to something? Does every instruction in the walk still land somewhere real? None of that is visible in a render and all of it is decidable from the bytes.
And because a check that cannot fail is not a check, the last thing built was a machine for breaking things. It takes a model that passes, damages it in one specific way — renames a bone, deletes a bone, unpins a patch of surface, squashes the whole model flat — and demands the checker notice. Every one of those was noticed. A picture was taken too, and it is on the record; it is evidence of what the thing looks like, and nothing more than that.
The orders that were cancelled before they cost anything
The written plan for this test contradicted itself, and nobody noticed until the orders were already queued.
The game's skeletons arrive inside the models they were built for, and those models stand in one particular rest position: arms straight out to the sides, like a scarecrow. The way a new shape gets attached to an existing skeleton is by borrowing the attachment from that original model, point by point, by nearness. Which only works if the two are standing the same way. The plan asked for the new models to be ordered standing with their arms down — and, a few lines later, asked for them to match the rest position of the model they would be borrowing from. Both of those cannot be true at once.
Borrowing by nearness from a scarecrow onto a figure with its arms at its sides does exactly what you would expect. The instructions meant for the arm land on the closest thing available, which is the chest. The models would have come back with their torsos crumpling every time an arm moved, the test would have failed, and it would have failed for a reason with nothing whatever to do with the question being asked. That is the worst thing that can happen to a test like this: a false no, on the one question you cannot afford to get wrong.
4 orders were pulled back out of the queue before they reached the hardware and placed again with the arms out. Nothing was spent. The only reason it was caught is that somebody checked the plan against the actual models instead of against itself.
You cannot ask it which way to face
Every one of the 6 orders asked, in identical words, for the model to arrive facing forward. One of them did, to within 0.08 of a degree. Another turned up 151.0 degrees round — which is to say very nearly backwards — and the rest were scattered across everything in between. Nothing in the wording accounts for the difference, because the wording was the same every time.
It is a small finding with a large consequence for anything built on top of this. You cannot ask a generated model which way to point. Every one of them has to have its facing measured off its own geometry and baked in before the game is ever shown it, and a pipeline that takes the order at its word will ship an army marching sideways.
A warning that keeps being wrong about correct work
The service marks a delivery as suspect when the model is far thinner in one direction than in the others. That is a good rule aimed at a real failure: a common way for one of these to come back wrong is with the object sitting on a flat slab of scenery, and a slab is thin.
4 of the 6 models came back flagged. Every one of them was a person standing with their arms held straight out — which is to say, about two metres wide and about as deep, front to back, as a person is. There was no slab. The rule was measuring precisely what it claimed to measure and drawing the wrong conclusion from it, and the proof is sitting in the game already: the hand-made soldier the board has been rendering happily since long before any of this is thinner still by exactly the same measure.
The same rule turned up again the next day wearing a different hat. The plan on file said a building must be rejected outright if the service flags it. Then a length of castle wall came back flagged, on honest proportions: 1.99 long, 0.59 high and 0.32 thick. That is not a defect. That is a wall. A blanket rule would have thrown away a correct part for being correctly shaped.
Twice is a coincidence, so the third time it was measured properly — against 105 models, every one of which is either already on the board or has been checked by hand. 29 of them are flagged. All of them are fine; most are what is on your screen right now. The soldier the game has been rendering for months is about 17% as deep as he is wide, and the flagged new ones are about 24%, so the game's own art is the thinnest thing in the set. There is no line you could draw through that spread that separates good work from bad, because the spread is all good work.
Then the rule was asked to do the one job it was hired for. Take a soldier that came back correct, weld a slab of floor to the soles of his feet — the exact failure the warning is named after — and measure again. He stops being thin. With a floor attached he is about 98% as deep as he is wide, and the warning goes quiet. It fires on the clean model and says nothing at all about the broken one. That is not a rule that needs its threshold nudged; it is pointing the wrong way round, and moving the line only changes which correct models get thrown away.
The strangest part came last. The same soldier had been ordered twice, from identical words and the identical random seed, differing by exactly 1 instruction — and the two came back with the same shape down to the last decimal place of every corner of its bounding box. One was marked suspect. The other was not. Whatever that flag is measuring, it is not the model.
So the rule lost. What replaced it judges each piece on its own proportions instead of on the category of thing it belongs to. The plan was written by someone reasoning about shapes in the abstract; the measurement was taken off an actual wall, and when those two disagree it is not the wall that is wrong.
And it looks for the opposite thing. A person standing with their arms out is supposed to be thin; what a person standing on a slab suddenly becomes is square. So the new rule draws a floor and a ceiling around each way of standing, and it is the ceiling that catches the slab. Which leaves exactly one case unsolved — a flat tile with a floor welded to it, where thin is correct and square would be correct too — and no proportion test anywhere can help with that one. It needs somebody to look at the geometry itself, which is the next thing to build.
Then the same bad habit turned up in our own game
This project has one rule it will not bend: code fails loudly. It does not paper over a missing value, quietly substitute something plausible and carry on, because that is how a fault stays invisible for months. So the tool that prepares a generated model for the board was written to refuse rather than repair. It will not guess which part of a file you meant and it will not silently drop a piece it does not understand. It ships with 17 small hand-built files whose only purpose is to be fed to it — a few of them correct, most of them broken in exactly one way each — and it has to accept or reject every one of them by name, saying which rule was broken and where.
Writing that turned up a violation of the same rule sitting in the game's own renderer, where it had been since the board was first built.
The renderer scales every piece of scenery to fit a tile, and to do that it has to know how wide the thing is, so it takes the larger of the model's two horizontal measurements. Someone had added a guard so that a model with no width at all could not be divided by zero. The guard was written in a way that only ever looked at one of the two directions. So a model that genuinely had no footprint — no width and no depth — walked straight past it and was blown up until it filled the sky, silently, instead of being refused.
Nobody had ever hit it, because nothing in the game is shaped like that. Generated models occasionally are: the flat-slab failure the service warns about is exactly this shape, and it would have come in through this side door rather than the front one. It throws now.
A second one was sitting next to it. When that same loader could not find anything usable in a file, it returned nothing at all, and every piece of code calling it answered nothing by drawing nothing. One bad tree and the forest simply was not there — no error, no warning, nothing in the log to search for. That throws now too, which means one bad tree takes the whole board down with it. That is deliberate, and it is the trade this project keeps making: something you can see beats something that quietly is not there.
A castle, assembled from five separate orders
Ask the service for a castle and it gives you a castle: one fused lump of geometry with a single picture painted over the whole of it. It is not a bad castle. It is unusable, for a reason that has nothing to do with how it looks.
On this board you can tell whose city you are looking at because the roofs are painted in that player's colour. The stone stays stone; the cones on top go blue or red or green. It is the only ownership signal a capital has. You cannot paint a roof that is not a separate piece, and a fused lump has no separate pieces.
So a castle is ordered as 5 things instead — a keep, a length of curtain wall, a corner tower, a gatehouse, and a cone roof — which come back as 5 unrelated files and get assembled here. Four runs of wall closing a square, a tower on every corner, the gate breaking the south face, a cone on the keep and one on each tower. 15 pieces, 19,700 triangles, standing 1.10 by 1.15 tiles: a castle occupies one tile of the map, not a district, so the whole thing has to be a keep-sized object rather than a plan view of a fortress.
Every piece's final position is then read back out of the finished file and checked against the layout it was supposed to land in — rather than believed because the tool that placed it did not report an error. That distinction is most of what this chapter has been about.
Then the machine learned to do the thing we had built the machine for
Everything above exists because the service could not attach a skeleton to anything. Ask it for one and it refused outright. That refusal is the entire reason this project owns a rigging stage at all — the whole apparatus of borrowing attachments from an existing model, the pose contradiction, the checker that reads the file instead of the picture, all of it.
Halfway through the week, without warning, the refusal was removed. Nobody had tried it. So it was tried once, on the same soldier, from the same instructions, with the same random seed — everything identical to the model the test above had already threaded onto a skeleton by hand, changing exactly one thing: this time the service was asked to do the threading itself.
It worked. It came back with a skeleton of 34 bones, every point of the surface attached — 0 loose ends — and 3 animations built onto it, including a run cycle this project does not own and has never had. The one previous attempt anyone had recorded stalled at five percent and produced nothing. This one took 4.5 minutes.
And it is useless to us, for a reason that took one number to establish. The game does not simply load a skeleton, it calls its bones by name — every animation is a list of instructions addressed to a bone with a particular name. The service's skeleton shares 0 names with the game's. Not a few, not a different convention that could be mapped across in an afternoon: none of the game's 48 names appear on it anywhere. So a model rigged this way arrives with a second skeleton that has to be translated onto the first before anything can be played on it, which is more work than attaching the game's own skeleton was in the first place, not less.
There is a small joke buried in the offer. Because the service knows a person might want to adjust a joint before the animations are built, it stops and asks — and the joints you are being asked to adjust are named bone_0 through bone_33 at that exact moment — all 34 of them, with nothing anywhere in the file to say which one is the left elbow. The real names only appear in the step it is holding back while it waits for your answer. It was approved without touching anything, because approving edits to a skeleton you cannot read is not a decision, it is a coin toss.
The last number is the one that settles what those animations are. Building three of them across 34 bones took 0.04 seconds, which is not enough time to have invented any motion at all. They are stock cycles, retargeted. Every soldier made this way would walk in exactly the same borrowed way — which is fine, and is somebody else's walk.
None of this makes anything you can look at
There is no new unit on the board at the end of it. What there is instead is a check that would have caught a failure a photograph could not, a tool that stops rather than guesses, two silent failures closed in code that was already shipping, and a written plan that kept losing arguments to its own measurements.
Every quantity on this page was read out of the committed measurements by a script and written into the page, so it cannot drift from the file it came from — a test regenerates it and fails on any difference. The prose around them is written by hand, which is exactly why it can be wrong in ways a test cannot catch.
The next chapter has to be about actual soldiers standing on the actual board, or something has gone wrong.