XYZZYnews

Tales from the Code Front:

So you want to write a text adventuring authoring system...

by Alan Conroy

Many a programmer who has played Adventure, or any of the Infocom games has considered writing their own adventure game; some even consider writing an authoring system. In this article, author Alan Conroy (alan@accessone.com) discusses how he developed an adventure authoring system named Adventure Builder and the issues involved with writing your own.

The genesis of Adventure Builder

When I was in high school, I played nearly every game on the HP 2000 system that users at my school and others in the area could dial into. I wrote a couple simple games of my own -- battleship, card games, and the like. In the summer of 1978, just after I had graduated, a former teacher of mine began managing the district's new minicomputer. The three high schools in our district now had their very own DEC PDP-11/70 running RSTS/E. I spent some time at the computer center as a guest, playing with the computer while they worked the bugs out of the new system.

That summer I was introduced to Adventure, an early port of the original that had me instantly hooked. Imagine! A computer game which understood typed English commands! True, it only understood one or two-word commands and had an extremely limited vocabulary, but compared to anything else up to that point it was a revolution.

I played Adventure whenever I could that summer, and in the fall I started taking evening classes at a community college while working as an EKG technician. They had a dial-up terminal in a back corner that sat unused in the evenings, so I dialed- in to the PDP-11 with a guest account and continued to play Adventure. By the next year, I hadn't yet solved it -- two puzzles still had me stumped. Most of my high school buddies who had played Adventure were at colleges out of state and there were no such things as Invisiclues, so I was on my own. The thought of writing my own game had also firmly taken root and I had begun preliminary coding in BASIC.

Then I moved to Washington to attend Seattle Pacific University. Some of my high school buddies were already there, and I found several other new friends who had played Adventure through to the end. That first quarter at SPU, I finally got all 350 points in Adventure. Now I could consider some serious coding for my own game. SPU also had a PDP-11 computer, so my game -- such as it was -- required no rewriting. In 1980 I took a Pascal course and for the course project decided to write a complete specification of my game from a programming standpoint. This included deciding what data structures I was going to use, the basics of the parser, and converting what little I had written into Pascal. This was the beginning of the Quest game.

I continued to work on Quest on my own once the course was over. By this time, TRS-80 computers were in vogue and were soon showing up all over campus. After I gained access to the university's one TRS-80 Model II with a FORTRAN compiler, I decided to convert Adventure to run on that platform. I had to type all of the source code and text in by hand before I could even deal with compatibility issues between PDP-11 FORTRAN and TRS-80 FORTRAN. Of course, before I could finish that -- I still had grades to consider -- one of the university's administrative departments repossessed the Model II, and I never saw it again.

About that time I learned about adventure games for Apple computers created by companies like Broderbund, Adventure International, and Sierra On- Line. The Apple games had the same limited parsing ability, but included low-resolution graphics that accompanied the text. Shortly thereafter, TRS-80 Model III computers could be found all over campus and I decided to earnestly start coding Quest for that platform. I converted my Pascal code to BASIC -- the only programming choice I had for that computer -- and tried to squeeze it into 64K along with the BASIC interpreter and the TRSDOS operating system. I made enough progress that I let other people play Quest on a trial basis and used their input to refine my design and ideas about adventure games.

Then someone installed DUNGEO (Dungeon) on the academic minicomputer and I was hooked all over again. Here was a parser that understood much more complicated input than any other adventure game! In short order I ran into the shortcomings of Dungeon, but found it such an improvement over everything else that I was willing to forgive all. There were many times that I played the game with several other students at the computer lab, trading hints until the early morning hours until we had solved the mysteries. Suddenly, Quest seemed pale and insignificant by comparison. It was no use trying to improve it, the 64Kb memory limit and the limitations of BASIC and TRSDOS made it pointless to continue.

So, once again I converted Quest, this time to BASIC-Plus-2 (a BASIC compiler) on the PDP-11. With the 128Kb memory limit and the ability to do overlays, I was free to make a decent game along the lines of Dungeon. At this point (about 1981), I began to wonder if I couldn't create a library of routines that could be used by any number of games, enabling any programmer to create adventure games on the PDP-11. This new goal, plus my desire to finish Quest, fueled my work for the next two years. Even with overlays and data caching, the memory limits were a real thorn in my side. I spent half of my time trying to figure out how to change the overlay structure to allow me to compile every significant enhancement.

