My childhood debt to open source (II)

This article follows on the previous article of the same name. The previous article describe my childhood passion for computers and the necessity that open source software played in it. Being able to read and share source code was an undercurrent that I took for granted from 1983 onward.

IBM PC Years

By 1989 my family had retired the Atari 400 and the occasionally borrowed Apple II. We got a 286. Manufactured by Hyundai, no joke. Back in these days, the computer came with two gigantic binder manuals: one for MS-DOS and one for GW-BASIC. Being able to have the BASIC reference manual, not to mention its copious sample programs meant that an inquisitive child could soak it up fast.

Several friends and I had already learned Atarisoft and Applesoft BASIC, so moving to the PC was a snap. Graphics and sound capabilities were different and generally more difficult, but the core concepts were the same. We attempted to write parts of fighting games and Sierra-style adventures. Given that we could only use the interpreter and didn’t know much about graphics, text adventures were the thing that we could code.

One book, Compute!’s Guide to Adventure Games, stood out for me. The book talked through the plots of popular text adventures, but later got into the mechanics of programming. A sample chapter is online, preserved in HTML form by Richard Bartle.

Happily, at the end of the book, there was the full source code for “Tower of Mystery,” a complete text adventure. Predictably, I pored over the mysteries of the parser and tinkered in vain effort of adding my own rooms and objects to the game.

Online Years

Swapping floppies of BASIC programs had been the modus operandi for years. Once I got a modem, it had changed. No more floppies–we could just upload. No more GW-BASIC–it gave away our kiddie status. Once BBS and Internet access came, sharing and learning from source code took on new forms.

The games ZZT and TinyTIM embodied this well. Both of these offered ways to add value and replayability by writing extensions to the game yourself. In fact, TinyTIM depended on it. You could play the introductory module of ZZT and then proclaim yourself “done,” but TIM all but required the full participation of its players in expanding its life.

For both of these games, sharing the internals was the key. You learned to program ZZT games by downloading other games and inspecting their guts. You copied down someone’s “shopkeeper” program and adapted him so that instead of swords and shields, he sold light sabers and blasters. In TinyTIM, if you wanted to build, you learned by examining the objects that others made and used that as the basis for your new idea.

Of course, once you had created your new ZZT module or your new TinyTIM object, you shared it back to the group. It’s great to make a game for yourself, but the point was to have others play it. The goal of building your TinyTIM mansion was to have your friends over for a party. While they were there, you could bet that they were examining the camera and answering machine you made, so that they could build one too.

For years, I took for granted that having open source games and other programs was the way that computers worked. The natural openness of the platforms encouraged exploration, tinkering and alteration, ready for exploitation by a curious child.

In my final article in this series, I’ll wrap up with ways in which I shared back with the community. Hopefully these articles ring bells for others and can help bring an awareness of something that was largely taken for granted in the 1980s and 1990s.

About these ads