The Let's Play Archive

Hadean Lands

by ManxomeBromide

Part 12: Bonus Tech Post: The Hadean Lands Software Stack

Part 12: Bonus Tech Post: The Hadean Lands Software Stack

We've just reached, approximately, the halfway point in the game. This seems like as good a time as any to discuss what this application I've been running actually is. This isn't super-revolutionary but it is sort of amusing because there is in fact a clean line of descent here all the way back to Zork.

The application itself that I've been taking screenshots from is a program called "Lectrote", and that is how it identifies its interpreter when you type >VERSION. Lectrote itself is a JavaScript text-game engine executing in Electron—which is a fairly generic wrapper program you use to turn web-based applications into desktop ones. (Slack and Discord use it for their desktop versions, for instance.) Lectrote basically includes a complete copy of Google Chrome and a JavaScript-based internal web server, and that's why a text game ends up being fifty megabytes when you download it from Steam.

The interpreter that's actually being run is called "Quixe", and that in turn is an implementation of the "Glk" graphics library and the "Glulx" virtual machine.

And yeah, Plotkin is not well known for naming his technologies things that are easy to pronounce. I suppose it makes it more unlikely that you've accidentally named it after something that already exists. I personally pronounce them "lecked rote", "quick see", and "Glk" and "Glulx" as rhyming with "bulk" or "bulks".

Glk was an attempt to make it reasonably possible to have mega-interpreters in the early 2000s for all of the various text game file formats. This worked well enough but by the 2010s it seems like HTML is the new standard.

Glulx, on the other hand, is a 32-bit extension of the "Z-Machine", which is something Infocom invented in the 1980s to solve a problem that we don't face as much these days. Back then, there were a half-dozen wildly incompatible but also wildly popular different kinds of home computers. Being able to sell their games as broadly as possible would mean having to rewrite the game for every platform. A lot of software houses would actually do this for action-style games, and you can still see the occasional flame wars about which version of some 8-bit game is the best one.

Infocom solved their problem by, essentially, inventing Java ten years early. They'd make a simple virtual computer, compile their source code to that, and then just write one emulator for that virtual computer on each target system. As a result, the Z-Machine was built to cap out at 64KB of RAM and a chunk of "ROM" that it could load in from disk as needed, which in turn let the game run seamlessly despite being larger—sometimes much larger—than you could fit into memory all at once.

Infocom themselves used a language called ZIL (Zork Implementation Language) to write their games. This was a dialect of Lisp, and code looked something like this:
code:
<ROOM LIVING-ROOM
  (LOC ROOMS)
  (DESC "Living Room")
  (EAST TO KITCHEN)
  (WEST TO STRANGE-PASSAGE IF CYCLOPS-FLED ELSE
    "The wooden door is nailed shut.")
  (DOWN PER TRAP-DOOR-EXIT)
  (ACTION LIVING ROOM-F)
  (FLAGS RLANDBIT ONBIT SACREDBIT)
  (GLOBAL STAIRS)
  (THINGS <> NAILS NAILS-PSEUDO)>
As far as I know, nobody but Infocom actually used ZIL. However, in the early 1990s, Graham Nelson created a tool called "Inform" that produced very similar output files that could be run on Infocom interpreters. Inform is much more in the C- or Java-like school of language design:

code:
Object Living_Room "Living Room"
  with name 'living' 'room',
   e_to Kitchen,
   w_to [; if (cyclops_fled) { return strange_passage; } else { "The wooden door is nailed shut." } ],
   d_to trap_door,
  has light, land, sacred;
Inform was a major IF development language in the late 1990s and early 2000s, and as ambitions grew, the Z-machine was expanded in various ways so that people's designs wouldn't be constrained by the old necessity of only having 64KB of RAM and a few diskettes' worth of ROM. Glulx was the final evolution of that, expanding the instruction set and execution model to a full 32-bit address space. In Plotkin's words, he did it this way because it was easier to invent Glulx than it was to modify Inform to emit something more generic. Hadean Lands blows past the old limits; the part of the package that is actually Glulx code and data clocks in at a bit over two megabytes. Most Glulx games are not so vast.

Note that there is also considerable similarity in the Inform code and the ZIL code that's roughly equivalent. Inform would produce a RAM layout that was extremely similar to the old Infocom game engine. (Similar but not identical; Inform's standard library could do all the things late Infocom games could do, but they were implemented from scratch in Inform itself. The Z-Machine included a lot of special instructions for dealing with text, but the world model was reasonably generic.)

In 2006, Nelson released the first public beta of "Inform 7", which was a dramatic departure from its predecessors in both structure and syntax. Game objects no longer have the same structure as they did, the logic of command processing is based on series of "rulebooks" and declarative assertions, and the language syntax borrows the parsing capabilities of the text game itself:

code:
The Living Room is east of the Strange Passage, west of the Kitchen, and above the trap door.
The Living Room is lit.

A room can be terrestrial or aquatic. A room is usually terrestrial.
A room can be sacred or profane. A room is seldom sacred.

The Living Room is sacred.

Before going west from the Living Room when the Cyclops is on-stage:
    say "The wooden door is nailed shut." instead.
Usually making a programming language read like natural language ends in hilarious disaster, but Inform 7 largely got away with it. I think a big part of that is because you're writing something that needs to accept commands that look like this anyway, so framing the assertions as text-adventure-like sentences ends up exploiting the "don't repeat yourself" rule. (The late 1990s are littered with games that had game critical objects that were never described with any word that it would allow the player to type. Inform 7 lets objects have multiple words in their in-source identifiers, and it uses every word in that identifier as a default thing the player can type to refer to it. This can be overridden, but carelessness no longer results in an unplayable game.)

There's also a strong notion in Inform 7 of intercepting actions before they happen (as in the "Before going west..." rule). That kind of structure makes it a lot more reasonable to attempt something like Hadean Lands's autosolver ("Before taking something from the kiln when the player is not fire-immune..."), though it's still a terrifying amount of work to do. Nevertheless, Plotkin was already famous at this point for the things he'd managed to accomplish using the Inform 6 systems, and for him to say that Inform 7 was a necessary tool for Hadean Lands... it's a bit sobering.

That pretty much covers the technology used for the game here, though. If you want more information on any of these things, Google searches will turn up relevant stuff pretty much immediately. (I suppose that's another advantage of utterly unpronounceable names.) But in short, here we are, using Steam to run a web application wrapped for desktop use that is running a 32-bit extension of original execution engine of the original Zork games.