Back in the Days of Old when college students hung out in dank computer labs wasting time and avoiding the sun, there once was a game called Castlequest. Although widely believed to be forever lost, a determined adventurer by the name of Arthur O'Dwyer sought out its authors which led to the game's rediscovery deep within the catacombs of the US Copyright Office. With no small effort, Arthur manually transcribed the scanned source code to its original machine-readable format and through various magicks brought it back to life.
Ok, so he used a Fortran compiler.
Castlequest was originally written in FORTRAN 66, a language usually associated with numerical analysis, punchcards, and overwhelming malaise. F66 is not a particularly good language for writing games, but Castlequest was written in 1979. FORTRAN 77 had only been formalized the year before, so - all things considered - the decision to use FORTRAN 66 was completely reasonable at that time.
Arthur published the recovered Castlequest source code in March of 2021 and I learned of it in April. By mid-June I had converted the original rat's nest of FORTRAN 66 to Fortran 2018 - object-oriented, fully documented, with unit tests, build automation, and installation packages for MacOS, Windows, and Linux. From a user's perspective, Castlequest still plays the same but the internals are wildly different.
Castlequest is an interesting program with some history behind it. It's also a worst-case scenario of tangled logic and unstructured, unmaintained code, the sort that Dijkstra warned us about. But beyond that, it's a vehicle for applying modern software development techniques and tools such as build automation, continuous integration, test-driven-development (TDD), and more. Finally, it demonstrates the resilience of 40-year-old software written in a 55-year-old dialect of a 65-year-old language, one that's still widely used for large-scale high performance numerical computing.
I have been meaning to write about the Castlequest modernization project while the experience is still fresh: motivation, goals, processes and technologies applied, lessons learned, etc. Rarely does one have the time or motivation to draft an extended post mortem analysis of a software recovery project; my question is whether there's an audience for reading it. Drop me a comment if this tale sounds like it's worth continuing and what interests you the most about it.
In closing, much credit goes to Arthur O'Dwyer for his persistent detective work and initial code recovery. That was a lot of retyping...
Note: This article was originally published (by me) on LinkedIn
Top comments (0)