In 1983, I purchased a DEC Rainbow computer (8088) with a huge 5 MB hard disk and 256 KB of memory! And it only cost $3,600. My dream of text adventures for the masses was much closer. Still, it seemed unlikely that many people were going to buy systems of that caliber for that price, so I continued to work on PDP-11 Quest. It was around this time that the Zork series was released by a new company called Infocom. These games only required a 2-sided floppy and 256K of memory. I could run them on my machine at home! I was a college graduate by then and busy working as a system administrator; what little time I had outside of work was spent on other projects, not Quest.

Finally, in 1987 two important things happened. First, I got married. I had introduced my fiancee to adventure games, and she loved them. I had made some converts to adventure games over the years, but she was the most enthusiastic. Second, I was laid-off during a series of downsizings. So we both decided that I would work full-time on Quest as long as we could afford to financially -- she worked part-time and I did some consulting to stretch it out to six months -- and Conroy & Conroy Company was born. I decided to consider the previous nine years as research and development, with Quest as the prototype and write from scratch in Turbo Pascal V3 on MSDOS (version 2.11 at that time). This gave me the chance to completely separate the Quest game from the engine. Since I didn't want anyone to have to buy Turbo Pascal or any other compiler to use Quest or to write games, I wrote a simple compiler based on the Sirius language (which I had been refining even longer than Quest) and integrated it into what now was the Quest Adventure Authoring System Version 1.0. Since I had an integrated interpretive run-time system, it was easy to integrate the engine and the programming language more tightly than a more conventional approach would have made possible.

This was during Infocom's heyday, and I knew that Quest would have to let people write better games than the Infocom ones in order for it to sell. Fortunately the years of messing with parsers let me write a parser far better than what Infocom had back then -- in retrospect, this wasn't all that great of an accomplishment, but I felt good about it at the time. A few big games had been written by then; for example, Time Zone for the Apple was huge -- ten diskettes instead of the normal two. Not to be outdone, Quest allowed 8,191 rooms (called nodes), and up to 4,095 unique items. Users needed 640Kb of memory to run such a large game, but by that time, most DOS machines had over 1MB. However, I could fit a standard Infocom-size game in 256KB of memory. Quest came with the game I had been working on all these years as a demonstration of the authoring tool's abilities. I even included the entire original Adventure game as part of the larger Quest game. I sold a couple of copies and got a review or two in various newsletters, but the money certainly wasn't rolling in.

So in early 1988 I had to go back to work. Conroy & Conroy was still alive and well, but I wasn't putting the same hours. I made various improvements and bug fixes, until reaching Quest V1.2 in about 1993. Most of the improvements were in making the authoring system's interface less "techie."

Over time, my target market had changed from game companies to anyone who wanted to write a text adventure game. Quest had come a long way since the TRS-80 days, but even with V1.2 it was still too techie for a general audience.

By this point, though, text adventures were considered passť by the general public, and Infocom was no more. I had not made enough money to even cover a portion of the time I put into Adventure Builder. I made the Quest demo game available as freeware, but that failed to drum up any business either. The prospects for Quest seemed rather bleak.

So why did I continue? Partly because of the encouragement of my wife, Annette. She was working on her Masters degree in education -- specifically language acquisition. According to her, text adventure games were exceedingly useful in building language skills (both comprehension and composition) in limited-English students. By now she has completed her Ph.D. and still maintains that this is so. The second reason I didn't give up is that I personally still believed that text adventure games were unsurpassed in the game software world in their ability to engage your imagination. If only they could be made more popular with the current video- oriented generation...

In 1994 I began work on a major upgrade to Quest. First, I decided to change the name to Adventure Builder. It was too confusing to have the authoring system and the demo game named the same. Next, I created a Windows GUI version of the authoring system, another step towards making the authoring system easier to use, although the DOS command-line interface remained available for people who didn't use Windows --and at the time, that was most people. The new version was Adventure Builder v2.0, which is still the current version. The next version, 2.1 is underway, but it will likely be a few years before it sees the light of day.

Why did it fail?

So, with such an awesome product at such an early date, why wasn't it more successful? I think the major reason is that I am not a marketer; I'm a programmer. The first of several mistakes I made was in the pricing (I was charging $99). I came from the DEC computer world, where all software you purchased came with 12 months of free maintenance, including free updates of any software that came out during the 12-month period), with renewal for a relatively low price. I carried this philosophy forward into the PC market thinking that people would love the novelty of decent support. I also learned the hard way that many industry magazines were interested in printing a decent review only if you were willing to fork out hundreds of dollars to advertise in them.

