Titanic: Adventure Out of Time (RE)

This folder explains how Titanic: Adventure Out of Time (TAOOT) is put together and how this project turns the original 1996 game files into something that runs in a browser — no DOSBox, no emulator, a fresh reimplementation of CyberFlix's DreamFactory 4.0 engine in TypeScript.

The docs are written for a curious programmer who has not done low-level reverse engineering before. You do not need to know C++, and you do not need to be comfortable reading raw bytes. Where a byte-level detail matters, it is explained in plain language first, with the exact numbers in a table you can skim past.

Standing on other people's work

Almost nothing about DreamFactory is publicly documented, so it's worth being clear up front: the hard part of understanding these formats was done by other people, and this project mostly builds on their shoulders. Where a doc knows something, it tries to say where that knowledge came from.

1. DFET, by M3tox — a GPL-3.0 C++ tool that extracts assets (images, audio, scripts) from DreamFactory games. This is the big one. The container skeleton, the image-decompression codec, the audio codecs, the script encoding and the full command-name table — essentially the entire "how do you read these files" story — was worked out by M3tox and published in DFET. This project's file-reading layer is a port of that C++ code, and these docs lean heavily on M3tox's own plain-English write-up, FileInfos.md. If these formats make sense to you after reading, most of the credit is theirs.
2. MRXstudios — earlier still, MRXstudios' work reverse-engineering the scripts in DUST: A Tale of the Wired West (an older DreamFactory game) is what inspired DFET in the first place. The script-decoding lineage starts here.
3. The original game executable, TI.EXE — DFET can pull the data out of the files, but an extraction tool never has to run the game, so it didn't need to know what the scripts and coordinates actually do. That behaviour (what each script command means, how a prop is placed in 3D, how timers fire) isn't in DFET, so this project worked it out by disassembling the shipped Windows executable. This is the part that's genuinely new here — recovered incrementally, one command at a time (the builtin reference shows how far that has come). Whenever a doc says "recovered from TI.EXE", that's what it means.
4. The game files themselves — a lot was simply confirmed by decoding a file and checking the result against what the real game shows.

Reading order

The sections below are in dependency order — each assumes the ones above it — and so are the pages inside them. Every page also names its own prerequisites at the top, so you can jump straight to one and follow those back.

Two pages are outside the order, for reading out of order: the glossary (one line per term, when a word you don't know turns up in the middle of a page) and how we know it's right (what actually verifies these claims — worth reading whenever you want to know how load-bearing one is).

Concepts — how the whole thing works

• How the game works — the big picture. What a "pre-rendered adventure on rails" actually is, and what happens from the moment you launch the game to walking around and clicking on things. Read this first.
• Engine architecture — how this project is organised: the file-reading layer, the runtime engine, the render loop, and how a mouse click travels through the system.
• The scripting language — the game is mostly scripted, not hard-coded. This explains DreamFactory's little scripting language, the event model (openset, mousedown, …), and how the interpreter runs it.
• The mission flow — how the plot is encoded: the mission/phase globals, the story spine reconstructed straight from the scripts, and the tool that extracts it. Deeper than the three above and full of spoilers; safe to come back to.

File formats — the DFile containers

All game data lives in "DFile" container files. Read the foundation doc first; every format doc after it builds on it.

• The DFile container format — the shared skeleton every DreamFactory file uses. Read this before any specific format.
• The image codec — how a compressed picture (a room view, a movie frame, a prop) turns back into pixels, plus how colour palettes and depth maps work.
• SET — rooms, scenes & views — the pre-rendered world you walk around in.
• SHP — props ("shop" files) — the things drawn on top of the world: doors, items, buttons.
• MOV — movies & inspectable objects — cutscenes and click-through close-ups, and why one file is a chain of films rather than one.
• STG — stage files & the UI — full-screen screens like the deck map, the inventory, and the on-screen UI band.
• Audio — TRK / SFX / 11K / SND — music, sound effects and voice lines, and the two custom compression codecs.
• BOOTFILE — the game's startup & standard library — the script bundle that boots the game and defines its shared behaviour.
• The script container on disk — the binary layout of a compiled script, for when you want to go deep.
• PUP & CST — characters ("puppets") — dialogue, facial animation and character sprites.
• Saved games (.ti) — the one file the game writes: a serialized memory dump, and how it's read and patched back.

Runtime — how the port plays the game

The formats say what's in the bytes; these docs say what the engine does with them — the behaviour recovered from TI.EXE, plus the browser host around it. Overview: the runtime section.

• Timing — the heartbeat, makeloop, crickets, walks, and the game clock.
• Stage & UI — flat lifecycles, the overlay stack behind the inventory, and the click order.
• Characters — actors in the world and puppet conversations.
• Audio — channels, bank resolution, and the volume controls.
• Saving & loading — snapshots, the load sequence, and the in-browser saved-games UI.
• The browser host — the page and the boot it runs, the viewer, the screen everything composites into, the movie player, and input.
• The low-memory game — the smaller version of itself the game shipped with, what its own lowmemory() switches off, and why .11K is not 11 kHz.
• Languages & the chooser — one data tree per language, the two selectors a bare filename resolves through, the code page its text turns out to be in, and the chooser this port wrote as a real DreamFactory stage.

Editors — reading the formats back out

Seven browser pages the dev server hosts, one per container format: load a file, take it apart, change what is safe to change, export the repacked original. They read with the engine's own code, so they double as the best debugger the file layer has. Overview: the browser editors.

• The set editor — rooms: scenes, turn rings, hotspots, roads, actor marks.
• The shop editor — props: groups, states, frames, and where a frame lands on screen.
• The movie editor — a movie read as what it is, a chain of state machines of frames.
• The stage editor — flats and their clickable regions.
• The track editor — audio banks: the looping theme and the named one-shots.
• The puppet editor — a character's brains: stances, dialogue, subtitles.
• The cast editor — a character's body: poses as steps × directions.

Reference

Lookup material: the glossary, builtin commands, tools, the test inventory, and the route.

A note on licensing

The decoding logic in this project is ported from DFET, which is GPL-3.0, so this project is GPL-3.0 too. The game data is not included and is not distributable — it stays copyright CyberFlix and must come from your own copy of the game. These docs describe formats; they do not ship assets.