How to Learn to Write Code in 37 Short Years, Part 2: Adventure Games

Author’s Note: This essay is the second in a series on how I learned to write code. You may want to check out Part 1 if you haven’t already done so.

By the time I got my VIC-20, the computer was already outdated, but I wasn’t complaining. There was only one problem: I didn’t know how to write code. At least, not beyond the few commands I’d learned the previous summer. Moreover, being in a new town, I didn’t know anyone who did know how to program a computer. I was on my own.

What I did, then, was get my hands on some computer magazines. In the 1980s, computer magazines were popular on the magazine shelves, even in the grocery stores. I ignore most stuff in the magazine and focused on the programming samples that they had. I have no memory of what any of these programs did, but I remember some of them spanned multiple pages. I would carefully type these programs into my VIC-20, line numbers and all, and then run them. Often, they’d generate an error as soon as I executed them. Usually, this was because of a typo I’d made. It might seem like an inconsequential thing, but I began to develop a lightning focus for these typos. Today, when I compile something, or run some code I’ve written, and it errors out, I can almost instantly see the problem (forgot a semi-colon at the end of a line; or, a bad indent on a Python script.)

When the programs worked, I was delighted. I also began to experiment. I would change lines of code to see how it changes the program, and slowly I began to deviate from what was on those pages to something different.

This was slow going, made slower by the fact that it took a long time to enter these programs, and the tape drive I had didn’t always save them reliably. If that happened, and I wanted to run the program again, I had to start from scratch. On the downside, this meant a lot of re-entry of code. On the upside, I gained a lot of experience and got more familiar with the code I was entering.

Still, it seemed a slow way to learn. I needed something faster.

Eventually, my VIC-20 was replaced with an Apple IIe, which in turn was replaced by an IBM PC. It was on these two computers that things began to speed up for me. For one thing, both computers used floppy disks instead of tape drives, which made saving the code I typed in much easier. For another thing, I discovered a more practical way to learn to code: by having a specific, concrete goal in mind.

It was on these computers that I first encountered text adventure games. There was the Zork series of game, of course, which had a multiword parser that was almost like typing English sentences. But what grabbed my attention more were the Scott Adams adventure games, which used a simpler 2-word parser. Until i discovered these adventure games, I didn’t even know what the word “parse” meant. It hadn’t come up in any of my English classes. And as it turns out, parsing, is a fundamental operation in both operating systems and computer languages. I didn’t know it at the time, but these adventure games were helping me learn some basics of computer science.

Scott Adams adventure games were like Choose-Your-Own-Adventures, but more elaborate. You were presented with brief descriptions and then presented with a prompt like:

You are standing in a dark room. There is a door on the north side of the room and a hallway to the east. A letter rest on a desk in front of you.

There was a prompt and you could type in two word commands, which would evoke different responses. For instance, you could type:

read letter

which might produce a response: “You don’t have a letter to read.” So you’d type:

get letter

and see: “You pick up the letter from the desk.” Then:

read letter

and see: “Do not open the door. It is booby-trapped.”

The games interested me as a unique form of story-telling. (I was just beginning to write my own stories around this time.) But I was intrigued and fascinated by the mechanics of the game, even more than the storytelling. I tried to imagine what the game looked like inside, like opening up a clock and peering into the elaborate gear-works within. Only, I knew this wasn’t just gears. This code, and I was becoming more familiar with code. It occurred to me that this could be my goal: to learn how to make my own adventure game by learning how these games worked inside.

Right off the bat there were three things about the game that interested me:

1. How the parser worked.
2. How the map for the game worked.
3. How the game knew when things changed within it.

Much later, I realized that through these three interests, I was learning three fundamental concepts about programming:

1. Parsing and interpreting data.
2. Storing data and relating data in useful ways.
3. Managing the “state” of a system.

In almost every piece of software I have created in my professional life, each of these three concepts place a significant role.

I had to really look around to figure this stuff out. There was no Internet at the time. There were bulletin boards, but I didn’t have a modem to connect to any of them, so I was mostly on my own. The computer magazines helped some. Do did the Granada Hills Public Library, where I could go and look at books on computer programming.

I remember I figured out how to write a 2-word parser entirely on my own, in much the way I imagine a person who can’t read music learns to “play by ear.” There was a lot of trial and error, but eventually, I managed to be able to split 2 word input into a “verb” and “noun”. I could compare those to lists and if the entries weren’t in the lists, I could return error messages.

