Grantovich.net

Since my introduction to Ruby by way of talking foxes and chunky bacon, I’ve been fascinated with the works of the enigmatic “why the lucky stiff”, also known as _why. He became famous throughout the Ruby community for his eccentric demeanor and numerous quirky projects, all of which excellently demonstrated the power and beauty of the language in a way few others could duplicate. And despite the fact that he has appeared and spoken in public, very little is known about his true identity.

I recently thought of using Shoes, _why’s minimalistic GUI toolkit, for a project, and found that the domain wouldn’t resolve. At the time, I thought it was nothing more than a glitch in the Matrix. Had I searched around, I would have discovered much earlier the surprising truth: On August 19th, “why the lucky stiff” winked out of existence, taking everything he’d ever created with him. All of his web sites, his projects, his github account… gone, with no explanation.

Given that the man himself is unavailable for comment, theories abound as to why (or rather, _why) he departed so suddenly, and with so many of his projects left half-finished. Personally, I think it’s possible that _why planned to do this right from the start, as an exercise in “lifting up” the Ruby community and bringing it closer together; observe how quickly his many projects have been picked up by others, who have started developing them at a remarkable pace. _why’s departure created a tremendous vacuum of talent, one that dozens of Ruby hackers are now eager to fill. Was this the intended effect? It certainly seems to be a Good Thing… though I don’t think the sheer personality that _why gave Ruby will ever be duplicated.

I sometimes say that QuickBASIC was the first programming language I ever learned. This is a half-truth; a shortcut that allows me to avoid a lengthy explanation of what ZZT-OOP is, and how it was really the first programming language I ever learned. But since this is my blog and not a casual conversation, we have a bit more room for exposition. Read on, if you’re curious about languages and game development: ZZT is quite an interesting piece of history.

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.

While the latest version of Microsoft’s much-maligned browser did fix a menagerie of rendering bugs in the process of introducing full CSS 2.1 support, it unfortunately introduced one glitch that will probably have you scratching your head the first time you see it.

The bug is this: If you have a textarea with a width specified as a percentage (most commonly 100%), and there’s enough text in the textarea to cause it to scroll, the textarea will scroll up by a few lines for each character you type, only stopping when the line you’re editing reaches the bottom of the box (or the scrollbar reaches the uppermost position). Sometimes, when deleting text, it even scrolls up further than that, leaving your cursor somewhere outside the visible part of the textarea. Sounds fun, right?

Since the bug didn’t exist before IE8, it can be repaired by activating Compatibility View, which sends the page through the old IE7 engine instead. If you’re already doing the extra bit of work to accomodate IE7 users, this might not be a half-bad solution. But if you want to avoid regressing to an earlier version of IE and dealing with all the CSS hacks that implies, I recently found an alternate solution courtesy of the Simple Machines forum developers.

The bug is triggered when the CSS “width” property (and only that property) is set to a percentage. So how do you set width without setting “width”? By setting min-width and max-width to the same value! It looks a bit odd, but it’s perfectly standards-compliant and should be interpreted correctly by all major browsers. Do it like this:

textarea {
  width: 700px;
  min-width: 100%;
  max-width: 100%;
}

Note that the explicit non-percentage “width” value is required to avoid triggering the bug; it gets overridden by the other two properties anyway.

If you need to support IE6 (which I strongly recommend not doing unless human lives are on the line), you must keep in mind that it doesn’t understand min- and max-width, and will set the textarea to the fixed width you specify. If you’re not okay with that, you’ll want to feed a “width: 100%” declaration to IE6, probably using an alternate stylesheet linked via conditional comments.

At my current summer co-op, I’ve been tasked with setting up a wiki on the company intranet to make a variety of internal documentation more accessible, editable, and revision-trackable. As far as wikis go, MediaWiki tends to be the default choice; it’s reliable, extensible, and has vastly greater mindshare than any other wiki platform thanks to the omnipresent hive-mind of infallible factoids^{[citation needed]} that is Wikipedia.

Figuring that MediaWiki was probably overkill for this project, I struck out in search of something that would be easier to install and configure for me, and easier for non-technical users to maintain. What I found was DokuWiki, a somewhat minimalistic wiki platform that explicitly aims to fulfill the documentation needs of “developer teams, workgroups, and small companies.” Perfect!

As I soon discovered, one of DokuWiki’s distinguishing features is that it does not make use of a database for storage, as so many other wikis and content management systems do. This makes installation incredibly simple right off the bat: Just drop the files in a directory on your web server and go. All of your pages are stored as plain text files (e.g. another_wiki_page.txt)  in a directory hierarchy that matches the hierarchy of “namespaces” you create on the wiki. In this way, your content remains organized and perfectly readable even when you take the wiki software out of the equation.

