The year was 1996ish; the family computer, a Windows 3.1 pizza box with a 486 processor and CompuServe dial-up internet. In those days I would frequently monopolize it, sinking hours into whatever Apogee and Epic shareware games I could get my hands on. But since I couldn’t tie up the phone line with game downloads for too long, my dad would occasionally find something for me with his fast connection at the office, and bring it home on a good old 3.5″ floppy.

On one such occasion, I found myself the recipient of a well-worn disk with the cryptic string “ZZT 3.2″ scrawled on the label. Into the drive it went, and after a brief configuration prompt…

As you can probably tell from the above screenshot, ZZT is an ANSI-graphics top-down action-adventure-puzzle game. It was created in 1991 by Tim Sweeney, founder of Epic Games (then called Epic MegaGames), who went on to develop several notable shareware classics of the DOS era and became a key developer of the Unreal engine.

The registered version of ZZT came with four “worlds”, each a self-contained game that could be completed in a few hours. While these worlds remain iconic even today, and did much to establish the basic formula for “classic” ZZT gameplay, they are not the reason ZZT is so interesting.

Notice the Board Editor option in the screen above? If you haven’t guessed already, ZZT is in fact a complete game creation system. Using a wide variety of items, obstacles, and enemies, you can construct your own game worlds (stored in a “.zzt” file) and share them with others. You’re not limited to the built-in entities, either: ZZT has special generic entities called Objects that can take on any appearance, whose behavior is determined by a program written in ZZT-OOP, the “Object”-Oriented Programming language.

ZZT-OOP is a weird, restrictive little language. Among its oddities:

• You can’t create new objects at runtime; all the objects you want to use must already exist before the game starts (with one extremely limited exception)
• There are no methods, functions, or anything else that would imply a call stack
• The only flow control mechanism is “messages”, which are the equivalent of GOTO statements… except that code in one object can send a message to another object, causing that object to unconditionally jump to a different point in its program
• There are no statement blocks; the “if” command (which is the only method of conditional flow control) jumps to a specified program location if the condition is true, and falls through to the next statement if it’s false
• The only variable type is boolean, and you can’t have more than ten of them set to true at the same time
• All objects on a “board” (game screen) execute their code simultaneously, but objects on other boards cannot be accessed, since a board’s state is frozen when the player leaves it

With this being the first programming language I learned, and QuickBASIC being the second, it’s a miracle I ever managed to wrap my brain around modern languages at all. But the truth is, ZZT showed me how much fun programming could be, by setting it in the context of a game. Type in some cryptic codes, press a key, and there’s a little smiley face running around trying to shoot you. Even the tiniest amount of effort yields instant results. This appealed to my ten-year-old attention span, and though I never finished any worlds of my own, ZZT permanently lodged a favorable impression of programming in the back of my brain.

Needless to say, I wasn’t the only ZZT fan out there. Since the game’s 1991 release, aspiring game creators have cooked up thousands of ZZT worlds, each one pushing the limits of the engine further than before. Glitches were discovered that, if properly exploited, allowed one to do previously impossible things, like making an object move diagonally or teleporting the player to an arbitrary location. The world file format was reverse-engineered and new editors were created, far surpassing the game’s built-in editor. Ingenious coders transformed ZZT from a top-down action-adventure game into a sidescroller, an RPG, a stealth game, and many other genres.

As complex as some of the community’s later works were, I’d say the reason ZZT was so successful and long-lived was its simplicity. The simplicity of the text-mode graphics and PC speaker sound effects precluded the possibility of a lengthy media creation process. The extreme simplicity of the scripting language, and the existence of a pre-built engine with a lot of basic functionality included, meant that it was easy to ignore the gritty details of making a game and focus on the actual gameplay. All of these things might seem like severe limitations (they are), but they also dramatically lower the barrier to entry for new world builders.

Relatively few games today are based on user-generated content to the extent that ZZT was, and even fewer have built-in scripting languages. In a 2007 interview, Tim Sweeney himself had these words to offer:

Tim Sweeney said:

I’ve always wanted to build a massive-multiplayer version of ZZT. In other words, a vast interlinked game world built and extended by users using simple ZZT-like tools. Like ZZT, it would be open-ended and community-driven. Players would be able to build their own levels and write scripts for objects, as well as play the game as a character, build up attributes and collect items.

