ZZT-OOP/Printable version

ZZT-OOP

The current, editable version of this book is available in Wikibooks, the open-content textbooks collection, at
https://en.wikibooks.org/wiki/ZZT-OOP

Permission is granted to copy, distribute, and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 3.0 License.

Introduction

ZZT-OOP is a primitive object-oriented scripting language used by the DOS game creation system ZZT. The language was created by Tim Sweeney of Epic MegaGames (now Epic Games).

History of ZZT

ZZT was made in 1991. It was Epic's first release; although it was not terribly successful, it did gain some attention. After version 3.2 (the version considered to be the "official" ZZT), Tim Sweeney discontinued development, moving on to other projects, such as Jill of the Jungle. A sequel to ZZT with more advanced features was made, called Super ZZT, but it never had the success of its predecessor. The source code for the original was lost, putting a stop to the development of any further versions, although it was eventually reconstructed through reverse engineering many years later in 2020.

In 1997, Epic decided to release ZZT and the four games that came with it as shareware, due to the program's being severely outdated in both graphics and sound. Despite its age, ZZT continues to draw a following, and an online community based around it still exists today. Many attempts have been made in recent years to improve the program, ranging from hacking the ZZT executable itself to writing emulators that work like ZZT, except with a few new features. ZZT has even inspired various other fan-created game creation systems, such as ZIG and MegaZeux. However, the original ZZT 3.2 continues to be the most widely used.

Overview of ZZT

The ZZT-OOP language is an integrated part of ZZT; as a result, in order to write a program in ZZT-OOP, you must have some familiarity with ZZT. ZZT is not playable by itself; it is an interpreter through which ZZT games can be played. These games, called worlds, usually have all their code contained in one file with a .ZZT extension.

World Structure

The space in each world is divided into segments called boards. The display size of a board is fixed in size, and the player can only view one board at a time. However, these boards can be linked together to create the illusion of a continuous landscape. To clarify this concept, suppose that you were designing some dungeons in ZZT. The entrance to the dungeons would be on one board. The entrance on this board might link to a second board that contained the first rooms of the dungeons and a staircase. The stairs would link to a third board, which would contain part of the underground dungeons. This board might link to yet other boards that contained adjacent dungeon rooms, and so on. Note that scale is not always kept consistent; for example, each dungeon board might only contain a few rooms, while the board containing the dungeon entrance could be made into a zoomed-out map of everything else in the area. When a player leaves the board he or she is on, the board disappears from view, replaced by the board that he or she has moved to.

Every board in a world file is playable with the exception of the first board in the file. This board is called the Title Screen because it is the first board that the user sees when he or she loads your game. Because the player cannot actually play it, the Title Screen is usually used as a splash screen for the game; however, ZZT-OOP code will still run, which allows simple animation and even introductory cutscenes to be displayed.

Board Structure

The terrain on each board is based on a 60 by 25 grid of tiles. Each tile is a block on the screen that has a certain appearance and properties. Because ZZT runs in text mode, each tile is character sized, takes the appearance of one of the 256 ASCII characters, and has both a foreground and background color. Terrain limits the movement abilities of the player, but it is often used just to create an interesting backdrop. Although the word "terrain" implies an outdoor setting, it is also used for constructing indoor features, such as walls. The terrain can range from a simplistic box that represents a room to a more decorative, organic board; using different colors of terrain, it is even possible to draw simple pictures.

Tiles are not limited to representing terrain; various items and creatures can also be put onto boards as well. A detailed list of all tile types is beyond the purposes of this introduction; however, one of the most useful tile types will be mentioned here; the object. Objects are important because, unlike most of the other tile types, object tiles can contain ZZT-OOP programs. This allows the world designer to customize object behavior. For example, say you wanted to fill a dungeon full of monsters, but you did not want to use ZZT's built-in enemies. After designing the dungeon and laying down the proper terrain, you would add several objects to the board. You would then write a ZZT-OOP program that would instruct them on how to attack the player; how to write such programs is the subject of this book.

