Wander (1974, mainframe / Peter Langston)

Author(s): Peter Langston (engine); individual worlds by Langston, Nat Howard, and others.

Sources: Wikipedia: Wander (1974 video game) · shmup/wander (GitHub source release) · Renga in Blue: Wander (1974) release, and questions answered · Retroactive Fiction: Wander (1974), a lost mainframe game is found · Internet Archive: Wander (wander_201504)

Category: inspiration, Batch 10 (gameplay-mechanics mining). The cleanest early precedent for KN-86’s model: one engine, many authored worlds, with content held as separate data the engine interprets. Serves: IF Creation Kit / propaganda (assigned by Josh; see cart map)

What it is

Wander is a program for writing and running text adventures, built by Peter Langston around 1974. Langston did not describe it as a game. He described it as “a tool for writing non-deterministic fantasy ‘stories’” whose unfolding is affected by decisions the reader makes. The Wander binary is a generic interpreter; the actual adventures live in separate world files the interpreter loads at startup. The source was believed lost for decades until an interactive-fiction enthusiast contacted Langston in 2015, who found the 1980 distribution in a friend’s archived email and released it on GitHub. That makes Wander one of the earliest documented text adventures, and the earliest documented adventure authoring system.

Mechanics

The core design is the split between a fixed engine and swappable world data. From the released source (shmup/wander README):

• Two files per world. A world named oz is authored as oz.wrld plus oz.misc. The .wrld file holds all location-specific information: long and short descriptions, local action keywords, and the conditions and results attached to each location. The .misc file holds the global information: the initial message, word synonyms, initial object locations and characteristics, and global action keywords with their conditions and results.
• World selection at load time. The player runs wander oz to load a world by name. With no argument, the engine loads the default world, a3. An in-game init command re-reads a fresh .wrld / .misc pair, so an author can switch worlds without restarting the interpreter.
• A small state model authors program against. 128 numbered variables (0–127), each holding a value from −32768 to 32767; support for 256 to 512 numbered locations per world; and action logic expressed as condition/result sequences written with an escape-sequence syntax embedded in the world files.
• Natural-language command parsing. The engine parses typed imperative commands (for example north, kick machine), resolving them through the per-world synonym table so authors can map many phrasings onto one action.
• Instrumentation for authors. Optional .mon files record player commands, letting an author watch how readers actually move through a world.

The recovered 1980 distribution carries several distinct worlds built on this one engine, including castle (a rural castle quest), a3 (a science-fiction diplomacy scenario), library (a post-apocalyptic library exploration, authored by Nat Howard), and tut (a binary-arithmetic tutorial). One world, a department-store game, was never recovered. The same engine ran all of them; only the data changed.

Mineable patterns

• Engine/content separation as the primary architecture. The interpreter knows nothing about any specific adventure. All specificity lives in loadable data files. This is the reusable idea: build the runtime once, then ship worlds as data.
• A world as a pair of scoped data files. Location-scoped data (descriptions, local actions) sits in one file; world-global data (synonyms, initial object placement, global actions) sits in another. A clean split between “here” rules and “everywhere” rules.
• Condition/result action tables authored inline. Behavior is expressed as condition-then-result sequences attached to locations and to the world globally, authorable without editing the engine.
• A synonym table as the parser’s vocabulary layer. Many typed phrasings collapse to one action through an author-defined synonym map, keeping the command grammar forgiving without hard-coding.
• Hot-swap content at runtime. The init re-read means the same running interpreter can move between worlds, which is a natural fit for a device that loads different content modules.
• Author instrumentation built in. Command-logging turns real play sessions into design feedback for the author.

KN-86 resonance

Keep this at the concept level. The fit is architectural, and this stops short of designing a specific minigame.

• KN-86’s whole authoring model is one runtime plus many data-defined content modules: the nOSh runtime interprets Lisp carts, the same way the Wander binary interprets world files. Wander is the tidiest 1970s precedent for that separation and useful to cite when explaining why the engine ships empty and the carts carry the world.
• The .wrld / .misc split rhymes with the .kn86 container’s split between program code and static data (ADR-0006), and with the general bias toward human-readable, hand-authorable content that the KEC Lisp cart model already follows.
• Wander’s condition/result action tables and per-world synonym vocabulary echo the “content as data” direction of cart behavior tables and the SDK’s cart grammar, where an author declares world logic for the runtime to interpret.
• Multiple shipped worlds on one interpreter mirrors the launch-titles-as-capability-modules framing: distinct experiences, one loader, swappable at load time.

Sources & verification

Consulted: Wikipedia: Wander (1974 video game); the GitHub source release shmup/wander and its README (authoritative for the .wrld / .misc format, the 128 variables, the a3 default world, and the init switch command); Jason Dyer’s Renga in Blue and the Retroactive Fiction writeups (recovery story, the world list castle / a3 / library / tut, and the lost department-store world); Internet Archive item wander_201504.

Confidence: high on the authoring architecture (the released source and its README are primary). Medium on the exact 1974 feature set: the recovered code is the 1980 C version, and some claims about the very first HP BASIC build rest on Langston’s later recollection. The “predates Adventure” framing is well supported for the C rewrite (1974) but is usually stated with the same hedge, since Wander’s earliest form and Adventure’s development overlap in the mid-1970s. Not confirmed: any relationship to KN-86 beyond the architectural analogy drawn here.