How They Built It

A reconstructed account of the development process, based on reverse engineering of the SMART EGG engine and game data.

Contents

  1. The Team
  2. The SMART EGG Engine as a Product
  3. Development Tools and Workflow
  4. Game Design Process
  5. Memory Management
  6. Testing and Quality
  7. Publishing and Distribution
  8. Step-by-Step Build Process
  9. What This Tells Us

The Team and Their Roles

Three names appear in the credits, each with a deliberately specific title:

Ron Harris

Game Design and Scenario

He wrote the story, designed the puzzles, mapped the rooms, and authored every line of text. The prose is sharp, funny, and thoroughly British. Harris was the creative engine of the project.

Nigel Brooks

Implementation and Development

The bridge between writer and programmer. He took Harris's text and room maps and encoded them into the data tables: room connection matrices, object property bytes, action handler indices, pointer tables. He assembled the game from its parts.

Said Hassan

Programming and System

He built the SMART EGG engine: the text decompression algorithm, the command parser, the inventory system, the screen output routines, the save/load mechanism, and the offline compression tools. Hassan was the systems architect.

How a Three-Person Team Worked in 1987

There was no Git, no Slack, no shared cloud drive. A small team like this almost certainly worked in the same room, passing floppy disks or cassette tapes between them. Harris writes game text on paper or types it into a word processor. Brooks feeds the text through Hassan's compression tool, then manually builds the data tables. Hassan provides the engine as a relocatable binary blob that Brooks plugs data into.

The SMART EGG Engine as a Product

The string "SMART EGG!" at $9B2E was not a throwaway label. This was a product. Smart Egg Software built a reusable text adventure engine and reused it across titles.

The Three-Tier Compression

Hassan's compression scheme operates on three levels, all keyed off a single byte XOR'd with $FF:

Tier 1: Single Characters ($01-$5F)

Each byte maps to one of 96 entries in a character lookup table. The table order is optimized so the most common characters get the lowest indices, which matters for the digram encoding.

Tier 2: Digrams ($60-$EF)

144 two-character combinations built from the 12 most frequent characters. One byte encodes two characters. This nearly doubles the information density of the most common letter pairs.

Tier 3: Dictionary Words ($F0-$FF)

16 whole words stored in a dictionary. The first 11 are English function words (THE, AND, WAS, etc.). The last 5 are game-specific: HARPER and the four compass directions. These words were selected by frequency analysis of the actual game text.

Results

10,279 compressed bytes expand to 16,145 decoded characters. A 36.3% space saving. On a machine with approximately 38KB available per game part, saving over a third of the text storage is the difference between a richly described world and a sparse one. Harris's vivid prose, the mutant dogs with "too many claws and teeth," the walkway that "lurched drunkenly," the bomb that whispers "Psst!", all of this was made possible by Hassan's compression giving him room to write.

Development Tools and Workflow

What Was Available in 1987

On-target development (coding directly on the C64): Turbo Macro Pro, PAL (Personal Assembler for Loadstar). The edit-assemble-test cycle on a single C64 with a floppy drive could take minutes per iteration.