Such a project would tackle all the key technical problems of MMO development without the complexity of a 3D environment. The data required for levels and motion data is also so simple that servers could be run by the community without significant bandwidth expense.

Alas, such a game wouldn’t be much of a Gears of War killer. So don’t expect it to actually happen. But it would be interesting!

Indeed it would, Tim. Indeed it would.

Some links for you:
Z2 is the largest archive of worlds and other ZZT-related downloads on the internet, though much of its textual content is outdated. Be sure to check the Featured Games list, which includes a lot of famous and influential games in ZZT’s history. DOSBox comes in handy for running ZZT on modern machines (>=10,000 cycles recommended). You might also want to check out ZZT’s vastly-more-powerful-but-also-more-complex spiritual successor, MegaZeux, which is still developed today.

Twittjr is a system that allows an IBM PCjr to search the public timeline on Twitter. In case you weren’t aware, Twitter is a social micro-blogging service introduced in 2006 and has over five million active users. The IBM PCjr is a personal computer introduced in 1984 and has a 4.77MHz processor, 128KB of RAM, and uses 360KB floppy disks for storage.

It seemed like a good idea at the time.

How does that even work?

Let’s say you have a PCjr hooked up to an external dial-up modem, which is connected to a phone line. Elsewhere, you have a modern internet-connected computer (call it the “server”) with another dial-up modem, connected to another phone line. The PCjr calls the server and establishes a modem connection, which it uses to send a request for whatever search term the user enters. The server uses the Twitter Search API to download the three most recent posts on the public timeline that match the search, and shoves them back over the phone line to the PCjr, which displays them on the screen in glorious 16-color ASCII-vision. In the absence of user interaction, the PCjr refreshes the search results every minute or so, providing a sort-of-live feed. 

Note that while a modern PC is involved, the PCjr is far from being a “dumb terminal” in this setup: I intentionally put as much work as I could on the PCjr side, and the server software is tiny in comparison to the pile of BASIC code that runs the client. The only things that aren’t done on the PCjr are the actual download from the internet (good luck cramming all those protocol stacks into 128KB of RAM!) and the XML parsing (which is possible, but not very fun, in BASIC). The two machines exchange data using a super-simple ”protocol” I made up on the spot.

The 5.25-inch floppy drive I installed in my desktop to transfer code for Twittjr

What’s the code written in?

The PCjr software is in Cartridge BASIC, which is essentially BASICA with some extra bits. Cartridge BASIC is the best of the three forms of BASIC that can be used on the PCjr (the others are Disk BASIC and Cassette BASIC), because the interpreter doesn’t take up system memory, it runs almost as fast as compiled code, and you can save your programs to disk. It does, however, require that you have A) the actual Cartridge BASIC cartridge, and B) a DOS disk to boot from.

The “server” software is a small Ruby script that uses only built-in libraries. It should work on any platform that can run Ruby, but I’ve only tested it on Linux.

Twittjr at ImagineRIT 2009

How did Twittjr get started?

As it happens, I’m a member of Computer Science House at RIT, and one day I discovered a fully-functional PCjr gathering dust on a shelf in one of our common rooms. Noticing that it used BASIC, which I was familiar with from my high school days, I figured I could write some eye-catching application that would attract people to our tables at the ImagineRIT innovation fair. Lots of CSHers had been joining Twitter recently, including myself, and someone who saw me fiddling with the PCjr suggested putting Twitter on it. Several weeks later, the first version of Twittjr was serving up tweets to curious open-house visitors.

Can I set this up on my own PCjr? 

Absolutely, as long as you have the following things:

• One IBM PCjr with DOS boot disk and Cartridge BASIC cartridge
• One of the following:
  • Internal PCjr modem installed (limited to 300 baud)
  • External serial modem with PCjr serial adapter to attach it
• A 5.25-inch floppy drive in your own computer, to copy the program
• A spare 5.25-inch disk (or use your boot disk if it’s writable)
• Any modern-ish PC to use as a server
• A modem for said PC that appears to your OS as a serial device
• A working installation of Ruby on said PC
• Two phone lines (at least one must be capable of calling the other)

And last but not least, you’ll need the Twittjr code package! It includes a README with basic setup instructions, so make sure you look that over before you start.

