In the previous installment, I gave a brief overview of my eight week effort to convert the 1979 text adventure Castlequest from FORTRAN 66 to Fortran 2018.
A big question: "Why?"
Whatβs My Motivation?
My teen years were spent playing the text adventures that came in the wake of Castlequest, both Infocom classics such as Zork to BASIC programs you had to type in yourself from a magazine or library book. I won't lie - nostalgia is part of my motivation but there's more to it than that. If I just wanted to play the game, it is already in a working playable state. Similarly, if I wanted to study the code as if it was a museum piece, the original 1981 code is easily available in PDF form. Neither is a reason to modernize the code.
Aside: "FORTRAN" was spelled in all caps until the 1990 revision
when the name was officially changed to "Fortran". Typically
"FORTRAN" refers to the revisions I, II, IV, 66, and 77 and
"Fortran" refers to revisions made in 1990, 1995, 2003, 2008,
and 2018. The former set is currently considered
'legacy FORTRAN' and the latter 'Modern Fortran'.To avoid eye strain and/or hearing loss, the 1966 and 1977
revisions of the language will be abbreviated "F66" and "F77"
respectively.
Arthur O'Dwyer (introduced last episode) went through no small amount of difficulty trying to build and run the game after forty years without maintenance. I want Castlequest to be playable forty years from now, preferably with less pain.
There is a problem, however. Well, problems. I will cover interesting problems in detail later, but the major problem is that the code contains a number of F66 features which have been deprecated and deleted in Fortran 2018. The next time the code fails to compile it will be even more difficult to recover and there will be fewer people who understand F66 and its idioms well enough to recover it.
It's not just that the implementation language is long obsolete. The design of the code is alien to software developers who have spent their careers using object-oriented languages such as C++, Java, Python, etc. Castlequest's design and implementation don't affect gameplay so, from the player's perspective, they don't matter. What the program does is far more important than how it does it.
The game is not the code.
Museums and Garages
Arthur and I have very different philosophies regarding Castlequest's source code. He's acting as a museum - acquiring artifacts, preserving them, and presenting them for display and study. With Castlequest, his goal is to keep the source code and gameplay as close as possible to the 1981 version while making the game playable on modern systems.
In contrast, I am acting as a garage. I bring a car into the bay, open the hood and assess its condition, then make it as safe, reliable, efficient, and maintainable as I can within the owner's constraints. At bare minimum it will be clean, road-legal, and will start, drive, and stop reliably. It may or may not have a pine tree air freshener hanging from the mirror but it will definitely have New Car Smell.
My goals with Castlequest are to modernize the code to meet current language standards, restructure it to simplify maintenance, and clarify its internal operation should someone wish to implement the game in a new language. I want to preserve the original story and mechanics while improving the user experience on modern systems. I'm willing to sacrifice authenticity for playability and long-term maintainability.
Arthur and I have very different approaches but they're both completely valid. We don't have to make an either-or choice between museums and garages. There's space enough for archivists and mechanics and plenty of others.
Pine tree air freshener photo courtesy of PΓ₯l Berge via Wikimedia Commons
Top comments (0)