Introduction

Welcome to SLP-ZIL, the Zork Implementation Language interpreter for the Emulator.ca Systems BBS network.

In the early 1980s, a small company in Cambridge, Massachusetts created something remarkable. Infocom's text adventures—Zork, Planetfall, The Hitchhiker's Guide to the Galaxy—transported players to worlds built entirely of words. While other games offered crude graphics and simple mechanics, Infocom's interactive fiction offered rich narratives, memorable characters, and puzzles that challenged the mind rather than reflexes.

The secret behind these masterpieces was ZIL: the Zork Implementation Language. Developed from the MDL programming language at MIT, ZIL gave Infocom's "Implementors" the tools to create living, breathing worlds. Rooms connected in logical geography. Objects could be examined, taken, dropped, or combined. The parser understood natural English commands with remarkable sophistication for its era.

SLP-ZIL brings this legendary language to your terminal. While this implementation provides a focused subset of the full ZIL specification—concentrating on world modeling, object manipulation, and narrative output—it captures the essential spirit of adventure game creation. You can define rooms and their connections, place objects in the world, write routines that respond to events, and craft the text that brings your creation to life.

This is not merely a historical curiosity. ZIL's elegant design influenced generations of interactive fiction tools that followed. Understanding ZIL is understanding the foundation upon which an entire genre was built.

The SLP-ZIL interpreter provides:

• World model primitives: ROOM for locations, OBJECT for interactive items
• Behavior definitions with ROUTINE
• Conditional logic via COND with pattern matching
• Narrative output with TELL
• Variable management: SET (local) and SETG (global)
• Object manipulation: MOVE and REMOVE
• Containment testing with IN?
• Boolean operators: AND, OR, NOT
• Flow control: RTRUE, RFALSE, RETURN

Quick Start

Create your first interactive location in under five minutes.

Step 1: Dial the SLP-ZIL service:

ATDT555-0360

Step 2: Once connected, define a room at the READY. prompt:

<ROOM CAVE
  (DESC "A damp cave with water dripping from the ceiling.")
  (EXITS (NORTH FOREST))>

Step 3: Add an object to the room:

<OBJECT TORCH
  (DESC "A wooden torch, its flame flickering.")
  (LOC CAVE)>

Step 4: Write a routine to describe what the player sees:

<ROUTINE LOOK ()
  <TELL "YOU ARE IN A CAVE. ">
  <COND
    (<IN? TORCH CAVE>
      <TELL "A TORCH PROVIDES DIM LIGHT.">)
    (ELSE
      <TELL "IT IS VERY DARK HERE.">)>>

Step 5: Run your routine:

<LOOK>

The interpreter responds: YOU ARE IN A CAVE. A TORCH PROVIDES DIM LIGHT.

You have created your first ZIL world. From here, you can add more rooms, connect them with exits, place objects, and write routines that bring your adventure to life.

Getting Connected

To access the ZIL backend, configure your modem for dial-out and issue the following command:

ATDT555-0360

Upon successful connection, you will see the ZIL banner and a prompt indicating the system is ready:

Language Basics

Expressions and Lists

ZIL belongs to the Lisp family of languages, deriving from MDL at MIT. Unlike standard Lisp which uses parentheses for everything, ZIL uses angle brackets <> for forms (executable expressions) and parentheses () for property lists (data structures):

<TELL "HELLO, ADVENTURER!">

The angle brackets define a form. TELL is the operator—it outputs text to the screen. The string "HELLO, ADVENTURER!" is the argument—the text to display.

Forms can be nested. Inner forms are evaluated first, and their results become arguments to the outer form:

<TELL "THE APPLE IS " <COND (<IN? APPLE KITCHEN> "HERE") (ELSE "GONE")>>

Conventions:

• Keywords and object names are typically UPPERCASE
• Strings are wrapped in double quotes
• The interpreter ignores extra whitespace and line breaks
• Comments are not supported in this subset

Rooms and Objects

The world model consists of rooms (locations the player can visit) and objects (items that can be examined, taken, or manipulated). Every adventure game is built from these two primitives.

Defining Rooms

<ROOM KITCHEN
  (DESC "A tidy kitchen with a humming refrigerator.")
  (EXITS (NORTH HALL) (EAST PANTRY))>

Directions can be: NORTH, SOUTH, EAST, WEST, UP, DOWN, IN, OUT

Defining Objects

<OBJECT APPLE
  (DESC "A shiny red apple, perfect for eating.")
  (LOC KITCHEN)>

Routines and Flow

Routines are named blocks of code that perform actions, make decisions, and return results. They are the verbs of your adventure—what happens when the player does something.

ROUTINE

Use ROUTINE to define reusable behavior blocks:

<ROUTINE routine-name (arguments)
  body...>

The argument list can be empty () or contain local variable names. The body consists of one or more expressions that execute in sequence.

