Zzrk - Adventures in the Great Unsaturated Grammar

What is it?

Zzrk is a toy text adventure (or, if you prefer, a toy work of interactive fiction) written in "pure" Zz — assuming such a concept makes any sense. Zz is a dynamic meta-language designed for the APE parallel computing project to enable variants on languages such as FORTRAN to be quickly developed. As such, Zz maintains very little distinction between the language definition level and the language use level. For this reason, it might be more accurate to describe Zz as a self-modifying grammar.

Since Zz is typically used to define programming languages, I thought it would be a nice abuse to try to use it to write an actual program (albeit a very language-like one.) The result is Zzrk.

Playing the Game

First, you need an implementation of Zz. The only one I've found, and subsequently the one I've written Zzrk around, is OpenZz. It can be gotten from http://openzz.sourceforge.net/.

Although OpenZz does have an interactive mode, it unfortunately assumes you're using Zz to describe a compiler. Since I assume you'll want to play Zzrk interactively (as opposed to typing the sequence of actions you want to take into a text file, piping it through Zzrk, and seeing what happens), here's a guide to working around some of OpenZz's drawbacks.

First, you can't just specify zzrk.zz as the input to ozz. Instead, start OpenZz, then at the ozz> prompt, type

/include "zzrk.zz"

You can then treat the ozz> prompt as the prompt for the adventure game parser. Try the usual actions, and see what happens. Be forewarned that any unrecognizable command on your part -- an unknown verb, noun, or other part of speech -- will trigger a syntax error. And, because OpenZz thinks you are the input to a compiler, accumulating 10 of these errors will actually cause OpenZz to quit!

The Game Itself

The game itself is embarrassingly simplistic, but there are a few nominal puzzles just to demonstrate that the standard adventure game furniture can be concocted in Zz. Collecting treasures will get you points, and obtaining 50 points will win the game (that is, if you have 50 points and you type score, you will get a message telling you that you have won. You will still need to quit OpenZz through some other manual action, such as typing Ctrl-D, or causing syntax errors.)

Comments

I originally wrote zzrk.zz on November 21st, 2003. I gave it actual puzzles, wrote this readme, and released it under a BSD license on May 6, 2007.

A couple of annoying things about Zz...

The documentation for OpenZz doesn't mention that the /if { } construct has a variant that takes an else clause. And, /return does not actually cause an immediate return, it only assigns a value to the nonterminal under consideration. For these reasons, I was originally writing many of my tests twice (like /if a == b {} /if a != b {}). Then I noticed, in examining the results of /krules, that the kernel does in fact support else. The fact that curly braces actually denote lists means they're not optional in tests though, and the nesting is still pretty annoying.

The other annoying thing is that there's no way to prioritize selection of nonterminals. For example, I feel very strongly that it ought to be possible to write the score_of production like this:

/$num_t -> "score_of" coin     { /return  5 }
/$num_t -> "score_of" jewel    { /return 10 }
/$num_t -> "score_of" sceptre  { /return 15 }
/$num_t -> "score_of" crown    { /return 20 }
/$num_t -> "score_of" object^$ { /return  0 }

On the basis that coin et al. are more specific than object^$, and should be selected before it. But, it's not possible to set this up, at least as far as I can see. Which is a pity, because this sort of "catch-all" mechanism would also enable much better error handling.

A couple of nice things about Zz...

The parser-oriented approach is, of course, very nice for an adventure game. It was very simple to create a parser which is in some respects sophisticated: it can understand "pick up the key" just as easily as "get key". Even nicer is that the scope rules (verbs that apply only to objects that are being held, are in the same room, or either) are implemented directly as productions in the grammar.

Changing the grammar of the language you are using on the fly can be very scary, but also very powerful. Note that until you learn what the magic word is, you can't even use it without causing a syntax error. But afterward it is a full-fledged part of the parser's vocabulary. Note also that this is how the properties of an object are updated: the production which handles e_exit square_room is replaced by one that returns a different value, once the door is open.

Some of the action productions are a bit clumsy because they contain logic that should probably be associated with the object instead. Putting lists of statements in a property of the object, and using Zz's /execute facility, would probably allow a "method-like" style that permits this, but I haven't played with it.

Lastly, it's interesting to note that internal helper functions (not to mention the full complement of OpenZz builtins) are all available to the player during the course of the game. For example, try

move player to chest

and see what happens. Even better, why not try

object snake "snake" "Eek!" wall wall wall wall "no" loc player
look
examine snake

Using Zz's notion of scopes, it might be possible to protect the internals from being invoked like this, but considering Zzrk is just a toy it hardly seems worth bothering.

Happy adventuring!

-Chris Pressey
May 6, 2007
Vancouver, BC