A second problem was that the target market was relatively small. More people wanted to play adventure games than write them. But I wrote Adventure Builder because that is what I wanted to write. There were other minor reasons too, I think, but the combination of writing what I wanted rather than what the market demanded, plus the inability to market it in the first place, is explanation enough.

So why didn't I write games instead of an authoring system? I was really more interested in the authoring system, and I'm not that great of a game author. If you play Quest, you will see that it doesn't have much over Zork I as far as plot or NPCs.

What about the Internet? Until this year, I didn't have Internet access. I was pleasantly shocked to find a thriving, if small, gaming community online. And though Adventure Builder might have been the first commercial text adventure authoring system outside of the game companies, it certainly is not the only one now. If I had Internet access ten years ago, things might have been different -- or they might not have. The current popular authoring systems all have (at least) one major advantage over Adventure Builder: support for multiple platforms. It is unlikely that Adventure Builder will support platforms other than DOS and Windows.

Why write your own authoring system?

This question might be be rephrased as "Why would anyone write their own authoring system anymore?" After all, there are numerous authoring systems, the market is small, and no one in this field is likely to get wealthy because of it. Nevertheless, I think there are still good reasons for writing your own authoring system.

Nothing will teach you more about adventure game theory than writing your own authoring system. As a game writer who uses an authoring tool, you don't need to concern yourself with file formats, the internal workings of parsers, object interaction engines, compilers, interpreters, linkers, or debuggers. But as you write an authoring tool, many or all of these things must come together or no game can be written. Knowing this kind of detail about the underlying system can make you more adept at writing games. It will hone your programming skills. It will call upon a wide range of knowledge domains. In other words, you will learn a lot.

Perhaps your strengths don't lie in the area of game writing -- I, for one, am more of a "tools" person than an "application" person. Writing an authoring system allows me to write an application that is a tool. It will give you great appreciation for the accomplishments of authoring tools such as Inform, Hugo, and maybe even Adventure Builder.

Despite the lack of both fame and fortune, I don't consider the last 19 years of effort on adventure games to be a failure. I had fun. I learned more from that effort than I learned in my years at the University -- that's no reflection on SPU. Finally, it's given me the confidence to know that I can pull off the next generation of adventure game software I write. Fame and fortune would have been nice, but they were never the motivating factors for what I did.

How do you start?

You can learn a lot about how a successful authoring tool works by studying the inner workings of someone else's parser. The same holds true if you plan to develop a compiler or interpreter. There is a lot of source code readily available on the Internet for your perusal. You should also seek out opportunities to talk to those who have already created their own. Check out various game magazines, such as XYZZYnews. One good introduction to adventure game authoring issues is an article by Infocom's Dave Lebling in Byte magazine, Volume 5, Number 12 (December 1980) -- your local library should be able to help you locate a copy.

Expect to spend roughly equal parts on the game itself, the parser, and the rest of the program. In Quest V1.0, the parser was 30% of the executable in size, but took about 50% of the development time due to the complexity of interpreting commands in English.

Don't be daunted by the size of the task. If I had known that Adventure Builder would be ten years in the making, I probably would not have even started it. However, at each stage of the process, I had a better system than before. You can implement your improvements in phases: Do a very simple parser on the first round and concentrate instead on how objects interact in your world. Once that's done, get a simple demo game working and then add a better parser, then an interpreter, then allow save and restore, and so on. Immediate feedback from your efforts will encourage you. After all, you're doing this for fun, aren't you?

Consider working with someone else, especially if their interests complement yours. Perhaps they will work on the interpreter while you work on the parser, and so on.

Good programming skills are a given, as is keeping a goal in mind. You should have a good sense of what you want the finished program to do before you start. Next, spend some time designing it before you begin programming. Don't overlook your target audience. If the authoring system is solely for your use, a fancy user interface may not be necessary. On the other hand, if (like me) you wish to allow non- technical people to write games, you will need to invest time in designing the authoring system's user interface. Finally, seek out constructive criticism on both the authoring system and your game. This could be done in many ways, from asking friends to review your software to having official beta testers.

Conclusion

I hope I've encouraged a few of you to experiment with your own authoring tools. If you have questions about adventure game theory and existing authoring tools, you can post them in rec.arts.int-fiction and most likely find someone with an opinion on the issue. If you would like to get a copy of Adventure Builder, go to http://www.accessone.com/~conroy/ab.html. The documentation may be of particular interest since the authoring tool source is currently unavailable.


[top arrow] Go to the XYZZYnews home page