COND (Conditional Logic)

COND is ZIL's branching construct—equivalent to if/else-if/else chains in other languages. It evaluates each clause in order; the first clause whose test succeeds has its body executed.

<COND
  (test-1 body-1...)
  (test-2 body-2...)
  (ELSE default-body...)>

The ELSE clause is optional but recommended—it catches any case not handled by previous tests.

RTRUE / RFALSE / RETURN

Every routine eventually returns a value. These constructs control what gets returned:

If a routine reaches its end without an explicit return, it returns false by default.

State and Objects

Adventures are stateful—the world changes as the player interacts with it. Doors open, items move, puzzles are solved. ZIL provides tools to track and modify this state.

Variables: SET and SETG

Variables store values that can change during play. ZIL distinguishes between local and global scope:

Arithmetic Operations

SLP-ZIL supports basic arithmetic for counters and scores:

Object Manipulation: MOVE and REMOVE

The physical world of your adventure changes as objects move between locations:

Location Testing: IN?

IN? tests whether an object is currently located somewhere specific:

<IN? APPLE KITCHEN>     ;true if apple is in the kitchen
<IN? TORCH PLAYER>      ;true if player has the torch
<IN? KEY CHEST>         ;true if key is inside the chest

This is the fundamental query for adventure game logic—most puzzles involve checking where things are and moving them around.

Object Flags: FSET?, FSET, FCLEAR

Objects can have boolean flags for tracking state. Define flags using the FLAGS property, then test and modify them:

Logic and Output

Boolean Operators: AND, OR, NOT

Complex conditions combine simpler tests using boolean logic:

TELL (Narrative Output)

TELL writes text to the terminal—it is how your adventure speaks to the player. Multiple arguments are printed in sequence without spaces between them:

<TELL "YOU SEE " "A LAMP.">    ;outputs: YOU SEE A LAMP.

Special TELL Directives:

Equality Testing: EQUAL?

SLP-ZIL provides EQUAL? for testing equality between values:

<EQUAL? a b>           ;true if a equals b
<EQUAL? a b c>         ;true if a equals any of b or c

Complete Examples

These examples demonstrate how ZIL's components work together to create interactive experiences.

Example 1: Kitchen Scene

A simple room with an object the player can take:

Example 2: Light and Darkness

A classic adventure game mechanic—rooms that require a light source:

Example 3: Simple Puzzle

A locked door puzzle requiring a key:

Appendix A: Quick Reference Card

┌─────────────────────────────────────────────────────────────┐
│                SLP-ZIL QUICK REFERENCE                      │
│                Emulator.ca Systems                          │
├─────────────────────────────────────────────────────────────┤
│  SYNTAX: <FORM args> for commands, (props) for data        │
├─────────────────────────────────────────────────────────────┤
│  WORLD BUILDING                                             │
│    <ROOM name (DESC "...") (EXITS (dir room))>              │
│    <OBJECT name (DESC "...") (LOC room) (FLAGS ...)>        │
│    Directions: NORTH SOUTH EAST WEST UP DOWN IN OUT         │
├─────────────────────────────────────────────────────────────┤
│  ROUTINES                                                   │
│    <ROUTINE name (args) body...>                            │
│    <RETURN value>   Return a specific value                 │
│    <RTRUE>          Return true                             │
│    <RFALSE>         Return false                            │
├─────────────────────────────────────────────────────────────┤
│  CONDITIONALS                                               │
│    <COND                                                    │
│      (<test> body...)                                       │
│      (ELSE body...)>                                        │
├─────────────────────────────────────────────────────────────┤
│  OUTPUT                                                     │
│    <TELL "text" CR>     CR/CRLF = newline                   │
│    <TELL N score>       N = format number                   │
│    <TELL D object>      D = object description              │
├─────────────────────────────────────────────────────────────┤
│  VARIABLES                                                  │
│    <SET var value>    Set local variable                    │
│    <SETG var value>   Set global variable                   │
├─────────────────────────────────────────────────────────────┤
│  ARITHMETIC (+ and - only; no * or /)                       │
│    <+ a b>    Addition         <- a b>    Subtraction       │
├─────────────────────────────────────────────────────────────┤
│  EQUALITY (no <, >, <=, >= operators)                       │
│    <EQUAL? a b>    True if a equals b                       │
│    <EQUAL? a b c>  True if a equals b or c                  │
├─────────────────────────────────────────────────────────────┤
│  OBJECTS                                                    │
│    <MOVE obj dest>    Move object to room/container         │
│    <REMOVE obj>       Remove object from play               │
│    <IN? obj loc>      Test if object is in location         │
├─────────────────────────────────────────────────────────────┤
│  FLAGS                                                      │
│    <FSET? obj flag>   Test if flag is set                   │
│    <FSET obj flag>    Set flag to true                      │
│    <FCLEAR obj flag>  Clear flag (set to false)             │
├─────────────────────────────────────────────────────────────┤
│  BOOLEAN LOGIC (no short-circuit evaluation)                │
│    <AND expr expr>    True if all true                      │
│    <OR expr expr>     True if any true                      │
│    <NOT expr>         Inverts truth value                   │
└─────────────────────────────────────────────────────────────┘

