Crawl of the Forsaken update: melting the monsters, and what Opus 4.8 and Fable actually did

Back when I wrote up how Crawl of the Forsaken got built, the pitch was that every monster is a script, not a model file. No imported meshes, no texture budget, a whole bestiary that streams into a browser tab because each creature is a few kilobytes of code that draws itself. All of that is still true. What changed is how the drawing works, and the new version is a big enough jump that the old monsters look like a different game.

This post is the technical one. If you want to know how a signed distance field becomes a mobile-friendly monster, and where an AI model fits into sculpting 3D characters, read on. There are a lot of pictures.

The old monsters were a bag of parts

The original bestiary was built the honest primitive way. Each creature was a pile of separate meshes: boxes for a snout, capsules for legs, ellipsoids for a belly, cylinders for claws. A little GDScript helper stacked them at roughly the right proportions and painted each one a flat color. It shipped, it worked, and up close it always looked like exactly what it was.

Look at the seam running across the old rat's back where two ellipsoids intersect, or at the legs, plainly capsules that got parked under the body. Nothing connects. The ghoul was worse, because a humanoid made of separated limbs reads as a shop mannequin, and a mannequin is not scary.

None of this was a rigging problem or a talent problem. It is just what you get when a body is a set of solids that happen to overlap. The shapes never agreed to be one shape. So I made them agree.

The melt: one body from many capsules

The new bodies start from the same idea as the old ones, a handful of tapered capsules describing a trunk, a head, some limbs. The difference is what happens next. Instead of drawing each capsule as its own mesh, the whole creature becomes a single signed distance field.

A signed distance field is a function. You hand it a point in space and it tells you how far that point is from the surface, negative inside, positive outside. Each capsule gets a round-cone distance function, which is cheap and exact. The trick is how you combine them. A plain union takes the minimum of the two distances and gives you a hard crease where they meet, which is the seam problem all over again. A smooth minimum blends the two fields over a small radius, so the surface flows from one capsule into the next with a fillet instead of a crack. Run that smooth-union across every capsule in the body and the separate parts fuse into one continuous skin. That is the melt.

This came out of a sister project I keep on the side called Ragdoll Lab, which is a sandbox for procedural creatures, one shared animation system that poses any body: two legs, four legs, six, eight, a hopper with no legs, a flyer with wings. The animator hands the melt system a fresh set of capsule positions every frame, and the smooth-union rebuilds the whole body around whatever pose came in. Legs bend, the jaw drops, the whole thing stays one skin.

To actually see the field you raymarch it. For every pixel you march a ray forward in steps, asking the distance function how far the nearest surface is, jumping that far, and repeating until you hit skin or give up. It looks fantastic and it melts on screen in real time. It is also where the trouble starts.

Why shipping the raymarch was a non-starter

Raymarching a distance field is not cheap. For a single pixel you might evaluate the field ten or twenty times as the ray walks in, and each of those evaluations runs the round-cone math for every capsule in the body and folds them together with smooth-min. A detailed monster carries up to thirty capsules. Multiply that out: thirty distance calls, times twenty steps, times every pixel the creature covers on screen. Now put six monsters on a dungeon floor and hand the whole thing to a phone that also has to run the game.

On a desktop GPU it is fine. On a mid-range phone in a browser tab, which is the whole point of Legitsauce, a floor full of raymarched monsters is how you turn a game into a space heater. The live field is gorgeous for one hero creature or a boss. As the everyday bestiary it does not fit the budget.

So the live melt never ships to players. It is the master I bake the real monsters from.

Baking a distance field into a tiny mesh

Baking means running the expensive process once, offline, and saving the cheap result. For the melt that result is an ordinary triangle mesh, and getting there takes a few steps.

First I extract the surface. I sample the distance field on a 3D grid and run Surface Nets, a dual isosurface method that places one vertex per grid cell that straddles the surface and stitches them into quads. Compared to classic marching cubes it gives a smoother, more even mesh, which is what a blobby melted body wants. The grid resolution is a dial I set per creature, and it trades directly against triangle count. I tune it so each monster lands around 2,500 to 2,900 triangles. There is a hard ceiling of 3,500 wired into the test suite, so a creature that blows the budget fails its test and never reaches the game.

Then I rig it. Every capsule becomes one bone in a flat skeleton, and every vertex gets bound to its nearest four capsules with weights that fall off by distance. Because the bones are the same capsules the animator already drives, the baked mesh moves through exactly the same walk, attack and death poses as the live version. The animation is not baked. Only the shape is. The skinned mesh re-poses every frame from the same procedural animator that drives everything else.

Then comes the part that makes it look like a real game instead of a smooth grey blob: I paint the detail into the vertices. At bake time, for every vertex, I compute a handful of things a texture artist would normally hand-paint into a skin, and store them in the vertex colors.

• Ambient occlusion, darkened toward a tinted shadow color rather than flat black, so crevices read as bruised shadow instead of dead pixels.
• A mottled hide pattern from a couple of octaves of value noise, the low-poly stand-in for a painted texture.
• Grime, ground into the underside near the floor and onto thin features like paws and tail tips, where painted skins always go dark.
• Per-vertex roughness, packed into the color's alpha channel, so wet bellies catch a specular glint and dry fur stays matte.

Finally I render it with a proper lit shader, a wrapped-lambert diffuse with a GGX specular highlight, so the dungeon's real torch light and cast shadows do the work. The old flat-shaded monsters ignored scene lighting entirely. The baked ones sit in the light. That single change, letting the torch actually fall on the creature and letting it throw a shadow, is most of why the new bestiary feels grounded and the old one floated.