For the most part, DokuWiki’s syntax is pleasant and sensical. Instead of MediaWiki’s odd multiple-single-quotes scheme, you have //slashes// for emphasis and **asterisks** for strong emphasis, which feels more intuitive. Instead of MediaWiki’s bizarre syntax differences between internal and external links, DokuWiki treats them all the same: [[link_target|Link Text]]. But then again, there are some strange and arbitrary syntax decisions on DokuWiki’s side, like the fact that the largest headings are surrounded by ======Six Equals Signs======, and the number of equals signs goes down by one for each sub-heading level. Weird, though I suppose it’s in the name of plain-text readability.

Uploading images and other files to DokuWiki is a breeze, thanks to a pop-up media manager that includes a multi-file Flash uploader and can insert wiki-links to your files with a click. Nifty media icons abound in DokuWiki’s output, with PDF files, Word documents, and more each getting their own instantly-recognizable icons. External links and email addresses also get unique icons, making them stand out nicely on the page. The “pretty by default” approach extends to text, which gets automatic curly quotes and various other typographic entities in much the same way that WordPress output does.

Given that I’m using DokuWiki for documentation on a company intranet, I would be remiss if I didn’t mention what an absolute cakewalk it is to integrate your own authentication scheme into it. If you already have a table of users in a database somewhere, as I did, you can set up DokuWiki to authenticate against it in the time it takes you to write a couple of SQL queries. There are other built-in authentication modules you can use, and if none of them meet your needs, writing your own is surprisingly easy (and well-documented) if you have a decent knowledge of PHP. There is also a fairly comprehensive ACL system that becomes much more useful if you set up your authentication scheme to provide “groups” to DokuWiki, or if you’re using the built-in mechanism.

One downside I’ve encountered in terms of usability is DokuWiki’s strict adherence to a particular naming convention for both page names and media file names: Only lowercase letters, periods, dashes, and underscores are permitted. The aesthetics of this decision leave something to be desired, especially since the name of the page you’re on is (at least in the default theme) displayed at the top in very large text, and probably:looks:ugly_as_sin. I’m not sure why capital letters and spaces are disallowed, since they are both quite safe to put in a filename. You can set an option to superficially replace the ugly page names with the contents of the first heading on the page in question, but this just makes the page’s “real name” harder to discover when you have to link to it, and the visual duplication of the page title and the first heading is far from nice-looking.

Thankfully, DokuWiki presents itself very well in all other aspects, and the overall package has so many good things going for it that I can’t help but give it my recommendation. If you want a lightweight, documentation-oriented wiki that feels almost as slick as WordPress but gives off a more techy vibe, DokuWiki can definitely take you there.

About a week ago I whacked the auto-upgrade button on my admin interface to take me up to Wordpress 2.8. It is really nice how you can upgrade even the core system in a single click, right in the browser, without fiddling around on the server.

Unfortunately, after the upgrade, every other form submission on the backend was giving me blank pages and error messages, and I determined that my outdated theme was likely to blame. What’s more, I had foolishly made several customizations to the theme’s CSS, which of course would not be preserved when I upgraded it. Since I always thought that theme was a bit dull, anyway, I figured it would be as good a time as any to search around for a new one. As a side note, the new theme browser/installer in 2.8 made this task incredibly easier than it had been before.

So now we’re rolling along error-free with a new theme and all my customizations safely stashed in the Custom User CSS plugin. I’m still not totally satisfied with this theme (especially the weird fadey drop-down menus) and will probably change it again in the future, but that’s life. On the positive side, the main content area is now just wide enough to squeak a 640-pixel-wide image into.

One of the non-CSS customizations I had made to my old theme was to add several lines of PHP that would prevent my content from being “texturized” – straight quotes replaced with smart quotes, doubled hyphens replaced with real dashes, etc. When I enabled the new theme and the texturization returned, I was surprised to notice that the one thing about it that really annoyed me had apparently been fixed: Straight quotes inside <code> blocks are no longer converted into smart quotes. I’m not sure if this is a fix on the part of the theme or WordPress 2.8 (I don’t see anything in the changelog about it), but either way I’m happy enough to leave the feature turned on.

The one thing that really impressed me about 2.8 is the new syntax-highlighting, line-numbering, generally awesome-looking code editor. This is the first time I’ve seen anything like this, though in retrospect it seems like an obvious idea: If we can already do WYSIWYG editing for normal content, why not apply some nice formatting and colors to code-editing as well? If you’re curious to see what this looks like, the WordPress 2.8 release announcement has a slick video overview that touches on the code editor and various other new features (I recommend watching it, if only to witness the incredibly high production values for it being an announcement of a point release).