Friday, April 06, 2007

Adventure Musings

Those of you who are aware of CKSoft, the forerunner of Fifth Column Software, might be familiar with the "Adventure" series. These were some text adventures I developed, which unfortunately have been lost in a hard drive crash (always back up your data, boys and girls!), but continue to loom large in my mind. By looking back at these games, I can trace the trajectory of my self-taught period of programming.

Even before I started programming, I was interested in it. My family subscribed to 3-2-1-Contact magazine, one of those educational rags with stories on science and whatnot. The back of every issue had a simple BASIC program which you could copy, line by line, and then run to play a very simple game or perform some calculation. I loved the esotericism and mystery of the commands. Although I didn't realize it at the time, it was also an early exposure to the problems with "Write Once Run Everywhere" which has been dangled in front of programmers' noses for decades; I would idly wonder why Apple programmers would need to type "10 HOME" while IBM programmers would write "10 CLS".

My parents bought us a computer when I was in elementary school. It was a grand old thing, an IBM-compatible Epson computer with an 8088 processor. It didn't come with a ton of software, but it did have QBasic, that glorious blue primitive IDE. Early on, I took great pleasure in digging out my old copies of 3-2-1-Contact and patiently copying the programs, line by line, into the computer.

This triggered a few things. First of all, it gave me a huge rush; my present employment can be directly traced back to the pleasure I got from watching the screen light up with the results of the commands I had typed in. The sense of creation and pride of ownership, even if it came via transcription, has been a profound motivator to me. Second, it was a spur to creativity. Once I was brave enough to go off script, I had a lot of fun editing the programs they had provided, seeing how to change and tweak them, or re-using what they taught me in other contexts. Finally, it was a surprisingly accurate introduction to the world of debugging. Few programs would work properly out of the box, since the 1970s-style syntax they provided did not precisely match with what QBasic was expecting. So I came to have an expectation of how software was developed: you wrote something, tried to run it, deciphered error messages, made changes, and continued trying until it worked. Again, this is shockingly close to what I do today.

Along a parallel track, I was enjoying several disks of shareware software that we had gotten with the computer. One of my favorites had a title like "Great Adventures 2", and was a collection of text adventure games. One was set on a mysterious island, another on a nuclear submarine, another in the arctic, another in an arcade... I was fascinated by the games and their puzzles, and seemingly never tired of my attempts to figure out the one magic word that the developer was expecting me to type in.

It seems natural, then, that most of my early development would revolve around creating my own text adventures. My skillset consisted of old magazine articles and the QBasic Help program; my goal was the opaque but fun games which were compiled onto that floppy disk. And so, as best as I knew how, I set about getting from point A to point B.

Looking back, I'm kind of embarrassed at what I did, but in my defense, I was around 10 years old and hadn't programmed before. For starters, because every line in those magazine articles started with a number (10, 20, 30, and so on), every line in my games started with a number too. My one innovation was discovering that the numbers didn't need to be multiples of 10, so if I wanted to do something between 10 and 20, I could insert 15. It would be several years before I learned that this was no longer required in modern BASIC.

Another limitation was that I really didn't understand variables. This makes sense, since I wouldn't take an algebra class for several years. Instead, I looked at patterns of programs and tried to replicate them. I would see that I could write something like this:
50 PRINT "What is your name?"
60 INPUT A$
70 IF A$="Bond" THEN
80 PRINT "Hello James Bond"
90 ELSE
100 PRINT "Hello other person!"
110 END IF

I didn't really grok what A$ was, but I saw how you could use it to make the computer do different things based on what the user typed in. And so, when I did my first ambitious program, an adventure game creatively called "Adventure", I leveraged it as far as I could.

I'd love to still have that program so I could give you concrete examples, but let me describe what the code looked like. The entire game used exactly one variable: A$. Like most text adventures, there was a series of rooms that you would move between by typing "NORTH", "SOUTH", and so on. You could also type in certain commands, like "TALK GUARD" or "LOOK CASTLE". In the code, this was implemented as an incredible collection of GOTO statements that linked together blocks of code. Each block would PRINT out a description of the room, do INPUT A$ to get the command, and then do something based on the input.

This had a couple of repercussions. For starters, there was no real state data for the game. That meant that, for example, if you typed "GET CARD", I could do a PRINT or a GOTO in response, but the game itself wouldn't keep track of the fact that you had the CARD. To simulate the effect of progress, then, I would use the PRINT statements to clue the player in to what they needed to do. In this example, it might say "The CARD looks like something you should SHOW to the GUARD." Then, when you got to the GUARD, you would know to SHOW CARD. My favorite example of this is one point where you pick up some dynamite, at which point the game informs you "You can use this to KABLOOOIE what you want to blow up." I knew that my clever misspelling of KABLOOOIE would keep players from cheating, since they wouldn't know how to spell it without first picking up the dynamite.

