Dust: A Tale of the Wired West

CyberFlix, 1995, on DreamFactory 1 — the engine two years before Titanic, and the reason several formats in this documentation have a -v1 reader beside them.

One CD, one language, no edition axis, and a town you can walk around. It is in this repository to answer a question rather than to be finished: how much of a port written against DreamFactory 4 can read DreamFactory 1 at all? Most of it: the container envelope, the frame codec, the palette shape, the script bytecode and its opcode numbering, and the PUP and CST record layouts are all frozen across the two engines. What moved is the per-format container-0 header, plus two things that changed in kind rather than in layout: how a set describes movement, and how a bank names its sounds.

What runs today

The page boots off the real disc, through the same GameHost Titanic uses:

• the boot, out of the disc's own BOOTFILE — which is not in DATA/ but at INSTALL/ALT31/BOOTFILE, beside the installer's copy of DF.EXE;
• the intro films, played by the engine's own MoviePlayer over mov-v1.ts, including the frame flag that says hold this frame until the sound it started has finished — which makes the dog at the edge of town growl twice instead of once (#278);
• the town, walked with the three controls the original had, because its set scripts handle exactly uparrow, leftarrow and rightarrow;
• saved games — its own .rtd in its own IndexedDB database, seeded from the ones that ship beside the disc, which are a whole playthrough;
• the control panel, a full-screen flat with its buttons drawn on it;
• TH mode, the room alone on a wide display with the menu band sliding in when it is wanted, as on Titanic's page, after Tyler Hartman's fullscreen builds;
• a collection page, for how to run the 1995 DOS game instead of this port of it.

What is different, in one paragraph

There is no disc to mount: Dust is one CD, so nothing does setpath(disk). Its SET addresses a standpoint by grid cell and facing rather than by the numbered views a v4 set uses. Its films are the format that diverges most — a frame names the frame after it, can block until the sound it started has finished, and carries typed click records rather than a region table. Its ambience is one track rather than a crowd of reopened containers. Its saves are .rtd and carry world coordinates that a v4 prop record does not have at all. And its town exists twice — town.set by day and nite.set by night — which matters to a save format.

The pages here

• Walkthrough — the game, played, day by day. Every step names the shipped save that ends it, so any of them can be loaded
• The golden thread — where that walkthrough comes from: sixty of the sixty-one shipped saves are one continuous session, written by the original DF.EXE, and what that is worth to a port
• Music & sound — the 40 banks — why .SND is not .TRK, and why the name a script asks for is frequently not the file's

And the engine pages that carry Dust's half

Most of what is true about Dust is true about DreamFactory 1, so it is written up with the engine rather than here:

SET — DreamFactory 1	the grid of cells and one flat transition table, and the adapter that hands it to the viewer as if it were a v4 set
MOV — DreamFactory 1	the chain-of-segments model survives and almost every mechanic under it differs — the format where the two engines diverge most
Saved games, DF1 (.rtd)	the same save container three years earlier, rewritten from DF.EXE's own record layout
Saving & loading	both halves, v1 and v4, and what a load actually is
The DFile container format	the envelope, unchanged between the two

The code

dust/ in the repository: three pages (the game, /collection/ and the unlisted /speedrun/ workbench), its own disc, its own tools and suites. The architecture map has the file list; the short version is that the shell is small, because one volume and one edition need much less than six editions and two CDs.

Its suites are dust/tests/ — the movie layout against the whole disc, the player on a clock, the .rtd round trip, every set read without a game tick (sets.ts), and the play page itself run in node (page.ts) — and the ones that open the disc skip rather than fail without a rip, which is why the CI runner treats Dust's disc as optional (Continuous integration). The test reference lists them all. Its tools are dust/tools/: dustsets.ts, the sweep the v1 SET reader was built against, rtdthread.ts for the golden thread, mkdustlogo.ts for the title card, and the two that write run sheets below.

The speedrun

Dust has Titanic's speedrun workbench, off the same engine modules (the speedrun), at /speedrun/. Its own verbs are in dust/src/speedrun/actions.ts, each earned by the route: goto a grid cell (the shape the whole map and the thread's ladder are written in), give, offer, takeInHand, talkOut, doorAt, meet, loadSave, and blackjack(800), which plays Jan's table in the Hard Drive Saloon until the cash in hand reaches the target (#490). menuSave and menuLoad go through the horn and the control panel, on the clock (dust/src/speedrun/menu.ts); loadSave(), like Titanic's load(), makes a run NOT A VALID TIME.

dust/tests/speedrun/run.sheet.txt is the route as legs, one per rung of the thread, and every leg opens by loading the save it starts from — so it is the route, not yet a continuous run, and its total is not a time. The commands around it:

npm run speedrun:sheet -w dust    # regenerate the sheet from the thread's ladder (overwrites; diff first)
npm run speedrun:rung -w dust -- d2a006   # one playthrough rung's gestures as sheet lines (--all for every rung)
npm run speedrun:legs -w dust     # every leg in one boot, against a dev server (ONLY=, FROM=)

Back to Documentation.