2 This document covers the Zork Implementation Language, or ZIL for
3 short, as originally developed and used by Infocom for their games.
5 ZIL is a subset of the MIT Design Language, or MDL for short, and
6 pronounced as "Muddle". MDL is itself based on classic LISP.
9 This document is written using CommonMark, a markup language. More
10 information about CommonMark can be found at <http://commonmark.org>.
12 ## Copyright And Licensing
13 Permission is granted to copy, distribute and/or modify this document
14 under the terms of the GNU Affero General Public License as published
15 by the Free Software Foundation ("FSF"), either version 3 of the
16 License, or (at your option) any later version published by the FSF.
18 You should have received a copy of the GNU Affero General Public
19 License along with this document. If not see
20 <https://gnu.org/licenses/>.
23 A "definition" is used to describe a room, object, routine, etc. in or
24 used by the game. Each definition consists of a number of properties,
25 flags, and/or instructions. A program written in ZIL can be thought of
26 as consisting of two or more of these definitions. At a minimum, a
27 program must define which version it is to be compiled for and contain
28 at least one routine named GO from which execution begins.
29 Definitions, properties, flags, and instructions include brackets
30 which must be correctly paired and nested.
33 Infocom made 6 versions of the Z-machine. The community made 2 more,
34 for a total of 8, mostly to support larger story files. To define
35 which version of the Z-machine a program is to be compiled for, it
36 must contain a VERSION definition at the top level, outside any other
37 definitions, in the following format, using this BNF-style syntax:
39 <version-definition> ::= "<" "VERSION" <version-number> ">"
41 <version-number> ::= "ZIP" | "EZIP" | "XZIP" | "YZIP" | "1" | "2"
42 | "3" | "4" | "5" | "6" | "7" | "8"
44 ZIP is equivalent to version 3, EZIP to version 4, XZIP to version 5,
45 and YZIP to version 6.
48 Comments are ignored by the compiler. A comment begins with a
49 semicolon (;) and continues until the end of the line. A multiline
50 comment also begins with a semicolon but is enclosed in double quotes.
51 However, single line comments may also be enclosed in double quotes.
52 While comments may be placed anywhere in a source code file, a comment
53 may not be placed inside an atom.
56 The purpose of the parser is to receive and process the player's
57 input. Its primary responsibility is to determine the player's
58 intended action along with any objects that may be referred to.
60 The player's action is referred to internally as the PRSA (think "A"
61 for action like "EAT", the direct object as PRSO (think "O" for
62 "object") and the indirect object as PRSI (think "I" for indirect.)
64 For an example, the command "KILL TROLL WITH SWORD" would set the PRSA
65 to KILL and the PRSO to TROLL and PRSI to SWORD. It is important to
66 note that not all instructions from the player will necessarily have
67 all three things, but a PRSA is required in all cases and you can't
68 have a PRSI without also having a PRSO. In cases where there is no
69 PRSI or PRSO, they are set to false.
71 Note that the PRSA isn't simply the word that the player entered. The
72 PRSA from a given sentence is determined by the syntax definitions in
73 the game. An example being: The player might type "CONSUME APPLE" but
74 in the game's syntax definitions, the PRSA associated with "consume"
78 Syntax definitions are used by the parser to determine valid sentence
79 structures. Each entry must correspond to this format:
81 A simple example might be:
83 <syntax xyzzy = v-magic>
85 Using this example, should the parser match the player's input to
86 "xyzzy" then the PRSA is set to magic. PRSI and PRSO would be set to