AI-Assisted Game Dev · Asset Reverse-Engineering Series, Part 4 · Scene Ecology
Intro: The Ground Is Laid — Now, What Goes On Top?
This is the companion follow-up to the terrain article. That article covered “how a planet’s ground comes to be” — how terrain tiles are cut, how biome surface materials are procedurally colored, how height is generated in discrete steps. It ended with a planet whose ground is laid, but bare. This article picks up from there: what should grow on this ground, and what should be built on it.
With the ground laid, open a level and look closely — and one thing stands out: it looks more like “a plot with correct terrain” than “a living planet.”
A real planet isn’t bare ground. A forest should look like a forest — tall trees in stands, shrubs filling gaps, grass carpeting the floor, layered clearly; a colony should look like a colony — main structures standing, walls enclosing, crates scattered by the door. That “it just looks right” feeling doesn’t come from the terrain itself, but from the rules of filling: what grows where, how it layers, at what density.
And once you realize this game has over four hundred planets, it becomes clear this layer of filling can essentially only be procedural. Four hundred planets, each to be carpeted with vegetation and dotted with settlements — placing all of that by hand would be hundreds of person-months of work, and unmaintainable afterward: change one tree’s model, and you’d have to go back through four hundred maps replacing it one by one. At this scale, almost no team would take the manual route. The realistic approach is to abstract “how to fill” into a set of rules and let the machine fill by those rules. What the artists produce isn’t “four hundred maps” but “a vegetation/building library + a set of filling rules”; the four hundred planets are that rule set run with four hundred random seeds. What this article reconstructs is exactly that rule set — it’s one of the key reasons this kind of open world can sustain a vast number of planets on limited manpower.
This article is about that layer of rules. And we’ll find that this filling layer and the terrain generation from the terrain article are continuations of the same idea — both are “rules + inventory + seed” assembly: given a set of rules, an asset inventory, and a random seed, assemble the plot that should be there. The terrain article uses it to generate the “ground”; this one uses it to fill in the “things.”
Concretely, for “filling things,” this game uses two parallel filling systems:
- The natural side — driven by ecological biome (the very same biome that decides surface material in the terrain article), placing vegetation;
- The artificial side — driven by faction + module kit, assembling buildings.
The two systems each govern half the world, yet follow the same idea. Explain both thoroughly, and — together with the terrain generation from the terrain article — you complete the full picture of how this kind of open world “assembles a planet from scratch.”
1. The Divide Between the Two Filling Systems
Let’s set the skeleton first. Lay the two systems side by side and you’ll find they present a strikingly symmetric structure at the analysis level (this is the symmetry we saw after classifying — not necessarily a symmetry the original designers intended, but as a framework for understanding and reproduction, this symmetry is very useful):
| Dimension | Natural side (vegetation) | Artificial side (buildings) |
|---|---|---|
| Driving logic | biome | faction + module kit |
| Asset scale | 258 kinds | 732 pieces |
| Core layer | primary vegetation (tall trees) 81 | core structures (building bodies) 393 |
| Accessory layer | shrubs 37 | accessory props (crates/tanks) 174 |
| Base/boundary layer | understory ground cover (grass-fern) | walls / railings / boundary 165 |
| Grouping dimension | which biome a planet belongs to | which faction a building belongs to |
This table is the crux of the whole article. Both sides are a three-layer structure of “core + accessory + boundary” — nature’s tall trees/shrubs/ground cover map to the artificial world’s main buildings/props/walls. The filling system doesn’t care “is this a tree or a building”; what it cares about is the layer role: who’s the skeleton, who fills the gaps, who marks the boundary.
Once you grasp this symmetry, the next two chapters are really “the same method, applied to two kinds of assets.”
2. The Natural Side: Placing Vegetation by Biome
Planet → Biome → Vegetation List
The first question: which planet should grow what vegetation?
This game’s planets aren’t hand-authored maps but assembled from “templates + seeds.” Each planet carries a terrain template, and the template name spells out which biome it belongs to. Follow this thread, and you can string together “planet → biome → vegetation.”
Take two highly recognizable planets (using their community nicknames):
- A “Hellmire”-type planet, terrain template “arid forest tundra,” lands in the forest biome — its vegetation list has 49 kinds, all forest-type: tall trees, alien landmark trees, pines, redwoods, full sets of shrubs.
- A “blood-jungle”-type planet, terrain template “blue primordial jungle,” lands in the swamp/primordial biome — 36 kinds of vegetation, an entirely different batch: withered alien giant trees, large/medium/small primordial shrubs.
These two planets’ vegetation lists barely overlap. That’s the meaning of biome-driven filling — swap a template, and the whole set of vegetation swaps. Meanwhile, another planet also carrying the “primordial jungle” template (the Terminid-leaning one) has a vegetation set highly consistent with “blood-jungle,” proving the rule “template determines the vegetation set” holds.
Fan it out further, and the rule gets clearer. Pick one representative per biome:
| Planet (community nickname) | Terrain template | Biome | Vegetation count |
|---|---|---|---|
| Hellmire-type | arid forest tundra | forest | 49 |
| blood-jungle-type | blue primordial jungle | swamp / primordial | 36 |
| moor-bog-type | tundra swamp | moor | 49 |
| wet-swamp-type | standard swamp | swamp | 36 |
Look at this table and one thing stands out: what determines the vegetation list isn’t “what the planet is called,” it’s “which terrain template it carries.” Forest-biome planets share one forest vegetation set, swamp-biome ones share a swamp set — the planet name is just a label, the template is the key. This is also why, when tagging later, we trust the “template name” over the “planet type field” (more on that pitfall below).
Extend this rule across all four-hundred-plus planets, and you see a very tidy picture: a few dozen terrain templates, each corresponding to one fixed vegetation set; the four-hundred-plus planets are those few dozen vegetation sets reused over and over. No planet has “exclusive vegetation” — they all draw the same batch of assets from the biome library, and re-scatter with a different seed. This also explains how the game can have a vast number of planets without blowing up asset count: planets are cheap combinations, vegetation is shared inventory.
Here’s a pitfall we hit along the way, worth noting: the planet data actually has a “planet type” field, and the most intuitive move is to read it directly to determine the biome. But in testing this field is systematically misaligned (what should be biome A reads as B), and judging by it gets whole batches wrong. In the end we switched to judging by “terrain template name + region name” to get it right. Once again, the most conspicuous field is the untrustworthy one.
Symbiosis Layers: Primary Trees, Companion Shrubs, Ground Cover
A list alone isn’t enough; you also need to know how they layer. This layer of info — the original distribution rules — is encrypted and unobtainable; but you can infer it from “which vegetation always appears together in the same cell” — what always appears together is an ecological symbiotic combination.
The statistics make the symbiosis clear:
- Fern clusters: a certain grass-fern always pairs with another fern (co-occurring in 18 cells) — a fixed pairing at the ground-cover layer;
- Shrubs in pairs: two variants of a forest shrub kit almost never appear alone (14 cells) — the mid-layer gap-filler;
- Pine-shrub pairs: two shrub forms of the tundra pine are bound together (11 cells).
Group these combinations by naming semantics, and you get a three-layer structure: primary vegetation (including landmark tall trees) 81 kinds / shrub layer 37 kinds / understory ground cover. This is the layering to follow when reconstructing a forest in-engine — first drop the primary trees to set the skeleton, then scatter shrubs to fill the mid-layer, finally lay ground cover to seal the base.
The co-occurrence data hides an even finer phenomenon worth calling out. Ordinary forest tall trees have companions that are uniformly forest shrubs — forest_hero_tree_01 is always surrounded by forest shrub kits. But those few alien landmark trees (alien_hero_tree) are different: their companions include withered shrubs from the primordial biome. In other words, landmark trees borrow accessory vegetation across biomes — an alien giant tree in a forest is footed not with ordinary forest shrubs but with withered shrubs borrowed from the primordial/swamp biome, to accentuate its “alien, jarring” landmark presence. This detail can’t be seen from the asset list; it only surfaces when you compute “who’s always with whom.” It also reminds us: layering isn’t a rigid “forest trees only pair with forest shrubs” — the symbiosis rules themselves carry artistic intent.
A word on how weights are set. Each vegetation’s “spawn weight” isn’t a subjective choice but inferred from naming level + occurrence frequency: landmark tall trees have the highest weight (0.9, because they’re the visual focus and should be few and prominent), ordinary primary trees 0.8, shrubs 0.5, ground cover 1.0 (most numerous, highest density). These weights feed directly into the engine’s distribution density — high-weight ones placed sparsely, low-weight ones (ground cover) carpeted.
Tagging and Weights
Finally, tag all 258 vegetation kinds one by one for batch engine configuration. Named trees (118 kinds) get their biome judged directly by name; unnamed ones (140 kinds) get their biome inferred from the cells they appear in.
Here’s a detail worth noting: names lie. One tree has “forest” in its name and by name should belong to the forest biome; but look at the cells it actually appears in, and they’re all “Super Earth city” environments — it’s actually urban landscaping, not wild forest. “Where it actually appears” corrected “what it’s called.” On this point, a name-only approach would be entirely wrong; cell co-occurrence is what gets it right.
3. The Artificial Side: Assembling Buildings by Faction + Module
Now switch to the artificial side. The method transfers over completely; only the driving dimension changes from “biome” to “faction.”
Building → Faction Mapping
Buildings are inherently easier to classify than vegetation — their names carry a faction prefix. Split the 732 building assets by prefix:
- Super Earth (human): 457 pieces, the bulk — habs, colony buildings, crates, railings, a full human outpost;
- Cyborg / mechanical faction: 114 pieces — containers, breaching batteries, barriers;
- Illuminate faction: 71 pieces;
- Terminid: 27 pieces — not “buildings” but hive walls, cave bridges, rock walls;
- No prefix: 61 pieces, inferred from cells.
Faction is to buildings as biome is to vegetation — it determines what this artificial settlement should look like. A human colony is boxy habs; Terminid “buildings” are organic hive walls.
Assembly Layers: Core, Accessory, Wall
Corresponding exactly to vegetation’s three layers, buildings also split into three:
- Core structures 393 pieces — habs, towers, bunkers, colony buildings, bridges, the settlement’s skeleton;
- Walls / boundary 165 pieces — walls, fences, railings, pillars, gates, enclosing the settlement’s extent;
- Accessory / props 174 pieces — crates, tanks, pipes, barricades, the fill scattered around the core.
The Settlement’s Fixed Combinations
The most interesting part is building co-occurrence — it reveals the standard configuration of “a human outpost.” Tally which buildings always appear in the same cell, and the top entries are almost all crate combinations:
- Small crate + medium crate: co-occur in 203 cells;
- Large crate + small crate: 197;
- Large crate + medium crate: 166;
- Small crate + fence: 139;
- Small crate + railing: 137;
- Crate + groundplate, crate + flagpole: around 120 each.
This is the “human outpost” recipe — several crates of different sizes clustered, a groundplate laid down, fences and railings ringing the perimeter, a flagpole planted. Its consistency is the same thing as vegetation’s “fern clusters always in pairs”: not random scatter, but a module combination with pairing rules. Read this co-occurrence ranking top to bottom, and you can practically read the build order of a human supply point — first lay the ground, stack the crates, ring the fences, plant the flag.
Take this recipe apart, and its structure is strikingly like a real-world temporary camp: the core is supplies (crates), the outer ring is boundary (fences and railings), the middle leaves room to pass. This isn’t casual artist placement; it’s a “settlement template” reused over and over — just as vegetation’s “terrain template determines vegetation set,” buildings have “settlement template determines module combination.” The same crate-and-fence recipe, moved, reoriented, with modules added or removed, generates hundreds of human outposts that look all different yet are all the same source.
And reading further down the ranking, there’s a second kind of human settlement hiding: trench wall + pillar (132 cells). This one is completely different from the crate outpost — it’s a trench fortification, wall segments joined by pillars into a defensive line. In other words, the human faction actually has two settlement logics: the “supply outpost” on open ground (crates + fencing) and the “trench fortification” along defensive belts (walls + pillars). The co-occurrence data exposes the fixed recipe of each — they have their own module kits, their own pairing rules, yet both are products of the same “settlement template” idea.
Different factions’ “settlement logic” also differs completely, readable straight from the asset structure. The human faction’s 457 pieces are dominated by habs, crates, railings — a “modular assembly” mindset, boxy prefabs assembled like building blocks. The Terminid’s 27 pieces have almost nothing “building”-like, all hive walls, cave bridges, rock walls — an “organic growth” mindset, no assemblable modules, only continuous biological structures. Faction decides not just what it looks like, but “how it’s organized”: humans assemble, Terminids grow. This is exactly where “faction-driven filling” is more essential than “classifying by visual style” — it grasps the generation logic, not the appearance.
4. The Two Systems’ Shared Boundary
By now, both systems’ capabilities and limits are exposed. And their boundary is the same line.
Both can fill locally correctly. Given a forest planet, you can list its due vegetation, layer it, tag it; given a human settlement, you can identify its faction, break out core/wall/accessory, recognize the crate-outpost recipe. Locally, it’s right.
But neither can assemble “a complete planet.” Because the final link — “this region of this specific planet: which exact batch of cells, at what density, with what random seed, placed how” — this precise distribution rule is locked by encryption on both sides:
- Natural side: “which tree grows only on this specific map” is unobtainable — only down to the biome granularity of “forest planets use forest vegetation”;
- Artificial side: “by what rule this settlement assembles these modules” is unobtainable — only down to the faction granularity of “the human faction uses this crate-and-wall set.”
This isn’t a shortfall of method; it’s a ceiling set by data structure + encryption. And — this wall is the same one the terrain article hit. The terrain article can reconstruct terrain generation rules (how to cut tiles, how to color, how many height steps), but can’t get “which seed this specific planet used, exactly how it turned out”; the filling article can reconstruct filling rules (what a biome grows, what a faction assembles), but can’t get “what exactly this specific region places, at what density.” Both, walking to their own ends, find the end is the same encryption wall: reconstructible down to “rules + inventory,” not reconstructible down to “that one specific assembly’s seed and arrangement.”
This is in fact the same conclusion this reverse-engineering work keeps hitting — from terrain to geometric placement to ecological filling, it recurs all the way: rules are reversible; the precise arrangement of a specific instance is not. Reconstructible down to biome/faction-granularity filling rules; beyond that is a black box.
5. Reconstructing In-Engine
With these two datasets, configuring in-engine has a basis to work from — and this is exactly the layer that should be done “after bringing the assets in,” yet often nobody does.
Vegetation side: take the biome tags + symbiosis layers + weights, and configure the engine’s vegetation distribution system (Foliage / PCG). Concretely — build one vegetation group per biome, and within it set different distribution parameters per layer: landmark tall trees get the lowest density and the largest minimum spacing (ensuring “few and prominent”), ordinary primary trees medium density, the shrub layer spawns following primary trees (using symbiosis data to set “only spawn this shrub within a certain radius of a primary tree”), ground cover at the highest density carpeting the surface. Weights convert directly to distribution density, co-occurrence relations convert to “companion spawn rules.” A forest spawned this way has layering and pairings that match the original, rather than a uniformly-scattered single-tree “lawn.”
Building side: take the faction tags + assembly layers, and organize the modular buildings into reusable prefab units. Human settlements become individual “outpost prefabs” — core structures at the base, crates grouped in by the co-occurrence recipe, walls ringing the boundary; the whole prefab gets a faction tag, instanced and reoriented as a group when needed. Terminid organic structures don’t go through assembly — laid directly as whole terrain assets. The key is to make “the settlement” a reusable unit, rather than placing hundreds of crates one by one.
Neither side is “placing assets one by one” but “giving the engine a set of rules + an inventory, and letting it fill by itself” — that’s the true intent of procedural filling, and the real use of these two reverse-engineered datasets.
Worth stressing: this layer is precisely the most-overlooked, most-valuable step of “asset reverse engineering.” Earlier parts extracted assets from the binary, imported them into the engine, and put them back in position — do all that, and you’re holding a pile of “correct parts.” But parts don’t grow into a world on their own. What actually turns an empty plot into “instantly recognizable as which kind of planet” is this set of filling rules. The endpoint of reverse engineering isn’t “getting the assets,” but “getting the method to organize assets into a world.”
6. Landing in UE5: How the Filling System Actually Runs
The preceding was “principle” — give the engine a set of rules and an inventory, and let it fill itself. This section is “engineering”: to actually run these two filling systems in UE5, how should it be built? (Finer algorithm derivations, parameter calibration, and showcase are left to the companion implementation piece; this section makes the skeleton and each step’s key decisions clear.)
The implementation shares the same overarching principle as the terrain article’s implementation, which must be established first: authoritative computation is entirely on the CPU, the same seed produces identical results across all clients, and the GPU only renders. The terrain article designs the heightfield as an (x, y, seed) pure function — the heightmap, mesh, and collision are all just samples of that function cached at different resolutions. The filling article follows the same path: making “what grows and gets built where” also a deterministic function of the seed. Why insist on this? Because this kind of game is multiplayer — if vegetation and buildings relied on the engine’s built-in random scatter, each client would scatter to different positions, and you’d have to sync the coordinates of tens of thousands of trees to all clients, and network overhead would balloon; whereas CPU pure function + one shared seed means each client computes independently and, ideally, gets identical results, syncing only a single integer seed. This isn’t over-engineering, it’s a hard constraint of multiplayer.
However, “determinism” isn’t free in engineering — to truly get bit-for-bit agreement across clients, two real problems must be handled: one is floating-point error (float operations may differ slightly across CPUs/compilers/optimization levels, and a hair’s difference in sample points cascades and amplifies) — in practice you either lock down float behavior or use fixed-point / integerized hash sampling on critical paths; the other is instancing-order consistency (for the same point set, if the traversal/generation order differs across clients, the random-stream consumption order breaks) — you must ensure the seed-driven iteration order is strictly identical across clients. These are the real details to gnaw on when “deterministic scatter” goes from an architecture description to a shippable engineering solution — this article only flags their existence; the handling is left to the implementation piece.
6.1 First, Take the “Ground” the Terrain Article Outputs
The first step of filling isn’t placing assets, but reading the terrain. The terrain article, during the loading phase, has already computed this planet’s terrain, and — this is the key to the handoff — it has also marked the semantic zoning: where is gentle slope (dense forest can grow), where is cliff (only sparse vegetation clings, or nothing grows), where is a flattened base (put buildings, clear vegetation), where is road (scatter on both sides, clear the surface).
The filling layer doesn’t re-judge the terrain; it reads this zoning directly. This is the practical meaning of “part-to-part handoff” in engineering: the terrain article’s output isn’t just a heightmap, but also a “what type should grow where” semantic map. Filling scatters by it, and so won’t plant trees on cliffs or pile crates in the middle of roads. Here the two parts truly interlock into one pipeline — terrain handles “what the ground looks like + what each patch’s nature is,” filling handles “placing things by nature on top.”
6.2 Vegetation Side: Biome-Driven Deterministic Scatter
First, solidify the three reverse-engineered tables (planet→biome vegetation list, symbiosis layers, tagging weights) into a biome vegetation config data asset. One record per biome, listing its three-layer vegetation, each with a density weight, plus symbiosis rules. This config needs no manual filling — it’s the direct product of the preceding sections’ reverse-engineered data: the weight 0.9 landmark trees, 0.8 primary trees, 0.5 shrubs, 1.0 ground cover — these tiers were statistically derived from naming level plus occurrence frequency.
The scatter splits into three layers, all computed by the CPU by seed during the loading phase:
- Primary vegetation — do Poisson-disk sampling within the “gentle-slope zone where trees can grow.” Poisson-disk means “when scattering points, guarantee any two points are no closer than some minimum spacing” — abstract as a concept, but very intuitive in effect: the trees generated won’t clump into clusters, but spread out evenly and naturally. Landmark tall trees use a larger minimum spacing and lower density, so they naturally read as “few and prominent,” fitting their role as visual focus.
- Shrub layer — this is the step that best shows “symbiosis data is useful.” Shrubs are not scattered independently, but spawned following primary trees: after computing the primary trees, do a secondary sampling within a certain radius of each primary tree, using the companion species specified by the symbiosis table. This “companion species” isn’t a subjective guess — in the reverse-engineered data,
forest_hero_tree_01‘s top three co-occurrence partners are exactlyforest_bush_set_01_01(co-occurring in 7 cells) and other forest shrubs; the config just fills that in. A forest spawned this way naturally has the “shrubs under trees” layering, rather than “a layer of trees and a layer of shrubs” each scattered separately and unrelated. Here, co-occurrence statistics turn from “an analysis table” into “a spawn rule.”
- Ground cover — carpet the surface at the highest density, but avoid roads and flattened base zones.
The render stage hands off to UE5’s Foliage / PCG for instancing (the GPU efficiently draws vast grass and trees). But draw one line: the authoritative source of positions is the point set the CPU computed, not random nodes in a PCG graph. PCG’s built-in randomness doesn’t guarantee cross-client consistency, and can only be used for “visual enhancement of already-fixed positions” (like per-tree random micro-scale, micro-rotation — jitter that doesn’t affect gameplay); deciding “where this tree is” must be the CPU.
6.3 Building Side: Faction-Driven Settlement Prefabs
The landing unit on the building side is a size larger than vegetation — not “a single crate,” but “a whole settlement.”
Solidify “faction→building layers” and “outpost recipes” into a settlement prefab library. One set of prefabs per faction: the human “crate outpost” is assembled by the reverse-engineered co-occurrence recipe — core structures at the base, then group in accessories and boundary by real recipes like small crate + medium crate (203 cells), crate + fence (139 cells). This isn’t arbitrary placement of a few boxes; it’s solidifying “the combination that always appears together in the original” into a reusable unit.
When placing, in the terrain’s “flattened base zone,” pick a faction, pick a prefab, position it, rotate it by seed, then instance the whole group. Human settlements go through this prefab assembly; the Terminid’s 27 organic structures don’t fit this approach (they have no assemblable modules, they’re continuous hive walls) — laid directly as whole terrain assets. “The settlement as the minimum placement unit” balances efficiency and realism: instancing a whole group at once is far more efficient than placing hundreds of crates by hand; and it comes out naturally “as a set,” because the combination itself was extracted from the original’s co-occurrence.
6.4 The Two Fillings Share One Loading Pipeline With Terrain
Finally, lay out the three steps’ timing. During loading, terrain bakes the heightfield and marks the semantic zoning; vegetation and buildings then, within the same loading phase, read the zoning, compute the scatter, place the settlements. The three are adjacent stages on the same pipeline, sharing the same seed, the same zoning data, the same “CPU-authoritative” overarching principle. With the seed fixed, this planet’s terrain, vegetation, and buildings are all determined, and — ideally — bit-for-bit identical across every client.
This approach is worth designing this way, rather than for-convenience adopting PCG random scatter or hand-building a few template levels — for just two reasons, but both are hard:
- Cross-client consistency — CPU pure function + seed guarantees the world each client computes agrees down to every single tree and every single crate; PCG random and hand-placement both can’t do deterministic replay. For multiplayer, this is the foundation, not an optional optimization.
- Ecological realism — random scatter gives a “uniform lawn,” visually false; whereas biome config + symbiosis-following spawn gives a layered ecology of “trees in stands, shrubs by trees, ground cover sealing the base,” matching the original. Realism doesn’t come from piling on more assets, but from the layering and symbiosis within the filling rules.
This section is the landing skeleton and key decisions. The full form of the scatter algorithm, the parameter values (specific calibration of density / minimum spacing / symbiosis radius), showcase screenshots, and cross-client-consistency measurements are left to the companion filling implementation piece (symmetric to the terrain article’s “Complete UE5 Implementation”). What’s fixed here is the skeleton: CPU deterministic scatter, biome/faction driving, sharing one loading bake pipeline with the terrain article.
7. A Few Transferable Methods: Not Just for This One Game
Extract the experience of this article (together with earlier parts), and a few methods apply not just to this one game, but to reverse-engineering any “procedurally assembled world.”
One: names are untrustworthy metadata; correct them by “where it actually appears.” This lesson recurs throughout the series — last part it was “material names lie” (a material called Billboard is actually used on the body), this part it’s “vegetation names lie” (a tree named “forest” is actually urban landscaping). The pattern is the same: an asset’s naming is a label for artists, not a classification basis for reverse-engineers. Naming may carry over from an old asset, may be a copy-paste someone forgot to change, may just be habit. The truly reliable classification signal is “which scenes this asset actually appears in” — correct naming with co-occurrence and context, and almost every time you recover a batch of pieces the name led astray.
Two: rules you can’t get can be inferred by “co-occurrence statistics.” The original distribution/generation rules are often encrypted and unobtainable. But “which things always appear together” is a statistic you can compute from the scene data you already have — and it precisely approximates that unobtainable rule. Vegetation’s symbiosis layers and buildings’ outpost recipes weren’t read from the original rules but inferred from “who’s always with whom.” When you can’t get the “recipe,” go tally the “products” — the combinations that stably recur in the products are the projection of the recipe. Here a boundary must be stated clearly: all “symbiosis layers” and “outpost recipes” in this article are structural inferences based on cell co-occurrence, a statistical description of the generated results, not the underlying generation algorithm itself. What we reconstruct is “the stable pairings that appear in the products,” not “what rule the original used to generate these pairings” — the latter is still behind that encryption wall. This distinction matters: it means these conclusions are “usable to reproduce similar effects in your own engine” but “do not constitute an assertion about the original algorithm.”
Three: distinguish “rules reversible” from “instances irreversible”; don’t overstate. This is the wall this part (and the terrain article) both hit: reconstructible down to the rule “forest planets use forest vegetation,” not reconstructible down to the instance “which seed this specific planet used, exactly how it turned out.” This line must be drawn honestly — if you can do biome/faction granularity, say biome/faction granularity, not vaguely “fully reconstructed.” The mistake reverse engineering most easily makes isn’t a shortfall of capability, but inflating “reconstructed the rules” into “reconstructed everything.” Admit the boundary, and the conclusion holds.
Four: worlds are “assembled”; the goal of reverse engineering is to get the “assembly blueprint.” Looking from terrain to vegetation to buildings, the common foundation of this kind of open world is: content isn’t hand-made, it’s assembled from “rule library + combination + seed.” Then the endpoint of reverse engineering shouldn’t stop at “how many assets I got,” but should push to “I got this assembly blueprint” — which are the reusable layers, driven by what dimension, combined by what rules. Get the assembly blueprint, and only then can you talk about reproducing the same “doing more with less” in your own engine.
These four are the general methods this reverse-engineering work has settled out, far more useful than “which trees this game has.”
8. Conclusion: Together With the Terrain Article, It’s One Planet
Sum this article up in one line: the terrain article makes the ground grow, this one makes what’s on the ground look like what that planet should be.
The two together are exactly the complete assembly line of a procedural planet:
- Terrain article — uses “rules + inventory + seed” to generate the ground: cutting tiles, coloring, setting height;
- This article — uses the same idea to fill the things: natural side placing vegetation by biome, artificial side assembling buildings by faction.
The same “rules + inventory + seed” idea runs through the whole process from ground to things. And both, walking to the end, stop before the same encryption wall — reconstructible down to “rules + inventory,” not reconstructible down to “that one specific assembly.”
For those wanting to build an open world, what’s truly transferable isn’t “which trees, which buildings this game has,” but this skeleton of the assembly idea: a world isn’t hand-built, it’s assembled from “rule library + combination + seed”; the ground comes this way, the things are filled this way too; break content into reusable layers (terrain’s height steps / filling’s core·accessory·boundary), drive it by one grouping dimension (biome / faction), and fix combinations by co-occurrence rules. However many planets, it’s just the same rule library reassembled. Understand this skeleton, and you understand how this kind of game “assembles an endless world from limited assets.”
9. AI Collaboration Retro
This is the series’ fixed section: a record of how human and AI specifically collaborated on this part, where things went off the rails, and how the human recovered.
Where AI helped:
- The symmetry of the two systems was “run out of the data.” At first it was just analyzing vegetation and buildings separately; it was when laying the two sides’ layer distributions side by side that the structural symmetry of “core 81/393, accessory 37/174, boundary —/165” surfaced — this crux of “the two filling systems are isomorphic” wasn’t thought of first and then verified; it was run out as data first, then the concept seen from the data. AI, on “batch classification + statistical comparison,” can compute out hidden structure.
- The building analysis is a transfer of the vegetation method. After finishing vegetation’s req1/2/3 (planet mapping / symbiosis layers / tags), buildings came out almost by taking the same set of scripts and swapping the driving dimension (biome→faction). Reusing a verified method, AI transfers fast.
Off-the-rails and human recovery:
- “Combine or split” was the human pinning the direction. AI at first defaulted to “vegetation as its own article”; it was the human asking “would splitting into two leave insufficient material” that forced out the better structure “the two systems are isomorphic — combining is actually more substantial.” AI tends to push forward along inertia; one counter-question from the human can lift the topic a level.
- “Names lie” proved out again. That tree “named forest but actually urban landscaping” in vegetation, and last part’s “material name misleading,” are the same kind of pitfall — in this game, names are untrustworthy metadata, to be corrected by “where it actually appears / what the actual geometry is.” This lesson recurring across parts shows it’s a general rule of this reverse-engineering work, not a one-off.
- Degradations must be honestly marked, not glossed over. “The corresponding planet is at biome granularity,” “building assembly rules are encrypted and unobtainable” — these are the boundaries of capability, and AI has a tendency to “state things at full confidence”; the human must watch and mark each degradation clearly as “what can be given, what can’t be gotten,” rather than vaguely saying “done.”
How it was resolved: make “run the data first, then propose the concept” the default cadence (no drawing conclusions first), hand the topic direction to the human in the loop to calibrate, and bind each capability boundary to an explicit “can/can’t” statement. This whole setup is what let the concept of “two filling systems” have both real data support and no exaggeration.
*All figures are self-drawn infographics (white background, corresponding line-by-line with the body). The vegetation/building layering, mapping, and co-occurrence data in the text all come from per-piece counting and cell co-occurrence measurement; anywhere involving “precise distribution rules,” it is encrypted and un-reversed, explicitly marked as biome/faction granularity, with no unfounded inference.*