(which I will not be able to participate in on the day, unfortunately. I am still keen, though, so I might just make something anyway.)
ZZT is... uhmm... crap. But that's not necessarily a bad thing. You see, if it wasn't crap, it would be quite inflexible, and therefore it would be the bad sort of crap.
Because ZZT is somewhat crap, you need to pay close attention to what I'm about to say as you may break things if you don't.
The ZZT-OOP parser is just bloody weird. There's a lot you can do if you know what you're doing. But if you don't know what you're doing, bad things can happen.
Here are at least some of the snags you'll need to be wary of.
- Names of labels, objects, and flags should not have numbers in them - the parser is weird. Sadly, I have forgotten exactly how the parser deals to these, so, um, just don't use numbers.
- A label cannot go on the very first line of your code.
- #restore will restore the first zapped label from the top, not the bottom. Be wary of this!
- Comments (') are actually zapped labels (:).
- ZZT runs its program code in text form. You're right; it's not efficient.
- #cycle 1. Seriously. Just do it. Anything else will behave unpredictably when you pause / unpause. Also, if Saxxon is to be believed, the tick counter wraps around at 420.
- Speaking of pause... weird stuff happens when the game is paused! For starters, if the player is trapped, and then decides to pause, ZZT effectively freezes.
- Much like how GReg JAnson doesn't know how to spell "gaurd", Tim Sweeney spells "alligned" with two Ls.
- You have 20KB available per board. Use it wisely. (I don't know if this includes the compressed or uncompressed 60x25 board layout.)
- You also have a somewhat arbitrary world size limit which is something like 380KB. ZZT behaves horribly if you run out of memory. Even then, KevEdit can segfault while saving. Back your games up!
- You cannot #put things on the bottom row. Sorry guys.
- You have enough space for 10 flags. If you exceed this... I forget what happens. You can check if this limit has been reached by doing "#if #dosomething" (if it hasn't, do something) or "#if not #dosomething" (if it has, do something).
- To place the player in the ZZT editor or KevEdit, use F1 Z. Copying and pasting the player will result in what is known as a player clone (these can also be made using #put player and stuff like that). Player clones are necessary for a lot of ZZT tricks, but you most likely don't want to be placing these by accident.
- There are several amusing ways to crash ZZT. Avoid them when you're not trying to crash ZZT. Here are some ways to crash ZZT.
- Spamming a scroll with lots and lots of text using a loop.
- Duplicating a player clone onto something pushable.
- Putting #become or #die or movement commands in a scroll, the latter of which is quite amusing.
- Accessing (or maybe simply having) a really, really large board. Keep your code size down!
- Having illegal tile IDs on a board (not explored).
- Touching blinking text, a won't-crash-immediately series of illegal tile IDs. There's a reason why KevEdit doesn't let you make blinking text easily, and this is it. (I think.)
Be wary of the stat order; that is, the order that things are processed. Some things will screw up. Pressing Ctrl-T in KevEdit will tell you what the "Stat index" of a thing is, and also allow you to add and remove stats.The Koopo trick (duplicating a player clone onto a passage) has a well-known bug which will set a thing's parameters and cycle to 255. It's either based on the player clone, the duplicator, or the passage - you can look that one up yourself if you want.
If an object does #die or something like that, the object after it in the stat order will move according to its "direction". This even affects things which use the direction but aren't supposed to move, like transporters and laserwalls. This does not care about the following object's cycle counter. So, if something "dies" and something else randomly moves, you might need to look at the stat order.
Oh yeah, also, use KevEdit.