Back when I was in high school, I dodged this stipulation by virtue of being incredibly lazy: A web development position almost literally fell into my lap, and I took it. Then I used the experience from that job to get another web dev position, and then I used the experience from that job to get another web dev position. By following the path of least resistance, I had accidentally become a full-fledged web developer.

Not wanting to pigeonhole myself, at the start of this year I began looking for a position that would give me a greater breadth of experience. A position that would challenge me to solve new and different problems every day, instead of grinding on a single project for three months straight. A position… on the IT Helpdesk?

Yes, believe it or not, I’m currently on a six-month co-op at the IT helpdesk of a local company. I wasn’t quite sure what to expect going in, but after being there for six weeks (it feels like it’s been three), I’m liking it better than any of my previous jobs. I get to interact with people more often, I have a pleasantly balanced and ever-changing mix of projects and issues to work on each week, and I’m learning loads of Windows sysadmin stuff that will definitely come in handy if I decide to take a similar position after I graduate next year.

Of course, I probably shouldn’t be abandoning webs as a career option quite so readily… but I feel like what I’m doing now is really what I meant to do all along, and I just got severely sidetracked for the past couple of years. Web development alone does not an “IT generalist” make.

Trying to think of things I could talk about with zero preparation (it’s a short list), I ended up giving an extremely ad-hoc presentation on coding in Cartridge BASIC for the PCjr. It was mostly me going through the client-side code for Twittjr and explaining how to do useful stuff when you don’t have function parameters, return values, code blocks, or variable scope. It produced more than a few glazed looks from the audience, but I got some positive feedback afterwards, so that was nice. The whole event made me wish I worked on more cool projects; or rather, that I had the motivation to work on more cool projects.

Lots of CSHers in attendance as usual, including a few venerable alumni (John Resig, Bill Kuker) and our favorite not-quite-alumni quasi-advisor, Andy Potter, talking about IT outsourcing and antiquated networking tech. We also had IGM professor Al Biles with the history of audio recording and some GenJam tidbits, and some cool people from Interlock Rochester, one of whom I already knew from elsewhere (hi Alan!). Overall it was a great time; lots of new faces and plenty of familiar ones too. I know I’ll be going next year!

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.

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.

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.