Jump to content

ZZT-oop

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Ralphy512 (talk | contribs) at 02:42, 17 January 2011 (Added that OOP stands for 'object oriented programming language'.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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. The name of the language is a play on ZZ Top, an American rock band.[citation needed]

Overview

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

Shortcomings

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.

Strengths

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

Syntax

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

Example

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. 

@Shooter
#GO WEST
:TurnAround
#GO OPP FLOW
:KeepMoving
?FLOW
#IF BLOCKED FLOW THEN TurnAround
#SEND KeepMoving
:Touch
'No need to keep the timer around anymore
#SEND InvisibleTimer:Die
#DIE
:ShootDownward
#SHOOT SOUTH
#SEND KeepMoving

@InvisibleTimer
'The #CYCLE command sets the rate at which this object is updated.
#CYCLE 40
:Loop
#SEND Shooter:ShootDownward
#SEND Loop
:Die
'Turn into a red wall
#BECOME RED SOLID


Retrieved from "https://en.wikipedia.org/w/index.php?title=ZZT-oop&oldid=408321319"