home · crate map

The port's crate map

The project is a Cargo workspace of small crates stacked in bands: one crate per disc format at the bottom, the format families over them, the engine's World-free kernels, the simulation, and the hosts at the top. Hover a crate to see what it uses and what uses it, click it for its scope, binaries and modules, or follow a scene from the disc to the screen.

The map

Each band uses only the bands below it, and colour marks the track a crate belongs to. The edges are the real [dependencies] of every Cargo.toml, regenerated with the page's data (how).

Loading the crate map...

Disc to pixels

The path one scene takes, from sectors on your disc to a frame on screen. Each step lights the crates that do the work; pick a step, or play the whole path, then trace it on the map.

Three hosts, one engine

No host carries a second copy of the game. The two play hosts tick the same engine-session BootSession over the same World; the minigames page drives the World-free minigame rules engines directly. What differs is only the shell: the window, the GPU API and the audio device. Host drift covers the gates that keep a feature from landing in one host only.

The native play-window and the browser play page both run engine-session over engine-core; the minigames page runs the minigame rules engines without a World. Native play-window engine-shell · legaia-engine winit + wgpu + cpal Browser play page web-play · play-app.js WebGL + WebAudio Browser minigames page web-minigames (WASM) one module per minigame engine-session · BootSession scene host + per-frame order + BGM director engine-core · World the simulation and its tick World-free kernels VMs, battle, field, menus, effects, render kernels minigame rules engines engine-minigames, engine-fishing
Solid arrows: the two play hosts share one session over one World. Dashed: the minigames page reaches the rules engines straight, below the World. Each box opens its crate on the map.

How the map stays true

The page draws from site/crate-map.json, which scripts/ci/gen-crate-map.py builds out of what the workspace already states: the edges and binaries from each crate's Cargo.toml, the public modules from its src/lib.rs, the one-line scope from the crate tables in CLAUDE.md, and the kernel ranks, roles and coupling reasons from scripts/ci/crate-layering.toml. Only placement is written by hand, in scripts/ci/crate-map-layout.toml.

  • Nothing points up. The generator fails if a crate depends on a crate in a band above its own, if a crate sits in no band or two, or if a crate has no line in CLAUDE.md.
  • A stale map fails the commit. gen-crate-map.py --check runs in the pre-commit hook and in CI, so a new crate, edge or module cannot land without the page and the README diagrams being regenerated with it.
  • The kernel ranks are not drawn by hand either. They are the stack the layering gate derives from its committed table of allowed edges.
Reference Crate layering How the layers stack The browser host Host drift