The performance math, plainly

Everything above is built around one trade.

The live raymarch gives you infinite variation and on-screen melting, and costs you a heavy per-pixel loop that scales with how much screen the monster covers. Great for one elite. Ruinous for a crowd on a phone.

The baked mesh gives you a plain skinned model of about 2,700 triangles that lights and shadows like any other mesh, with all the surface detail carried in vertex colors so there is no texture memory to load and no per-pixel field math to run. The saved file for one creature is a 70 to 80 kilobyte resource. A whole floor of them costs about what a floor of the old primitive monsters cost, except now they look melted and lit instead of assembled and flat.

What you give up is the live melting. A baked mesh cannot re-blend its own body, so a violent death pose that flings the limbs out will stretch and pinch the skinning in ugly ways. I handle that by freezing the last good pose at the moment of death and toppling the whole creature rigidly, a quadruped rolling onto its flank, a biped falling backward onto the floor. It reads cleanly as a body going down, and it dodges the one thing skinning is bad at. The worms are the exception, since their death is a low flat flop that skins fine, so they keep animating right through it.

What Opus 4.8 and Fable actually did

Here is the part people ask about, so I will be specific rather than mystical.

None of this pipeline was hand-modeled. A creature is defined in GDScript: a function that lists its capsules and proportions, a block of paint parameters (shadow color, mottle amount, grime, roughness, eye glow), and a bake resolution. The loop to build one goes: write those numbers, bake, render the result from four angles on the dungeon stage under the real lights, look at the renders, adjust the numbers, bake again. It is the same write-render-look-fix loop I described in the first post, just aimed at a distance field now instead of a stack of primitives.

That loop is where the models earn their keep. The heavy architectural work went to Claude Opus 4.8: porting the distance field to the CPU for baking, building the Surface Nets extractor, designing the vertex-paint pass. That work is long-horizon and unforgiving. A sign error in the surface normals turns the whole mesh inside out. A wrong winding rule punches holes in thin features. Getting the baker correct took the kind of careful, many-step reasoning Opus is built for. Fable, which is fast, carried the tight iteration: re-tune a palette, nudge the ear capsules, re-bake, pull the four renders, decide if the rat's snout got better or worse. Dozens of those turns an hour.

The new trick is that the model reads its own renders. It bakes a monster, looks at the four-angle screenshots, sees that the eyes are floating a centimeter off the melted surface, and fixes the projection that places them. It notices the ghoul's death topple is clipping through the floor and adds the lift that rests it on the ground. That is a real feedback loop on 3D character work, driven off images the model produced and then judged.

I want to be careful about the credit, though. The model does the volume and the mechanics. The taste is still a human sitting there deciding that the rat's new nose is too bright and blows out under the cool fill light, or that the ghoul reads as a corpse from three angles but a lumpy potato from the fourth. The gap between a technically correct bake and a monster you would put in a game is judgment, and judgment is the part I have not handed over. What the models changed is how many swings I get at it. When each iteration is minutes instead of an afternoon, you can afford to be picky.

New shapes fall out for free

Because the melt and the animator are general, adding a body type that the old primitive pipeline never had is cheap. The newest resident of the dungeon is a bouncing grave maggot, built on a segment-chain worm gait: it scrunches up, springs forward through a little ballistic hop, rears back cobra-style to strike, and flops flat when it dies.

A ring-banded grub with no hard edges is exactly the kind of thing the smooth-union does well and separated primitives do badly. It is under 2,700 triangles, it lights and shadows like everything else, and the same animator that walks the rat and shambles the ghoul gives it a completely different way of moving without a single new line of animation code.

What still looks off

Now the honest part, because a devlog that only shows the flattering angles is an ad.

Look closely at the new rat and you will notice it barely has feet. The old one had stubby capsule paws with pale toes; the new one walks on tapered stumps. The bake ate them. At this triangle budget the sampling grid's cells are about three centimeters across, and any feature smaller than a cell either fuses into its neighbor or drops out entirely. The melt makes it worse, since a small foot capsule sitting close to a leg gets absorbed by the smooth-union before the mesher ever sees it. The fix is straightforward, fatter foot capsules and a touch more contrast where the paw meets the floor, and it is on the list.

The ghoul also drifted. The old one was a yellowed skeleton with mesh ribs and a loincloth. The new one is a smoother, greener corpse. Some of that was a choice: the rib meshes floated visibly above the melted skin, so they got retired, and the silhouette now has to carry the corpse read on its own. Some of it is the medium, because a smooth-union pulls every design toward soft, and fighting the blob is most of the sculpting work. I think the new ghoul is scarier, but it is fair to call it a slightly different creature rather than a faithful remaster of the old design.

I am comfortable shipping both flaws in an update post, because the trend line is the point. Every pass through the loop comes out looking better and more real than the one before it, and the loop is cheap enough now that another pass is always affordable. The rat will get its feet back.

Where it stands

The rat, the ghoul and the maggot are converted and in the game. The rest of the bestiary, another forty-odd monsters plus the player heroes, is next, a few at a time, each one held up against the old version until it clearly wins. Everything is verified the boring way: every creature ships with a triangle-budget test, both test suites stay green, and every visual change gets its four-angle renders looked at before it lands.

If you played the earlier build, the monsters you fought are the ones on the left of those comparison shots. The ones on the right are what is coming. The demo is live and free in the browser, same as everything else on the site. Go see the rat before it eats you.