Appendix B: Troubleshooting

Problem: The interpreter displays a syntax error after entering a command.

Solution: Check that brackets are balanced and correctly used. Forms (commands) use angle brackets <>, while property lists use parentheses (). Every opening bracket must have a matching closing bracket. A common mistake is using parentheses for forms: (TELL "hi") should be <TELL "hi">.

Problem: A routine runs but produces no output.

Solution: Ensure your routine includes TELL statements to produce visible output. Without TELL, a routine may execute correctly but display nothing to the terminal.

Problem: IN? always returns false even though the object should be in the location.

Solution: Verify the object's LOC property matches the room name exactly. Names are case-sensitive in SLP-ZIL. If you defined <OBJECT LAMP (LOC kitchen)> but test <IN? LAMP KITCHEN>, the test will fail.

Problem: The terminal becomes unresponsive after running a routine.

Solution: You may have created an infinite loop. Press ESC to interrupt the currently running routine and return to the prompt. Review your code for loops that lack a termination condition.

Problem: MOVE does not seem to relocate the object.

Solution: MOVE changes the object's location but does not automatically update descriptions. After <MOVE APPLE PLAYER>, the apple is now "in" the player—subsequent <IN? APPLE KITCHEN> tests will return false. Use conditional TELL statements to reflect the new state.

Problem: Global variables set with SETG are not visible in routines.

Solution: Ensure you are using SETG (not SET) for global variables. Variables created with SET are local to the current routine and are not accessible elsewhere.

Appendix C: Glossary

COND — The conditional construct in ZIL, evaluating clauses in sequence until one succeeds. Similar to "if-else-if" chains in other languages.

Container — An object that can hold other objects. In the full ZIL specification, containers have capacity limits and can be opened or closed.

DESC — The description property of a room or object, containing the text displayed when the player examines it.

Implementor — Infocom's term for the programmers who wrote interactive fiction using ZIL. The title acknowledged their role as builders of virtual worlds.

Interactive Fiction — A genre of computer game consisting primarily of text, where players type commands to interact with a simulated world. Also called "text adventures."

LOC — The location property of an object, specifying which room or container currently holds it.

MDL — The MIT Design Language, a Lisp dialect from which ZIL was derived. MDL provided the syntactic foundation for ZIL's list-based structure.

Routine — A named block of ZIL code that can be called to perform an action. Routines may accept arguments and return values.

Room — A location in the game world that the player can occupy. Rooms have descriptions and exits connecting them to other rooms.

Z-machine — The virtual machine that executes compiled ZIL code. Infocom developed the Z-machine to allow their games to run on many different computer platforms. (Not implemented in SLP-ZIL.)

ZIL — Zork Implementation Language, the programming language created by Infocom for developing interactive fiction. Named after Zork, the company's first and most famous game.

Design Tips for Adventure Games

Creating a good adventure requires more than technical knowledge—it requires craft. These principles guided Infocom's Implementors and remain relevant today.

Start Small — Begin with a handful of rooms and objects. Get the core mechanics working before expanding. A polished three-room game is better than a buggy thirty-room maze.

Every Object Should Matter — If the player can pick something up, it should be useful somewhere. Infocom games famously avoided "red herring" objects that existed only to confuse.

Reward Exploration — Hide treasures, easter eggs, and interesting descriptions in out-of-the-way places. Players who examine everything should find something worth finding.

Test Your Puzzles — A puzzle obvious to its creator may be impenetrable to players. Have someone else try your game. Watch where they get stuck.

Write Vivid Descriptions — The text IS the game. Take time to craft room descriptions that establish mood, hint at puzzles, and reward close reading.

Consider Multiple Solutions — When possible, allow more than one way to solve a puzzle. Players feel clever when they find an alternative approach.

Fail Gracefully — When the player tries something that does not work, give them useful feedback. "You can't do that" is less helpful than "The door is locked" or "The torch is too wet to light."

Further Exploration

SLP-ZIL provides a foundation for understanding how interactive fiction works. To go deeper:

• Study the original Infocom games (many are available for Z-machine interpreters)
• Read "The Craft of Adventure" by Graham Nelson for design philosophy
• Explore modern IF tools like Inform 7, which evolved from ZIL's descendants
• Join the interactive fiction community at ifcomp.org and intfiction.org

The golden age of text adventures may have passed, but the art form lives on. Perhaps you will create the next memorable adventure.