World Library  
Flag as Inappropriate
Email this Article


Article Id: WHEBN0000347071
Reproduction Date:

Title: ZZT-oop  
Author: World Heritage Encyclopedia
Language: English
Subject: Epic Games, Titan Studios, Infinity Blade II, People Can Fly, Chair Entertainment
Publisher: World Heritage Encyclopedia


ZZT-oop was an early in-game scripting programming language, designed by Tim Sweeney, for his computer game ZZT. The name stands for ZZT Object Oriented Programming language.


ZZT-oop is event-driven. A ZZT game is composed of a set of objects, each of which has an attached script. Scripts are executed concurrently (one command being taken in turn from each script running on the current screen), and objects communicate by passing messages to one another.

Peculiarities and limitations


The ZZT-oop language is limited in application. It was designed for simplicity rather than flexibility. Boolean flags are the only kind of variables, making arithmetic quite difficult; the programmer is forced to be creative with algorithms, often relying on physical movement, possibly in invisible (but still physically present) objects, rather than arithmetic calculations.

Although ZZT-oop calls itself "object-oriented", objects are not instantiable due to their physical nature, meaning that one needs to duplicate much code to create complex systems.

ZZT-oop also lacks functions, and routines are likely to be interrupted by rogue messages — including ones sent by the object itself when it is shot or touched — and never completed. It is possible to overcome this disadvantage in a crude manner by using state flags or the lock and unlock commands during important routines; however, this is likely to cause the object to miss out on signals.

ZZT-oop is wholly run-time interpreted with no pre-parsing. No lexical analysis is performed before running, nor is any byte code translation applied. This means that any errors are reported in a cryptic way during run-time, and this can make debugging time consuming.

ZZT was intended for creating adventure games with multiple "boards" (that is, locations), but ZZT-oop does not have any way of creating state that persists from one board to the next, with the exception of boolean variables. A board's objects are only accessible while the player is on that board, and pause on board exit until the player reenters.


The language has some advantages:

  • ZZT-oop is accessible for beginning programmers. It is simple and intuitive and lacks mathematical operators. This helps beginners to learn the language without frequently needing to consult guides.
  • Integration within the game makes the language easy to use. Beginners do not need to install multiple programs to start programming. Concrete geographic positions make objects far easier to visualise than with abstract data types.
  • Parallel operating multi-threaded design is easy for one to think about in terms of a dynamic environment


The syntax of the language is exceedingly simple. It is line-based, and the first character of each line determines that line's effect.

  • The first line of the program may be prefixed with @, which gives the object a name. Objects without names cannot receive messages from other objects via the #SEND command (except for #SEND ALL:label and #SEND OTHERS:label), since there's no way to refer to them.
  • Unprefixed instructions, or instructions prefixed with $ or !, cause the object to open up a message window and display text to the player.
  • Instructions prefixed with ' indicate comments (really, they are pre-zapped labels).
  • Directions prefixed with / or ? instruct an object to attempt to move in the specified direction. Possible directions include North, South, East, and West, as well as SEEK (to move toward the player) and prefixes such as CW (meaning clockwise, such that CW N means east).
  • Messages are similar to the goto statement in declarative languages; the only difference is that they may optionally be sent to another object and cause that other object's own execution path to jump to that point in the script. The points that may be jumped to, called labels, are prefixed with a : and are used to denote both what the name of the message is, and where the object's control should jump when that message is received.
  • Flags are global boolean variables used for conditionals that may only be set or cleared with commands. If the #IF command is called on a given flag variable, then the flag will be evaluated; if it is set to true, the message listed after will be sent, causing the script to jump to that point.
  • Instructions prefixed with # specify commands, which control all interactions with the environment, whether it be shooting, setting a flag, sending a message or processing a conditional. There are dozens of primitive ZZT-oop commands, including
    • #SEND, which sends a message to another object
    • #SET and #CLEAR, which manipulate the values of flags
    • #LOCK, which renders the object deaf to incoming messages, and #UNLOCK, which reverses the operation
    • #PUT, which creates a new object of a specified type and places it next to the current object
    • #BECOME, which causes the current object to become some kind of item or creature, thus ending its programmable lifetime (#DIE acts like #BECOME EMPTY)
    • #ZAP, which replaces the : preceding some label with ' (thus turning the label into a comment), and #RESTORE, which reverses the operation


The program below illustrates a simple "shooter" object that will move back and forth horizontally (east to west), periodically shooting downward (to the south). (If the player is shot, the player will lose health.) If the player touches the shooter, the shooter will be destroyed.

Note the use of an invisible "timer" object to send a periodical ShootDownward message to the Shooter. The timer's program would normally be attached to an object whose graphical representation was the same as a wall (character number 219); then, it would go completely unnoticed by the player, since it does not move and turns into a real wall when its program ends.

#SEND KeepMoving
'No need to keep the timer around anymore
#SEND InvisibleTimer:Die
#SEND KeepMoving
'The #CYCLE command sets the rate at which this object is updated.
#SEND Shooter:ShootDownward
#SEND Loop
'Turn into a red wall

External links

  • Online version of the ZZT-oop reference included with the game
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.