Still and all, I have fond memories of the game. I suppose it was more of a tech demo for me than anything, but the game did have some atmosphere, at least for me, and its setting was strongly influenced by my obsession with fantasy (mainly Lone Wolf game novels at that time). Much of the game was set in forests, but you also would need to climb into the mountains, ford a river, and to win the game would ultimately penetrate the castle of the evil king to kill him (with a SWORD, no less).

Time passed, and I learned more and got better. Somewhere along the line I figured out that I could have more than one variable in a game, and even started to understand what they meant, including the difference (in BASIC) between a string and a numeral variable. On the gaming front, I was starting to get more into RPGs, mainly through Sierra's excellent Hero's Quest/Quest for Glory games, but I also had intriguing tastes of Ultima and enjoyed playing Dragon Warrior and the Legend of Zelda on the Nintendo. At some point, I decided I was ready to return to the world of Adventure, and started my very first sequel: Adventure II: The Chasm of Doom.

This might be as good a point of any as saying that I really wasn't very creative when I was young. The Chasm of Doom was the title of one of my favorite Lone Wolf books, and I didn't have any hesitation in taking the title for my game (which, after all WAS about a Chasm of Doom). This was a longstanding thing for me, starting when I named my teddy bear Big Brown Bear and not really ending until they finally taught us about plagiarism in junior high school.

Adventure II was kind of a hybrid game, sort of a combination text adventure and dungeon crawl. The first portion of the game was set in a village perched on the edge of the Chasm. You would wander through the village, talk with the locals to get clues, buy weapons and armor, and generally prepare yourself for the trials ahead.

Technically, this game was lightyears ahead of the first Adventure. Buying a weapon no longer just spat out some text; behind the scenes, it would set a variable which told the game that you had that weapon. I also started to get somewhat intelligent about structuring code. I was still a long way off from functions, but I came to realize that there were some tasks I was performing over and over again, so I would stick all that stuff into one block of code and use GOTO in and out of it.

Adventure II was another fun excursion. To me, it felt a tad darker than the first game; once you entered the chasm, there was no more human help, just a string of monsters to overcome. (Combat was very simplistic: you needed to have the right weapon to use on each monster in order to kill it.) I also started to reference a bit more of a backstory, one which involved a deposed king and the forces of chaos invading the land... typical fantasy potboiler, I suppose, but for me it was terribly exciting and interesting.

Somewhere around this time I first learned C, and while it is far more advanced than BASIC, I had little patience at the time for it because it took longer to get a game up and running. In BASIC, I could just type '10 PRINT "WELCOME TO MY GAME!"', and I already had the startings of a game. Whereas with C - sigh! - I had to import the standard IO library, and define a main function, and do all this other STUFF. It just didn't seem worth it. So I buried that knowledge and stayed focus on BASIC as a platform for games.

I branched out and did all sorts of other games, a few of which I actually finished. Pretty much everything was text based, with the occasional graphical trick tossed in. I'd learned as I was growing older that I had no artistic talent at all, so it was both more fulfilling and more logical to stick with what I was "good" at, storytelling and writing engines. I still remember a few of these games... some of the more interesting included Big Business, where you ran a conglomerate and needed to expand by buying businesses and responding to crises; School Simulator 1000, which cast you as a sixth-grade student progressing through school and uncovering the more unsavory aspects of your surroundings; Robin Hood, a game inspired by The Outlaws of Sherwood Forest by Robin McKinley, which had you recruiting, training, and deploying a rebellious society from the safety of the forest; and Spy, an espionage simulator that ran from WW2 through the present, and was heavily influenced by a book I'd read about the Mossad.

Keep in mind that, for me, programming is fundamentally a recreational activity. When you understand that, it might not seem so strange that almost every time I take a long vacation, I'll design or start work on an ambitious programming project. For me this provides another avenue of relaxation and creativity; it often confounds and angers those around me. Anyways, it came to pass that on one of my family's typical summer vacations, I started work on my most ambitious project to date, Adventure III.

One of the many striking differences for the third game was my approach to it. In almost every other project, I started the game by sitting down and typing; often the title, even genre and format, wouldn't be settled until I was well into it. This time, since I didn't have immediate access to a computer, I satisfied my urges by filling out much of a notebook with... well, I suppose you could call it design. I drew out a map of the overworld, I came up with a list of the characters you could talk with, drew out a timeline for major events in the game, and so on. As often happens for me, this sort of daydreaming snowballed, with good ideas popping out on top of one another and an endless stream of "Oooh, wouldn't it be cool it..." thoughts crowding in as well. It quickly became clear that this would be my largest, most intricate game yet.