Figuring out the map was much more difficult. Ultimately, I found a way to create a map using BASIC “data” statements. “Data” statements was how data that a program used internally was stored a part of a BASIC program. Imagine an adventure game with 4 rooms. There are 4 cardinal directions that are possible from each room. Suppose you have a map that looks as follows:

![[IMG_0662.jpeg]]

The data statement for a map might look something like this:

DATA 1, 'You are standing in room with a door to the north and a hall to the east', 3, 2, 0, 0
DATA 2, 'You have entered a hallway. There is a room to the west.', 0, 0, 0, 1
DATA 3, 'You are in a cave. A door leads south and there is a sldie to the east.', 0, 4, 1, 0
DATA 4, 'You are stuck in a pit at the bottom of a slide.', 0, 0, 0, 0

The first number is the room number as shown on the map. The next item in the statement is a description of the room that is displayed when you enter it. The following four numbers represent the rooms you can get to for each of the cardinal directions, north, east, south, west. So from room number 1, you can get to room number 3 by going north, and room number 2 by going east.

Figuring out the “state” of the game was probably the most difficult. Consider the letter on the desk. If I tried to read the letter without picking it up first, the game would tell me that I didn’t have a letter. But if I picked up the letter, I could read it. The game had to know that I had picked it up before I could read it. Once I picked up the letter, the “state” of the game had changed. But a game could have dozens or hundreds of situations like that. Door that were closed or opened. Lights that were off or on. Puzzles in these text adventures were largely based on the state of the game.

Eventually, I figured this out, too, although it took a little help. For the first, and only time, I enrolled in a class on computer game programming that was being given at California State University Northridge. I think it was a Saturday class through their extension program. I do remember that I was the only “kid” in the class. That class was helpful in that it provided a useful structure for how to think of things like “state”. It also taught me how to create a game where the “monsters” in the game were taught to find you, regardless of your position in the game map. (Much later, I realized this was an algorithm, but I didn’t know it then.)

I kept at it. I created my own adventure games which, in their look and feel, seemed indistinguishable from Scott Adams adventure games. It was only in their story-telling ability that they flagged. I tried to make my games too complex, with maps with a hundred rooms instead of a few dozen. I was less interested in the storytelling and more interested in the mechanics. The more code I wrote the better I got, but it was almost always off-the-cuff. They were also always plain text games. I felt I needed to expand my wings a bit.

I began looking for practical applications for my programming, instead of just building something to see if I could. One thing I coveted was Microsoft Flight Simulator, mainly because I’d always wanted to be a pilot, and flight simulator was about as close as I could get as a teenager.

The opportunity came as part of a project in a computer programming class I took in either eighth or ninth grade. Don McLish was our computer teacher and our project was to built something using the concepts we had learned. I built a flight simulator. It was a fairly simple thing. I think there was a single instrument, and line that represented the “horizon” out the window. But it moved the way it should as the plane steered through the air. I remember it requiring programming using some trigonometry, which I was taking in math at the time. It impressed the teacher enough for him to sent a note home to my folks.

This encouraged me, and despite the occasional comments that I was “spending a lot of time” on the computer, I continued to practice writing code, more and more looking for practical applications. In high school, worked in a local pharmacy and was impressed by the software the pharmacist used to manage his customer database. I went home and tried to mock-up my own version of that software as a kind of personal “rolodex” program on the IBM PC that I had. It worked so well that I used that program for several years, including my first few years in college.

In college, things slowed down a bit as I was focused on classes and my interactions with computers was mostly for typing up notes and papers. But two things took place in college which would have a big impact on me and my programming.

The first was a computer class that I took with one of my roommates. I think we learned to program in Pascal, a teaching language. That class made me realize that most computer languages were more alike than they were different. It wasn’t a big deal for me to go from BASIC to Pascal once you knew the subtle differences. We also used NeXT workstations our labs for that class, and I was impressed by the NeXT, which was Unix-based underneath. It was a fleeting thing, because the class was just one quarter, but I didn’t forget the NeXT or that initial introduction to Unix.

The other thing that took place was a promotion I got. I’d been working in the dorm cafeterias for my entire time in college. I’d started in the dishroom (which I enjoyed) and worked my way up to a supervisor, and then, in my senior year, into the business office, where I ended up spending the year writing computer programs to automate the cafeteria budgeting process in Microsoft Excel. I was now being paid to write computer code, and as much as I enjoyed working in the dishroom, I enjoyed this work a lot more.