Internals
How the game works inside, traced through the real code: start-up, world loading, the world file, objects and collision.
These pages follow concrete code paths step by step, with the function names you will find when you
open the files. They describe the tree as of 2026-11-10. For the overall layering (CNA,
cna-engine, the GalaxyEggbertCNA host, the game and editor code, the
engine-independent model) start with Architecture; for the
per-frame order see Game Loop.
Startup Sequence
From main() to the title scene: the player's folder, command-line flags, GalaxyEggbertGame, LoadContent(), the Wait screen and the main menu, and the --mission shortcut.
World Loading
LoadMission(): which file, reading it into WorldRuntime, legacy upgrades, objects and BigDecor, hub doors, placing Blupi, the resume log. Campaign, galaxy and custom worlds.
The .vwr Format
The binary world file byte by byte: VWR1 header, chunk table, VCH1 chunks, palette packing, the BMD1 sparse metadata types and their record layouts.
Object Lifecycle
A MoveObject from its world record to MobileObjSpec, through InteractionSystem (patrols, contact, pickups, shots, dynamite) to a 3D model or a billboard on screen.
Collision
BlupiController: quarter-cell masks, crates and solid BigDecor, no step-up (he jumps), ledges, swimming, penetration recovery, and the exact hazard shapes of lava, saws and fans.
Conventions used on these pages
- Raw grid coordinates are a world's own cells, 0-99 on each axis. Render space is the same shifted by −50 on X and Z (
WorldRuntime::kWorldCenterX/Z); Y is never shifted. Blupi's controller works in render space and converts to grid cells when it reads blocks. - Ticks: the simulation runs at 60 updates a second; timings copied from the original game are in its 20 Hz ticks, and 64 original pixels make one block.
- Ledger IDs such as
BD-0077orOR-0069point intoplans/audit/in the repository, where each behaviour decision is recorded.