The runtime — how the port plays the game

Prerequisite: Engine architecture.

The format docs answer one question: what is in the bytes on disk. This section answers the other one: what the engine does with them at runtime — the behaviour that DFET never needed and that was recovered from TI.EXE and from watching the real game.

Keeping the two apart is deliberate. A format page should stay true as long as the 1996 files don't change (they won't); a runtime page describes living code that gets refactored. When a format doc used to carry runtime detail ("how the UI band is drawn", "how a cricket pans"), every refactor quietly made it stale. Now the format pages stick to bytes and link here for behaviour.

The pages

Read in any order — each names its own prerequisites.

1. Timing — the heartbeat, loops, crickets & walks — the two time bases, makeloop's one-shot-that-re-arms model, positional ambient sound, actor walks, and the game clock behind the pocketwatch.
2. The sinking — how mission 4's clock runs — the one level played against a clock, and why that clock counts engine passes rather than seconds: the heartbeat, the conversations, the phase timetable's hold, and the movement bump that makes turning in place cost you the ship.
3. Stage & UI — flats, overlays and the click order — the StageController: how a stage opens, the overlay stack behind the inventory, and exactly who gets a click first.
4. Characters — actors & puppets at runtime — walking CST sprites in the world and PUP conversation close-ups: facing math, occlusion, speech pacing, subtitles and choice bevels.
5. Audio at runtime — channels, banks & volumes — the three playback channels, how a name finds its bank, the two-slot currentsound model, and the volume controls (including one deliberate divergence).
6. Saving & loading at runtime — what a save snapshot contains, the script-free load that restores the engine from the file rather than re-running the room, and the in-browser saved-games UI with its IndexedDB "file system".
7. The browser host — the part that is neither format knowledge nor recovered behaviour: the page and the cold boot it starts, the SetViewer navigation state machine, the movie player, input wiring, and the developer toolbar.
8. The low-memory game — the smaller version of itself the game shipped with: what BOOTFILE's own lowmemory() switches off, why .11K is not 11 kHz, and the one number the port moves to let a player hear it.
9. Languages & the chooser — one data tree per language, how a bare filename resolves through two selectors (disc and language), the code page a tree's text turns out to be in, and the language chooser: this port's own DreamFactory stage, scripts and all.

Where the code lives

Subsystem	Source	Page
Heartbeat, loops, crickets, walks	engine/scheduler.ts, engine/clock.ts	Timing
The mission-4 clock and its phase timetable	engine/scheduler.ts (serviceGameClock), engine/setscripts.ts (openScene/viewChanged)	The sinking
Stage layer (STG at runtime)	engine/stage.ts	Stage & UI
Actors (CST at runtime)	engine/actors.ts, engine/geometry.ts	Characters
Puppets (PUP at runtime)	engine/puppet.ts, puppet-view.ts	Characters
Props (SHP at runtime)	engine/props.ts	Stage & UI, SHP
Audio channels + bank library	engine/audio.ts	Audio
The heapsize answer the game's lowmemory() reads	engine/builtins/helpers.ts	The low-memory game
Save/load orchestration	engine/saveload.ts	Saves
Saved-games UI + storage	save-browser.ts, save-store.ts, save-seed.ts	Saves
Navigation + rendering	viewer.ts, ring-cache.ts	Browser host
The screen everything composites into	screen-presenter.ts, screen.ts	Browser host
Movie playback	movie-player.ts, df/mov-pace.ts	Browser host, MOV
Page + input	main.ts	Browser host
What a launch has to have in hand	engine/bootplan.ts, host.ts	The boot plan

The interpreter itself — scopes, operators, the event chain — is a language topic and stays in the scripting doc; the full command list is in the builtin reference.

Start with the one everything else leans on: Timing.