ZZT-oop

ZZT-oop was an early in-game scripting language programming language, designed by Tim Sweeney (game developer), for his computer game ZZT.

=Overview=

ZZT-oop is object-oriented and event-driven. A ZZT game is composed of a set of objects, each of which has an attached script. Scripts are executed concurrency (computer science) (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 very limited in application, to say the least. It was designed for simplicity rather than flexibility. Boolean flags are the only kind of variables, making arithmetic nearly impossible; therefore 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 is 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 and frustrating.

==Strengths==

However the language does have some advantages, its simplicity and intuitiveness for one, its lack of mathematical operators and integration within a fun game makes it very nonthreatening to budding programmers at any stage of life. The physical nature with a concrete geographic position makes objects far easier to visualise than abstract data types, and the parallel operating multi Thread (computer science) 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, 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. *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 (command) 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 **#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 **#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; 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 wall #BECOME SOLID

=Closing thoughts=

ZZT-oop provides a great stepping stone into programming for anyone with limited knowledge of such things. It can provide one with many hours of fun, but very little else.

=External link=

*[http://dave2.rocketjump.org/rad/zzthelp/langref.html Online version] of the ZZT-oop reference included with the game