Everything else in the codex describes what the shipped game is. This page guesses at how it was made. We have no access to FromSoftware's tools, source files or staff. What we have is the shipped data: its names, numbering, leftovers and structure, plus one measurement made for this page. Each claim says what it rests on, and the last section rates how sure we are. Read it as an informed reconstruction, not as fact.
1The toolbox, as the files hint at it
Every file format points to the tool that wrote it. Most of the engine is licensed middleware glued together by FromSoftware's own editors:
| Job | Probable tool | What in the files points to it |
|---|---|---|
| Modelling art and collision | A commercial 3D package, used in Japanese | FLVER models with material names and dummy-poly nodes; hit meshes named after art models (m005590_hh); default object names in Japanese (オブジェクト9875), saved in Shift-JIS |
| Physics export | Havok Content Tools (2014.1) | Every collision, ragdoll, cloth, skeleton and animation is a Havok 2014 packfile; FromSoft's own subclasses (fsnpCustomParamCompressedMeshShape) carry per-triangle game data |
| Laying out maps | An in-house editor, probably called MapStudio | Layouts live in map/mapstudio/*.msb; region names are Japanese working notes (霧 室内 10×10, "fog, indoor, 10×10") |
| Rules and numbers | A param editor over spreadsheet-like tables | 103 typed tables, with rows numbered by schemes (below); the draw params carry a Japanese comment on every variant ("MAP main", "Fire Keeper") |
| Animation timing | A TimeAct editor | .tae: per clip, hundreds of timed events, most of them flags a designer toggles on a timeline |
| Character state | Havok Behavior Tool + Havok Script | .behbnd graphs (with FromSoft's own node types) and Lua-based .hks state scripts |
| Enemy AI | Plain Lua 5.0, with C++ goals | aicommon.luabnd (shared goals) + one battle file per enemy type |
| Story and level logic | An event-script editor; "EzState" talk scripts | .emevd instruction lists; .esd state machines for bonfires and NPCs |
| Lighting | An offline GI baker in their pipeline | Lightmaps with a dominant direction ("DominantLightMap" in the draw params), SH probe grids, probe cubemaps named GILM… |
| Effects | An effects editor | FXR3: trees of containers and actions with keyed curves, the same family as Sekiro's and Elden Ring's |
| Sound | FMOD Designer (FMOD Ex 4.44) | .fev projects from FMOD Designer's own format; FromSoft's user properties on events |
| Post-processing | Silicon Studio's YEBIS 2 | GXYebis2Filter in the exe's RTTI; its shaders compiled into the exe |
2Building a level, step by step
Put the evidence of the Levels and Renderer chapters in order, and this sequence fits:
_hh, _hl) in the same file. m40 has 394 models placed 4,057 times; one small prop alone is placed 1,678 times..btl), probe points and boxes are placed; a bake produces 1,176 lightmap textures, 145,000 SH probes and 14 cubemaps. Small repeated props share atlas lightmaps, with per-part UVs in a table. Real-time sun shadows are kept for characters and a few objects.
Baking the water's reflections
The water doesn't mirror the terrain. It mirrors a few bands of upright cards standing along the banks, painted with 128 × 64 panoramas of what's behind them, sky included (Renderer). Those panoramas are baked, not rendered by the game: they ship as BC1-compressed textures in the map's texture archive, their unlit material shows the lighting and haze as painted in, and DS3's frame draws the cards from them without any pass that would update them data capture.
So the editor must have had some process to make them. Hand-painting panoramas that match the level this closely is unlikely. More likely, a tool rendered the level from the water, looking out towards each card's place, and saved the result small. Once an artist had placed the cards (a separate map piece, marked to draw only in the reflection), the bake would have filled in their textures. Nothing in the files records how it was done or when it was run. One trace of the bake may be that the panoramas look paler and hazier than the live scene guess.
3How the collision was fitted to the art: a measurement
To test it, a script of ours took 12 vertices from every one of m40's 363 collision bodies (4,324 points) and measured how far each lies from the nearest render triangle, and whether it sits exactly on a render vertex data. The bodies are grouped by how they're named:
| Collision bodies named… | n | < 1 cm | 1-5 cm | 5-20 cm | no art within 1 m | on a render vertex |
|---|---|---|---|---|---|---|
| all | 4,324 | 47.9 % | 26.2 % | 21.6 % | 2.0 % | 33.5 % |
after an art model (m000200) | 396 | 82.8 % | 13.6 % | 2.5 % | 0.3 % | 66.4 % |
as a model's hit mesh (m005590_hh) | 1,068 | 56.7 % | 28.2 % | 13.4 % | 0.5 % | 44.6 % |
after the part (h001000: terrain) | 484 | 54.1 % | 14.9 % | 13.6 % | 12.0 % | 39.5 % |
after an art instance (m002040_1004) | 2,328 | 36.5 % | 29.7 % | 30.4 % | 0.9 % | 21.8 % |
| special layers (kill, camera, water…) | 164 | 26.8 % | 14.6 % | 18.9 % | 29.9 % | 14.6 % |
What it shows data:
- The names are honest. 191 of the 194 bodies named after an art instance lie on exactly that instance, and 79 of 86
_hh/_hlbodies on the model their name gives. All copies of one prop have the same triangle count. - Collision hugs the art but isn't the art. Three quarters of the vertices are within 5 cm of a visible surface, but only a third are on a visible vertex. If the collision had been exported straight from the render meshes, nearly all would be.
- Props get simple proxies. Per-instance prop collision is the loosest: 30 % at 5-20 cm. A 20-triangle hull 10-16 cm outside a small prop is typical.
- Some geometry has no art at all. 30 % of the special layers' vertices and 12 % of the terrain meshes' have no art within a metre: hidden floors, invisible walls, triggers.
Most likely, each art piece was modelled with a hand-made, simplified hit mesh beside it in the same source file. Some were built from the art's own polygons (hence the
on-vertex share), some re-topologised over it within a few centimetres, and props got rough hulls. Big pieces whose shape matters (stairs, bridges) seem to use the art mesh itself as collision.
At export a tool gathered every placed piece's hit mesh into its region's collision part, baked into map space and named after the source. That's why a tree's collision is named after the tree's placement.
Level designers then added gameplay geometry by hand on top. The low-detail l set, a seventh of the triangles, was probably a further pass, automatic or manual: not measured.
4Characters and animation
- Clips were cut to measure. Root motion is stored apart from the pose (a reference-frame track), so animators authored real travel (a 4.45 m roll, 6.04 m/s dash), and design tuned feel by choosing clips and windows, not by changing speeds. The two clips of the Coiled Sword pull (the knight's and Gundyr's) keep the hand within 9 cm of the sword for five seconds: they were made together, probably in one scene.
- Timing was designed on a timeline. 186,508 TAE events on the player alone, most of them flags: i-frames, cancel windows, turn locks, sound and effect cues, poise windows. That's a designer's tool, used clip by clip.
- Reuse everywhere. The Cemetery hollows have no animations of their own and play the Hollow Soldier's. Most humanoid enemies share one behaviour graph. One model file holds every weapon and outfit of an enemy type, switched by display masks. An enemy variant is a few param rows, not new assets.
- Bosses are built in layers. Gundyr's second phase is a status effect that redirects every clip to a second set and swaps his AI file; the pus and arm changes are display-mask events on one clip. His AI script also holds Champion Gundyr's branches: one file, two bosses.
5Designing in tables
Row ids follow schemes that look like conventions a team agrees on, so people and tools can derive one id from another:
| Scheme | Example |
|---|---|
| attack row = 100,000,000 + weapon variation × 1000 + judge | Longsword R1: 102300000 |
| object effects = model number × 1000 + variant | a lit candle: 391000000 |
| footstep effect = 100000 + floor material × 1000 + step kind | a run in water: 120002 |
| flags and entities carry the area | Gundyr: entity 4000800, defeated flag 14000800 |
| sound names = type letter + nine digits, the last two the material | a run on grass: c000002005 |
Weapons without their own attack rows fall back to their weapon class's rows, which suggests an inheritance the editor or a build step understood. The AI's weights per distance, cool-downs and success distances read like values tuned by playtesting and kept in script, not in params.
6Fingerprints left behind
Shipped games keep traces of their making. A few from Firelink:
Overwritten tuning
The player script defines ACCELERATION_DASH_SPEED_UP = 6 and later redefines it as 4.5. Its counterpart …_SPEED_DOWN is used but never defined; it's harmless only because the code path can't reach it.
Missing and unused pieces
About ten textures referenced by m40 pieces aren't in the archives at all. The forward roll a000_027110 exists but isn't in the behaviour graph. 43 "DummyEnemy" parts stand in for cutscene characters.
Repurposed fields
NpcThinkParam's ear_dist holds 9910, the AI's guard request, on exactly the shield users: a field reused for something else. SoundTargetForgetTime reads 16448 for every hollow, which makes no sense as a time.
Shared and borrowed
Six m40 textures live in High Wall's binders. The lightmaps' sharpness offset is 1, which makes every texel fully directional, so the blend it controls does nothing. The level-of-detail switch sits at exactly twice the param's distance, cause unknown.
7How sure are we?
| Claim | Confidence | Because |
|---|---|---|
| Collision is hand-made and separate from the art, fitted to it within centimetres | Strong | The measurement above; the two never share a file |
| Each art piece carried its own hit mesh, merged per region at export | Strong | Body names match the art they lie on, 191 of 194 by instance |
| Visibility (draw groups) was authored by hand per floor | Strong | It's data in the MSB; no computed visibility exists in the files |
| The water's reflection panoramas were baked by a tool from the level | Plausible | They're pre-rendered textures that match the level; how they were made isn't recorded |
| A Japanese-language 3D package was used | Plausible | Two default object names in Japanese; which package isn't shown |
| The map editor was called MapStudio | Plausible | The folder name; nothing else |
| The map was built in a frame turned 28° | Plausible | Collision, lightmaps and probes share it; where it's set isn't found |
| Clips like the sword pull were animated together in one scene | Plausible | They fit to 9 cm for five seconds |
The l collision was generated by decimation | Guess | It's a seventh of the triangles; not measured |
| AI weights were tuned by playtesting | Guess | Their shape and per-row exceptions; no direct evidence |