Cross-development (coding on a more powerful machine): PDS (Programmers' Development System) on a BBC Micro, TASM (Telemark Assembler) on MS-DOS, or early PCs with custom serial transfer cables to the C64.

Given the cross-platform ambitions (C64 + ZX Spectrum), they almost certainly used cross-development tools. A cross-assembler with separate assembly targets for each platform is far more practical than writing the same engine in both 6502 and Z80 assembly on native hardware.

The Text Pipeline

  1. Harris writes game text in a plain text file, with markup for color codes
  2. A frequency analysis tool scans the text and produces ranked character, digram, and word frequency tables
  3. A compression tool reads the text and frequency tables, outputs the compressed byte stream plus lookup tables
  4. Brooks takes the compressed text, the tables, and the engine binary, and assembles them into a single loadable file

The Packing Pipeline

After assembly, two additional compression passes were applied:

Stage 1: LZ77/LZSS Compression

A sliding-window compression scheme at $0830. This compresses the game data tables, which contain repetitive structure. Standard LZ77 variant from the C64 scene.

Stage 2: Madsquad/XPLODING Cruncher

A popular tool from the C64 demo and cracking scene, providing good compression ratios with a self-extracting decompressor stub. Part 1 takes 477,072 CPU cycles to decrunch; Part 2 takes 3,502,232 cycles (~3.5 seconds of real-time C64 execution).

Game Design Process

Room Layout: Graph Paper and Colored Pencils

Before a single line of code was written, Harris would have designed the game world on paper. Text adventure room layouts are directed graphs: nodes (rooms) connected by labeled edges (compass directions). The panoramic view from the view-bridge is not just prose, it is the game's world map described in text.

Puzzle Design

The puzzle chain follows a clear dependency graph. Harris understood a critical principle: every puzzle should feel logical in retrospect. The medikit has a red button (emergency stimulant) and a green button (energy boost). Later, you need the stimulant to jump a gap. The connection is there if you were paying attention.

The red herring is deliberate and self-aware. A hint box contains "a clupea harengus" (Latin for Atlantic herring), literally a red herring. This is a designer winking at the player, confident enough in his puzzle design to joke about genre conventions.

The Minefield as Systematic Brute Force

The minefield is a simulation of what using a real mine-detector would feel like: slow, methodical, terrifying. The player must try all compass directions three times before finding the path east. This creates genuine tension through systematic experimentation, not arbitrary puzzle logic.

Memory Management

The 64KB Constraint

The SMART EGG engine makes several clever decisions to maximize available memory:

Three Layers of Compression

  1. SMART EGG text compression (design time): Three-tier character/digram/dictionary scheme. 36.3% savings.
  2. LZ77/LZSS compression (build time): Catches repetitive patterns in game data tables and code.
  3. Madsquad cruncher (distribution time): Final packing for tape, with self-extracting stub.

At load time, layers are peeled in reverse: Madsquad first (~3.5 seconds), then code relocation, then LZ77. Text decompression happens at runtime, on demand, fast enough to be imperceptible on the 1 MHz 6502.

Testing and Quality

How Do You Test a Text Adventure in 1987?

You play it. There is no other way. A tester sits down with the game, a notebook, and a pen, and methodically tries every command in every room: walk the golden path, try to break things, deliberately trigger every failure state, and check for dead ends.

The game has at least 14 distinct death sequences, each with custom prose. Each represents a failure state that someone had to discover, write text for, and test. The variety and humor suggest the team found writing death scenes as entertaining as writing the main path.

Writing Quality as Evidence of Process

The four different "I don't understand" responses ("Eh?", "Pardon?", "What?", "Huh?") are a small detail that reveals care. So are the consistent color conventions (cyan for parser, yellow for dialogue, purple for dark humor, green for environmental signs). This level of polish suggests multiple drafts and dedicated testing time.

Publishing and Distribution

Mastertronic: The Budget Label

Mastertronic sold games at 1.99 GBP on cassette tape, a fraction of what other publishers charged. For developers, this meant tight constraints: small enough for a standard cassette, cheap enough to develop profitably, good enough to compete in a crowded impulse-purchase market.

The SMART EGG engine gave Smart Egg Software an amortized advantage: the engine development cost was spread across titles, making each individual game cheaper to produce.

Tape Distribution

Cross-Platform Release

The game shipped on both C64 (6502) and ZX Spectrum (Z80). The data-driven architecture made porting feasible: same game text, same compression, same room connections. Only the engine code needed rewriting. Hassan likely maintained two codebases sharing the same data format, essentially the same approach as modern cross-platform engines.

Step-by-Step Build Process

Step 1: Design on Paper

Harris sketches room maps on graph paper. Rooms get numbers, descriptions, and connection arrows. Items, locations, and purposes are listed. Puzzle dependency chains are mapped out.

Step 2: Write All Game Text

230+ action texts, 35 room descriptions, system messages, dialogue, death sequences, parser responses. Marked up with color codes.

Step 3: Frequency Analysis

Hassan's tool scans the complete text and produces ranked character, digram, and word frequency tables. These become the compression tables.

Step 4: Compress the Text

The compression tool reads text and frequency tables, outputs compressed bytes plus pointer tables.

Step 5: Build Game Data Tables

Brooks encodes Harris's design into the engine's data format: room connections, object properties, action handlers. Meticulous, error-prone work where a single wrong byte sends the player to the wrong room.

Step 6: Assemble the Binary

Engine code (~7KB) + compression tables (~500B) + compressed text (~10KB) + pointer tables (~1KB) + game data tables assembled into a single binary with correct memory layout.

Step 7: LZ77 Compression

The assembled binary is compressed with LZ77/LZSS. A decompressor stub is prepended.

Step 8: Madsquad Cruncher

Final packing with self-extracting decompressor stub, producing the final PRG file.

Step 9: Tape Loader

A BASIC stub (10 SYS 2061) is prepended. The PRG is written to cassette tape.

Step 10: Test on Real Hardware

Load on a stock C64 with a Datasette. Play through the entire game. Verify tape loading, decompression, text display, puzzles, and the save/load mechanism between parts. Debugging means staring at hex dumps and counting bytes.

What This Tells Us

Rigel's Revenge is a perfect artifact of its era. Three people, with specialized skills, collaborated to produce a product that pushed the boundaries of its platform within the constraints of its budget. The SMART EGG engine is a piece of genuine engineering: a reusable, cross-platform text adventure system with a sophisticated compression scheme that let a writer fill the game with vivid, funny prose.

The game sold for 1.99 GBP. Adjusted for inflation, roughly 6 GBP in 2025. For that price, the player got a two-part adventure with over 16,000 characters of text, a dozen death sequences, a talking bomb, and a red herring labeled in Latin. It was compressed three times, packed onto a cassette tape, and it worked on every Commodore 64 ever made.

Today, building an equivalent text adventure would take a single developer with Python, a weekend, and a few hundred lines of code. There would be no tape to flip, no decompressor running for 3.5 million CPU cycles before the game starts. But the craft would be the same. Someone would still have to design the puzzles, write the prose, and test every failure state. The tools change. The discipline does not.