Glk

There are an awful lot of IF languages with their own virtual machines, and several more are being written. There are also a lot of different platforms out there, and new computer hardware and new operating systems are also appearing at a not inconsiderable clip. This has led to a problem that should sound fairly familiar if you've read the preceding sections. Every time a new IF system comes along, people need to write an interpreter for every platform they want to be able to play your system's games on: Windows, DOS, Mac, Acorn, Amiga, BeOS, Unix, and many many more. And every time a new platform on which IF can be played comes along -- let's say people want to play on a MUD, or on a Internet-capable cell phone -- the new platform needs a Z-code interpreter and a TADS interpreter and a Hugo interpreter and an ALAN interpreter and so on and so forth.

Furthermore, a lot of the work involved in writing an interpreter is wasted effort. See, an interpreter has to do two more or less independent things: data processing -- parsing, keeping track of the objects in the game, things like that -- and input/output (called I/O for short), which deals with how exactly the stuff the program says to print is displayed. And with limited exceptions (which we'll deal with shortly), the data-processing part doesn't care about the I/O part. It will tell the I/O portion the machine-code equivalent of "Here, print out these three sentences," but it doesn't matter to the data-processing part whether those sentences appear as plain text in a Unix shell or if they appear in a fancy font in a graphical window with scroll bars. By the same token, the I/O part is only concerned with showing the stuff it's told to show. It doesn't care about all the algorithms the data-processing part used to arrive at its decision of what to print. It just cares about doing the actual printing. This means that while the data-processing portion of all Z-machine interpreters is going to be close to identical, the I/O portion will vary drastically: DOS Frotz, designed for use in an environment with no support for various fonts, requires much different text-printing routines from WinFrotz. Similarly, while the data-processing part of various Mac interpreters will be quite different -- TADS and Inform and AGT and such just don't crunch the numbers the same way -- the part of the interpreter than deals with look and feel, the I/O, will be pretty much the same no matter what VM is being used. But since every possible pair has to be put together, the work ends up being redone many times over.

Enter Glk. Glk is an attempt to make this whole process more efficient by separating the two functions of the traditional IF interpreter. It does this by defining a number of routines, written in the computer language C and collected in the Glk library. Programmers familiar with C can then write Glk applications, which do the data processing and report the results in a format Glk can understand -- GlkInform, GlkTADS, and so on -- and Glk libraries (also called "Glk implementations"), which adapt the Glk functions for a specific platform: WinGlk, XGlk, MacGlk, etc. The interpreter writer then has little more to do than stick applications and libraries together.

If it's not clear how this is helpful, imagine it like this. Let's say that instead of trying to get from IF languages to various platforms, we were trying to construct a train system to carry people from various cities on the west coast of the US -- Seattle, Portland, San Francisco, Los Angeles, etc. -- to cities on the east coast: Boston, New York, Philadelphia, Washington, and so forth. The pre-Glk system of direct links would mean that we'd build tracks from Seattle to Boston, Seattle to New York, Seattle to Philadelphia, etc., then Portland to Boston, Portland to New York, etc. If a new starting point came along, we'd have to build a whole new set of tracks: San Diego to Boston, San Diego to New York, etc. And the same goes for any new destinations: we'd have to build Seattle to Miami, Portland to Miami, SF to Miami, and so on. What Glk does is establish a hub. In our analogy, let's say that's Omaha, Nebraska. So instead of building tracks directly from starting points to destinations, we build Seattle to Omaha, Portland to Omaha, SF to Omaha, etc., and then Omaha to Boston, Omaha to NY, etc. This drastically cuts down on the number of tracks we have to build. And if a new starting point comes along, we only have to build one new track: San Diego to Omaha. New destination? One track: Omaha to Miami. And people coming from SD can change trains in Omaha and go to any destination, and people coming from anywhere on the west coast can change trains in Omaha and go to Miami.

So let's say someone writes a brand new IF language called ABC. No need to write interpreters for ABC-to-Windows, ABC-to-Mac, ABC-to-Palm; instead, just write ABC-to-Glk, and people on all platforms with Glk libraries can play ABC games. Similarly, if Toastent Technologies releases the Cybertoaster, all that need be written is a Glk-for-Cybertoaster library, and the Cybertoaster is instantly equipped to play Inform games, TADS games, Hugo games, or games using any other system for which there's a Glk application -- all Cybertoaster users need is someone to put the library and the applications together to make interpreters.

You may be wondering: Glk applications take virtual machines and reformat their output so that Glk can understand it. Are there any virtual machines whose output is already tailor-made for Glk? The answer: you bet. That's what Glulx is.