Adventure - Explore Colossal Cave


After finishing those "simple" game programs, I thought about another game I also found at UCS, Adventure. It dealt with trying to explore a cave, Colossal Cave, and was the most difficult game I had ever seen, still is. I started doing a little research, trying to see if I could find out anything about it. I am quite embarrassed to admit that I did not know it is quite famous. It was really the granddaddy of all "role playing" games. As such, it holds a distinct and honored place in computer gaming history. It was originally written by Willie Crowther in the early 1970s, then enhanced by Don Woods to provide for many hazards and actual scoring.

This was a far too ambitious undertaking for Basic so Willie chose Fortran, one of the most popular languages of the day and quite capable of large, complex programs. It, however, was intended for engineering and scientific applications and does not lend itself well to extremely complex logical operations. I am humbled by the apparent talent of Messrs. Crowther and Woods to pull this off in such a language. Although I had to write a lot of programs in Fortran in my early days, 1960s and '70s, I never liked it much.

During that time, I discovered a new language, called Algol, that had all the capability of Fortran but in a much more logical form. In fact, while employed by UCS, where most of our programs were Fortran with some Basic, I developed an Algol compiler that we were able to use instead, at least those of use who wanted to. Working as a consultant after I left UCS, we installed my Algol for the use of NASA in the development of the space shuttle, well not the space shuttle exactly as it was already done, but the environment maintenance system. All right, I digressed.

Well, considering my distaste for Fortran in light of the assumed complexity of this program, I searched for something else to work from. It turns that the program has been converted and enhanced many times in the years since. I found a version converted to the C language. Since C is a pretty good language and I have quite a bit of experience with it, I thought that would be a reasonable starting point. I found and downloaded the source code from the internet and began conversion. My plan was to just do essentially a line-by-line conversion since the structure of C and Java are quite similar. This time, I would leave it as close to the original play wise as possible. That meant still running it from a terminal.

The C language lends itself to quite cryptic coding and this set was certainly no exception. Although I was doing a direct conversion, I did try to use more meaningful variable and method names. This at least doubled the size of the actual source code but certainly made it more readable. I found a few flaws in the code; converting Fortran to C is not direct and certainly not trivial, a couple of missing features and some I could not decipher. I found a later Fortran conversion by Kent Blackett and Bob Supnik that supplied the necessary information to fill in those blanks. Kent and Bob were fairly prolific with comments so I did not have to study the Fortran in great depth but could discern from the comments what was supposed to happen. It was still painful though.

Well I got it working with still some occasional flaws and left it for a while. Finally, I wanted to correct its shortcomings and possibly make it available to the world. Correcting the errors and making it more "presentable" was not going to be easy. Although I converted from C, the C version was converted as directly as possible from Fortran. My Java version was still a Fortran program written in Java. To take it any further meant essentially a total rewrite in native Java, making full use of Java's object oriented nature

Of necessity, the original Fortran version relied heavily on some very large arrays as well as external storage devices. In the 1970s, memory was extremely expensive and usually quite limited. External storage was much more practical for large amounts of data. This way of representing data of this nature is terribly error prone as well as extremely difficult to alter or maintain. My Java version still had those arrays although I did eliminate the external storage as memory is now relatively cheap and much faster. Actually, the C version I converted from also eliminated the external storage and replaced it with internal memory. It did still access that memory using the original ISAM method. By creating several new classes of objects and moving all the data and methods related to them, then making extensive use of the object orientation, I was finally able to completely eliminate those nasty arrays. Each room, object, dwarf, etc. now maintains all its own data, including any and all manipulation required. This is so much more easily maintained than the original.

Another goal of the rewrite was to add the ability for the player to "water the plant" or "oil the rusty door". I found these features in other versions but they were not in the version I converted from. I had to "pour" water or oil. It worked but was not as intuitive. These now work as they should.

With that done, I have to wonder what is next. Perhaps I will find a way to make it available to the world. I am sure there must be other fanatics like me that would enjoy having a modern version of such an important piece of computer gaming history.

Adventure screen