My holiday project of implementing a Sierra AGI web runtime is coming along nicely. The game engine was revolutionary for its time. It was effectively an entire creative suite (content tooling, bytecode VMs for distribution to different computer architectures) that allowed the early Sierra On-Line game company to sell its games on many different early personal computer systems.

The virtual machine was based around an in-house developed C-like programming language called “Logic”. When the programmer compiled a Logic file, the compiler produced an 8-bit “opcode” for each statement. In the interpreter, each opcode was defined in a jump table which simply pointed to an assembler subroutine. This made the system very fast and ridiculously elegant, because the logic itself never needed to be recompiled no matter what the target platform was. It was also fairly easy to extend the system which can be witnessed by the numerous versions of AGI interpreters produced by Sierra.

By the time these games were created, storage was limited and expensive. To reduce asset size, the game’s background images were defined as vector graphics instead of full raster images. When the game needed to display a new background image, it was drawn into a buffer and finally blitted to the screen. This is interesting because this theoretically allows us to rescale the images to any resolution. It’s also interesting from an artistic perspective as it allows us to trace how the artist originally drawed the pictures, command by command.

Topical for 2021: Adobe Flash Player, another type of runtime technology for interactive content. Very much ahead of its time, now finally being laid to rest by its corporate owner who chose the path of closed source propriety rather than attempting to using the technology to set a standard.

With my AGI web runtime, you can load the original game files directly and play them in your browser.

In building on this project I’ve also stumbled upon lots of cool tidbits along the way. For instance, I figured out why the game engine doesn’t handle F11 and F12 keys: the game engine’s initial hardware target was the IBM PC Jr (1984), which doesn’t have those keys on its keyboard.

I forked the original library and implemented a large number of features. The additions I added made it possible play Space Quest II in the interpreter. Lots of low-level VM debugging was done to get to a workable state and its compatibility is still low.

Progress at 2021-01-09.

Sample of the TTS enhancement.

Longer video demo of the runtime in action playing SpaceQuest 2.

Major changes

  • TTS for all in-game dialog text
  • saving and restoring game states to localstorage
  • Implemented the menu bar common to AGI games
  • Implement available player actions as buttons
  • Game objects respect priority areas on-screen
  • Fix drawing routines to be more compatible with behavior seen in published games
  • Implemented missing movement modes for game objects (chase player, etc.)
  • Implemented inventory item graphic display
  • Implemented interpreter clock

The changes were transformational to the original project. It is much more of a complete game engine than the JS tech demo of the original agi.js project. As with any large and novel software project: devils were in the details. Confronting quirks in the VM bytecode, register implementation, and hacks used by the game designers / developers to afford compatibility with published games gave me tremendous opportunity to learn about ABI design (Application Binary Interface) and emulation.

For now this fork of the project has paused, source code being available here: https://github.com/jsyang/agi.