Introduction
The story of Stonequest goes back to 1980.
Back in the stone age, personal computers were rare and expensive. The author of Stonequest first learned to use a computer on the famous TSR-80, but eventually spent most of his high school and college years on an Apple //e computer, which was created by Steve Wozniak and Steve Jobs prior to the switch to the MacIntosh line.
The Apple II computer
The Apple II series of computers were cutting-edge for their time, but now seem like ancient relics. The CPU of an Apple //e computer, for instance, was a single-core, single-threaded processor that ran at 1.023 MHz.
To put that in perspective, an HP 15.6" portable laptop found on Amazon today has four cores, each of which runs up to 3.7 giga-hertz. This provides about 14,477 times more computing power than the Apple //e. The difference? The Apple //e cost $2,000 in 1980s dollars (approximately $5,200 in today's dollars) versus the $295 price tag for the HP laptop.
What made the Apple II so special was that it was largely a hobbyist's computer, with well-documented behaviors that could be exploited by the clever hacker to come up with innovative ways to use its limited computing power and memory.
1980: Wizardry: Proving Grounds of the Mad Overlord
For an example of the gaming landscape for the Apple II, see GamesRadar's 10 Best Apple 2 games. You'll note that there was quite a lot of ingenuity involved in producing fun games with such paltry computing and graphics resources.
Yet despite all those games, there weren't many that conveyed the depth of a good old-fashioned table-top role game (RPG). There were a few attempts, such as Akalabeth and Ultima, but none really moved the needle until …
… until authors Andrew Greenberg and Robert Woodhead created Wizardry, a turn-based, party-based role-playing game complete with character sheets, classes, levels, monsters, spells … and even prestige classes! It set the gaming world on fire and showed what was possible with such limited hardware.
Wizardry was unlike anything that had preceded it. It was epic in scope. The dungeons weren't random; they were planned. You can play an entire party of diverse characters. And the spells …!
Wizardry's secret sauce was its magic spells. Before it had come along, all you could do was maybe quaff a potion or cast one of maybe a handful of spells. Now you could have a party of six characters lobbing off any of a couple dozen unique spells!
This game was the author's first obsession. He played it religiously and finally beat the game at a computer lab at NJIT, where his father taught chemistry. His father wanted to leave in time to make the train, but gave into the teenaged begging, and the evil Wizard Werdna was defeated!
1986–1989: VAX 11 Klone at Clark University
The author Jeffrey Getzin initially applied to Clark University as a Psychology major, but between applying and arriving, it became clear that it would be Computer Science all the way!
Under the friendly guidance of brilliant professors such as Dr. Frederick Green and the late Dr. Arthur Chou, he fell head-over-heels in love with computing. In those days, Computer Science at Clark was taught using the same programming language in which Wizardry had been written: Pascal.
Pascal wasn't Reactive. It wasn't Object Oriented. It was procedural, that is, the program was a function, which called one function after another, until everything finished, at which point the application ended. It sounds meager today, but it was Turing complete, and thus, was at least theoretically capable of performing any computation that any other Turing complete language, such as Java, could perform. This would prove crucial much, much later, during the Angular conversion.
The Digital Equipment Corporation VAX 11
In those days (the mid-eighties), personal computers like the Apple II were extremely uncommon due to their price tags. Moore's law had yet to kick in, so at the time, if you were serious about working with computers, you worked on a mainframe computer, or its smaller cousin, the minicomputer.
These machines were roughly the size of an armoire, give or take, and needed to be kept in dustfree, air-conditioned rooms. And they didn't even have a display, mouse, or keyboard! Instead they had a teletype console called the DECwriter that would print your conversation with the VAX.
However, most users connected to these VAX minicomputers from hardwired terminals and would login to "timeshare" its resources. When you did, it seemed like you were its only user, but in fact, there could be dozens of other users also logged in at the same time, and the computer would divide its time into tiny parcels so that each user felt like he or she was the only one logged in.
The VT220 terminal
Unlike a modern PC, a minicomputer like the VAX had no display or keyboard. Instead, you had to connect to it with a hardwired terminal. The terminal was little more than a monochrome monitor and a keyboard. What's a mouse?
The “standard” was the DEC VT100, but the VT220 was a more advanced and backward-compatible terminal. Stonequest was written with this terminal in mind, and the current web game simulates the experience of playing it on such a terminal.
The VT220 was a text-only display, though it came with a special font that had special line-drawing characters like these: ¼ : an upper-left corner, a horizontal line, an upper-right corner, a lower-left corner, and a lower-right corner. These special glyphs allowed you do very rudimentary line drawing, and Stonequest used those as extensively as possible.
The standard text on a VT200 was green on black, though the colors could be reversed to black on green. In addition, the VT200 had an orange-on-black mode which you could reverse to display high-visibility (but eye-burning) black on orange text!
Stonequest was written with the black/green color palette in mind, but it's not like there were a lot of choices available.
The VAX at Clark University
There were three VAX minicomputers at Clark University: Kukla (VAX 11/750), Fran (11/750), and Ollie (11/780). These three computers were networked together so that no matter which one you logged into, you had access to the same files and applications. You could also message users on other machines in the cluster.
If VAXes are ancient history, then the names Kukla, Fran, and Ollie are positively antediluvian. They come from a television show aired between 1947–1957, and features a comedienne (Fran) alongside two puppets (Kukla and Ollie).
Students, staff, and faculty would login to one of these machines from hard-wired terminals placed around campus. For instance, the MIS team who maintained the machines and ran the various reports and processing batches would have terminals at their desks, whereas students primarily had to login on the terminals in the stacks at Goddard Library. Terminals were intended to be used for research and coursework, but in the evenings and on weekends, they were mostly occupied by gamers, typically playing either Stonequest or Moria.
The Origin of Stonequest
Jeffrey Getzin started working on Stonequest before his sophomore year at Clark. His freshman year had been devoted to learning Pascal, but his first semester of his sophomore year was going to be spent on the mathematics his major required. Getzin was concerned his programming skills would atrophy, so he conceived the project of writing Wizardry for the VAX.
This would prove trickier than it sounded.
First, he did not have access to Wizardry's source code. He had to write the entire game logic from scratch. At the time, Pascal was the language of choice, the same language used to write Wizardry, making it the logical choice for Stonequest.
Second, the VAXes and their terminals had no graphics to speak of at the time. They were entirely text-based, though as mentioned earlier, they had extremely rudimentary line-drawing capabilities. However, the task of writing the windowing and line drawing was simplified by the availability of a clever runtime library on the VAX called SMG$ (Screen Management). This library allowed the programmer to create windows, draw lines, and even create virtual displays that could be scrolled up and down.
The SMG$ library worked with abstractions of the terminals being used, so if you wanted to draw a horizontal line and the currrent display supported line-drawing, you'd get a horizontal line. However, if the display did not support line-drawing, the SMG$ would render the text equivalent, e.g.,
+----------------------+
Even the 3D maze had to be drawn with text characters!
There were a number of other libraries on the VAX that enabled advanced (for the time) file management, which was crucial for Stonequest's data, which could be shared with multiple users simultaneously.
In addition, VAX Pascal was an enhanced superset of ordinary Pascal, and offered a number of advanced features, including some that would later be associated with languages like C.
The initial app was very simple but playable. However, to have a playable game, you needed to have data for the monsters, the maze levels, the magic items, and so on. And before the author could even create this data, he had to write editors for that data. Thus, the application was gradually bootstrapped: functionality in the game needed data, the author created an editor to enter that data, and then entered the data. Then more functionality was implemented, and so on.
As Stonequest grew in popularity, the players began taking up so many terminals and using so much computing power that eventually the system administrator had the author set up a schedule in the game so that it could only be played after hours and on weekends.
2023: The Restoration
Flash forward to 2023. A little thing called the Internet had come along. We used our smartphones to watch cat videos. Our cars drove themselves. Pluto was no longer a planet.
And Jeffrey Getzin was annoyed by the binder sitting on top of a high bookshelf.
Inside the binder was the last remaining copy of the original Stonequest source code. Its pages were yellowed with age and darkened with water stains. Even the type of printer used to print it, a dot-matrix printer, was obsolete. Yet, that binder taunted Getzin.
Since his last edit to the Stonequest source code, Getzin has gotten a masters degree, and had worked for technology companies such as Google and Intel. He had a wife, a house and, like, credit cards and stuff.
In its time, Stonequest was hot stuff, but that time had long passed. The technology for which it had been written was long obsolete. Graphics of the sort unimaginable in the 1980s were now commonplace in computer games, rendering almost photo-realistic images. Who would be interested in 1980s games?
As it turned out, quite a number of people. An unexpected trend developed: that of retro games. People restored old console games, played actual pinball machines, and even the source code for Wizardry were available for Apple II emulators.
Coincidentally, during the restoration of Stonequest, the original Wizadry: Proving Ground of the Mad Overlord was re-released with the same underlying logic and brand new 3D graphics!
To sum up: retro was suddenly cool.
Getzin eyed that binder of source code and decided to put it off no longer; he decided to get Stonequest running again.
Phase I: the Original VAX Pascal Code
The first step was to get the original source code for Stonequest. Unfortunately, it only existed in the single red binder.
Getzin tried scanning the source code with various tools and devices, but age had rendered the paper translucent, and the old dot-matrix characters weren't clear. Attempts at automated scanning were more noise than signal, and ultimately, a more brute force approach was needed: typing in every line of text by hand.
In an odd twist of fate, Getzin began entering the source code the same month that Sir-Tech released its 3D version of “Wizardry”.
First, he started by photographing every page of source code from the binder. He rotated and cropped these until they filled an entire monitor with the Stonequest VAX Pascal code.
Then, on a second monitor, he began typing it all in. It took him until nearly the end of November 21, 2023 to type it all in.
Phase II: Getting the Original Application Running on a VAX! (Well, a DEC Alpha …)
The next challenge was to ensure that the typed-in code was correct, and there was only one way to do that: compile that code and run the application!
By 2023, VAXes were not commonly available. Occasionally one would pop up on eBay for $2,000 or so, but that seemed like an expensive route: not just in dollars, but in floor space!
But another, option existed that required no additional floor space, or even any money: an emulator!
An emulator is an application that simulates another device or application. In this case, Getzin discovered that he could operate an emulated DEC Alpha running VMS using a free emulator written by Migration Specialties Europe. The DEC Alpha was a more recent device than the VAX, but it was capable of running VMS.
Getzin figured out through videos, hobbyist websites, and trial-and-error how to get the emulator configured and running. After that, it was simply a matter of transfering the typed-in Pascal source code to the emulated VMS system, and voila! Stonequest ran again for the first time in 33 years!
Why bother with running Stonequest on an emulated DEC Alpha? Because Getzin planned to convert the source code to a modern web application, and it was best to have a reference implementation against which to compare it.
With the original game running on the emulator looking exactly as it did back in 1992, Getzin was able to convert the code to a modern language and platform without worrying about breaking anything; at each step, he could compare the appearance and behavior of the new application against those of the original!
2023–Present: Translation to a modern Angular web application
Over his decades working as a software developer, the author gradually moved from the "back-end" (e.g., databases and APIs) to the front-end (actual web applications). Eventually, he specialized in a front-end framework from Google called Angular.
Angular is an advanced framework that enables websites that are ordinarily "static" (not changing) to dynamically populate the information you see on the screen. It is based on TypeScript, a superset of the JavaScript language used in web browsers.
Getzin decided to convert Stonequest to a modern Angular application. This would let an application originally written for an obsolete minicomputer be playable by anybody in the world with a browser and an Internet connection.
This would involve a number of steps:
- Convert the VAX Pascal to TypeScript
- Renamed all .pas (Pascal) files to .ts (TypeScript). The resulting files were, of course, invalid TypeScript.
- Use the find/replace with Regex ability of WebStorm (his development tool) to convert the Pascal code into TypeScript-like syntax. For instance, Pascal code like:
would be converted to something likeIf IsAdmin AND not Main_Menu then
This code was not valid TypeScript, but successive finds/replaces gradually brought it closer to TypeScript syntax.if (IsAdmin && !Main_Menu) { - The resulting code was then modified by hand to be valid TypeScript.
- Convert the TypeScript in an Angular application
- The original application relied heavily on the VAX's SMG$ (Screen Management) library. Rather than rewrite everything from scratch, the author wrote a compatibility layer that simulated functionality of the SMG$ library but using native Angular components.
- The author sought and found the font that was used on the actual DEC VT220: the GlassTTY: TrueType VT220 font. This font was transferred directly from the glyphs displayed on the actual VT200 terminal.
- The author is gradually converting the emulated SMG$ virtual displays to native Angular components. This is more a matter of maintainability than performance, as the emulated displays are plenty performant.
- Endless waves of gradual refactoring are converting the code to more idiomatic TypeScript and Angular: TypeScript classes, Angular components, pipes, and services, and so on. Since Pascal is a procedural language, the initial Stonequest application for Angular primarily used Angular services to represent those modules. Over time, the author is decomposing these services into more idiomatic Angular mechanisms, such as components and pipes, as well as making the application more reactive and less imperitive.