gets.chomp.strip.scan(/[^ "]+|"[^"]+"/).map{ |s| s.delete('"') }

This takes a line from standard input and splits it into a space-delimited argument list, with support for quoted arguments that have spaces in them. If you enter 'command with "some parameters"', you’ll get the array ["command", "with", "some parameters"]. Not particularly advanced, but maybe useful.

Recently I’ve been getting my new project, “Twittjr” (a mashup of Twitter and an IBM PCjr), ready to attract people to the CSH booth at GCCIS for ImagineRIT. Coding in Cartridge BASIC on a PCjr is simultaneously a fascinating and frustrating experience. On the one hand, it’s kind of annoying to not have any modern conveniences like, say, functions. But on the other hand, it’s sometimes fun to go through the weird brain contortions required to actually do things with Cartridge BASIC.

One of the interesting things about BASIC (at least in this ancient incarnation) is that it’s much more relaxed than modern languages regarding where you can send its thread of execution. Of course, you only have one thread, so you have to make the most of it. For example:

10 ON TIMER(30) GOSUB 1000: TIMER ON
20 WHILE 1
30 ' Do something continuously
40 WEND
...
1000 ' Do another thing
1010 RETURN

Initially this will just go straight into the WHILE loop and do its thing. But every 30 seconds, code execution will hop right out of that loop and jump over to line 1000 for the subroutine. If you’re doing something really important in the loop and you don’t want to be interrupted, just TIMER STOP before the important bit and TIMER ON afterward. It’s an extremely simplistic way of doing things, and doesn’t take much effort to write, but it also has a number of obvious issues that wouldn’t come up in a threaded environment (e.g. stalling in the subroutine will make the entire program lock up).

Of course, the vast majority of things you might try to do in BASIC are just plain unreasonably difficult. Subroutines don’t take parameters, so global variables are the only way to pass data between different parts of your program (not that there’s any variable type other than global). String manipulation is really fun because literally all you can do is A) Find the position of the first occurrence of a substring within a string, B) Extract a substring from a string based on character offsets, and C) Get the length of a string. Technically you can do everything with those operations that you could do with, say, regular expressions, but try anything more complex than splitting a string into an array and your code starts to look like spaghetti.

At any rate, Twittjr is almost ready for the innovation fair tomorrow; all it needs is some better word wrapping and I can probably call it v1.0. The full project write-up will be posted soon, and I’ll add the code itself a bit later.

If you perceive a slight edge to my voice at this point, it’s not your imagination. Though I recognize Python’s wild popularity, I respectfully disagree with certain aspects of its implementation. As such, when I started looking around for a new and hopefully useful language to learn, I chose Ruby instead. Most of my friends have indicated to me, in no uncertain terms, that they think I have made a terrible mistake. After working with Ruby for some time, although I’m certainly not ready to move away from it, I begin to see where they’re coming from.

Ruby, for better or worse (actually just worse), is something of a second-class citizen in relation to Python. There are a number of logical and well-established explanations for this: Ruby’s development lags Python by a few years due to its later introduction date; Ruby’s documentation is often difficult to locate and navigate; Ruby is just plain slower than Python for many non-trivial tasks (though 1.9 improves on this); compiling native extensions for Ruby on Windows is practically guaranteed not to work; and until very recently, Ruby didn’t have built-in support for Unicode strings, which is kind of important if you’re pushing for a global user base. Even in those areas where Ruby is improving, it’s turning out that Python is too entrenched already for those improvements to make a difference. Python came first, and there ain’t room in this town for another language that has basically the same features.

At this point you might be asking what’s so bad about Python that I would instead voluntarily use a language I just described a minute ago as a “second-class citizen”. One reason is my personal belief that, conceptually, Ruby is a better (albeit less mature) language than Python. Another reason is the syntax, and I will defend to the death my opinion that Python’s use of the Off-Side Rule is unbelievably boneheaded and makes code ten times harder to scan due to the complete lack of block terminators (not to mention the ease with which Python code can be irretrievably mangled if anything so much as sneezes on all your leading spaces). The really annoying thing about this is that the Off-Side Rule is not a required language feature to accomplish any of the cool stuff that Python can do. It’s just an arbitrary limitation with no solid rationale behind it.

Of course, at the end of the day, no matter how much I personally dislike the way Python does things, it’s still the more popular language. And given Ruby’s various failings, I’m not exactly surprised. For now, I guess I’ll just keep tinkering around with my little second-class language, and hope it eventually develops some of that secret sauce that makes everybody love Python.