Reasons to Learn ZZT-OOP

There are several reasons for learning ZZT-OOP:

• ZZT-OOP is necessary for writing an original ZZT game. Although it is possible to make ZZT games without knowing ZZT-OOP, one is restricted to only using the preprogrammed items and enemies.

• ZZT-OOP is a good introductory programming language. Although you couldn't turn programming in ZZT-OOP into a career, it is a fun and easy way to learn the basics of programming.

• ZZT-OOP (and ZZT) is a fun hobby. Writing games for ZZT is a nice medium for expressing your creative self, and it's not hard to go online and find somebody who will play your games.

• ZZT-OOP is restrictive, but in a fun way. Because the language was only meant for simple adventure games, code that would be easy in other languages becomes a challenge in ZZT-OOP. However, some of us live for such challenges, and although it won't get you a date or a job, being able to code complex things - a fractal generation program, for example - using only an archaic game creation system is rather impressive.

Syntax

ZZT-OOP has a very simple syntax, as demonstrated by the following example:

@Fred
'Objects run their programs right away;
'the following command will temporarily
'halt program execution.
#end
:touch
$This is an object named Fred!
!move;Tell Fred to move around.
#end
:move
/rndp rndne/rndp rndne
?n?n?n?n?s?s?s?s
FRED: I moved around!

The first character of each statement determines how the rest of the line is treated. For example, the first line begins with the "at" symbol (@), which makes it a name; the second line begins with an apostrophe, which makes it a comment, etc... Our discussion of ZZT-OOP syntax continues with a list of all the possible starting characters and their effects.

' (Comment)

This is a comment, it does nothing but inform you or whoever looks at your code what a function does. If you have a very large file (>320KB), get rid of any of these you may have (not including ones used as zapped labels). Also: this statement isn't a comment in fact, but a pre-zapped label (that means you can jump to it only after you restored it)

(Text), $(Text)

This prints a line of text at the bottom of the screen, or if there is more than one line, print a scroll. Using $(Text) prints text in a scroll centred and in white.

:(Label)

This is a label. You can jump to labels. Yes. You can also make other programs jump to labels.

!(Label);(Text)

This prints a line of text in a scroll in white with a pink arrow as a bulletpoint. This is an option. Selecting it will call the label given.

@ (Object Name)

The "@" character indicates that the rest of the line is the object's name. In the example above, the line @Fred gives the object the name "Fred." The only limit on object names is that they must be stated on the first line of the program; "@" statements elsewhere in the file are ignored.

If a named object opens a text box, the object's name appears at the top of the textbox, replacing the generic title "Interaction." It is not necessary to give an object a name.

# (Generic Command)

The "#" character indicates a command, or a jump to a label. For example, the example program uses the command #end to stop program execution. Many other commands exist; they will be discussed in detail in the next couple of chapters. For now, it is good enough to know what they look like.

/ and ? (Movement)

The "/" character instructs the object to move. The direction that the object moves is indicated by the text that follows; for example, /n causes the object to move one space to the north (move up one space). When "/" is used and the object cannot move in the specified direction, the object will simply wait until it can move in that direction; this results in the object waiting forever if it is facing something that does not move, such as a wall. The "?" character works like "/", but with one difference: "?" movement commands will be ignored if the object cannot move in the specified direction.

Both "?" and "/" are unique because they can be "stacked"; this means that a movement instruction can be followed by another statement. For instance, in the example program, you saw the code ?n?n?n?n?s?s?s?s. When this code runs, the movement instructions will be followed from left to right; the object will try to move four spaces upward, then four spaces downward. Types of statement can be mixed; for example, it is perfectly alright to say /n?n?n/n or even /n/n/s/s#end. However, you cannot stack a statement onto a non-movement statement. That is to say, /n/s/e/w#end is valid ZZT-OOP, but /n/s/e/w#end/n is not.