Part of the game was inspired by the box art for Final Fantasy, a game which I've never played, but which showed a castle floating in the clouds, an image that for some reason really resonated for me. The main world was divided into two main sections: the world of light, which had a normal day/night cycle, and the world of darkness, which was shrouded in perpetual gloom. They were divided by a massive mountain range, serving much the same purpose as the Misty Mountains in Middle-earth. The reason why the eastern section was always dark was because of the enormous, mysterious castle floating above it, casting its shadow upon the land below. The eastern region had fallen under the sway of various foul beasts who had started to encroach upon the free lands of the west, and the king of that land (who you had rescued in Adventure 2) desperately calls upon you to discover the source of evil in the land and make it whole once more.

As a side note, I find it amazing that so many fantasy authors use this simple "West = Good, East = Bad" formula. I got it from J. R. R. Tolkien and David Eddings, and just automatically set it in place when I did my own great work. I suppose this might be a legacy of Cold War thinking or something.

The game system itself was far ahead of Adventure 2, featuring a robust combat system with a variety of options (fighting, ranged weapons, use of items, and so on), inventory management, a skill-based stat system, day/night cycle in the western lands, and so on. I started actual coding while still on vacation, borrowing the computer of some family friends with whom we were staying, getting as far as I could and copying the results to a floppy disk which I carried home with me. It got bigger and bigger, and visions swirled in my head as those sketches in the notebook turned into reality. This would be a true epic! It would revitalize the world of text gaming! It would take dozens of hours to beat, and tell a gripping story in the process!

Then I discovered that QBasic has an upper limit on the size of the files you can edit.

I should point out that, while Adventure 3 was much more advanced than its predecessors, it was still a game written by a self-taught pubescent. While it had become more complex, the underlying structure wasn't much better than the very first game... I still wasn't using many subroutines, all variables were global, there was just a single file with everything dumped into it. The underlying problem is that I was using a procedural language, but even there, I wasn't really approaching it in a way to optimize the code I was writing. Anyways, there were just far too many lines in there, and for one horrible minute I sat staring at an error message which said "Exceeded Maximum Size."

Needless to say, that sort of took the wind out of my sails. By my own calculations, I had spent a few weeks on it, and had only finished maybe 5-10% of the game. A few weeks later, I did realize that I could squeeze some more space into there... the limit I was running into was the size of the source file, not the executable, so I could get creative (shrink variable names, consolidate multiple commands on a single line, and so on) to free up some space. However, it was painfully clear that I would not be able to realize my ambition, and so I regretfully laid Adventure 3 to rest, with the hope that some day I would be able to use another language to realize my vision.

That day hasn't come.

In seventh grade, I did start to dream of the future of the series. Not having finished the third game didn't stop me from plotting out the future course. I came to decide that the whole Adventure cycle would consist of a total of five games, and wrote plot treatments and drew (horrible) box art for each one. The third game would end, I decided, with a massive confrontation with the Ultimate Evil, and would end in failure, with your character banished from the universe. The fourth game was inspired by the Lone Wolf book The Prisoners of Time, and focused on your efforts to return to the main world. In the process you would travel through various elemental planes, in which everything you encountered was fire or ice or lightning or the like. As long as I was dreaming, I decided that the fourth game would be the first graphical Adventure game; the player would actually navigate through the world using the arrow keys instead of typing commands.

The fifth game would see you return in triumph to the main world, and the world of the text adventure. I wanted to return to the mode of Adventure 3, adding even more features to the game: you would travel with a party, and early on in the game would seize control of the floating castle, which you could fly around from place to place. I deliberately held off on deciding how the series would ultimately end - I tended to believe that I was most creative when I was making stuff up at the keyboard - but five seemed like a nice number to end on.

And that's as far as it went. I did continue to write more text adventures later on, leveraging what I had learned with Adventure to structure things more intelligently. At one point I even took the Sierra route and redid an existing game using more advanced technology, when I rewrote the original Adventure game using graphics. Later highlights included The Project Game, written in 8th grade as a relatively realistic game set in my junior high school and structured as a typical inventory management and quest-solving game (and also featuring incredibly crummy line-drawn graphics), and Something Strange, written in my senior year of high school and probably my magnum opus, a bizarre tale heavily influenced by Robert Anton Wilson and Zak McKracken which combined my high school with conspiracy theories, the Illuminati, government cover-ups, globe-hopping travels, and more inside jokes than you could shake a stick at. Something Strange is something that only half a dozen people in the world can even hope to understand, and it even confounds most of us.

And so it goes. I still love writing games, but the Adventure saga is well behind me. I think of them much as an artist probably considers his childhood scribbles: interesting and humorous, though slightly embarrassing. Still, they're part of my story and part of my life, and I probably wouldn't be the programmer I am today if I hadn't had so much fun writing them in my youth.

2 comments: