I have quite a bit of respect for the fact that this is a successful, real-world program developed using Literate Programming. It's a style of programming which has interested me before, but like many other people, I've found it hard to do in practice, and tools to be lacking.
As an aside, the interactive fiction community is from a technological perspective a fascinating microcosm, including from a CS perspective. You have not just one toolchain, but an entire ecosystem of competing virtual machine specifications (Z-Machine, Glulx, TADS, Hugo), compilers, and source languages, all intending to deliver architecture-independence and the ability to preserve IF for the ages, yet apart from all general-purpose technologies typically used for the task.
Glulx is a simple, 32-bit virtual machine created to replace the Z-Machine. Both have numerous implementations. Glulx is itself used with an extensible I/O abstraction layer, and as I recall has been used with numerous I/O systems. Usually it is used with Glk, but I recall some outfits trying to sell commercial IF defined their own custom I/O system using the same Glulx virtual machine to provide greater capabilities.
Inform 7, as people are probably aware, is itself an experiment in source languages which read like natural language. The compiler produces Inform 6 as an intermediate language, and then invokes the Inform 6 compiler. The Inform 6 language as far as I'm aware was a product of reverse engineering the Z-Machine, and is completely different to the language Infocom originally used to produce Z-Machine images (though I believe that source is now released for those with historical interest).
It wasn't all Inform, though. TADS was an interesting second fiddle and one I personally preferred, being designed to appeal as far as I can tell more to programmers. The downside is it probably led to less popularity; though I personally don't really find myself thrilled at the prospect of writing Inform 7 with its unusual language, it's clearly won.
TADS 3 in particular featured an extremely sophisticated object-oriented virtual machine, which was very complex compared to the simplicity of the 32-bit Glulx machine. It's an impressive piece of technical work which I find fascinating, but my understanding is that despite fairly good documentation on the system's internals, nobody besides its original author ever managed to write their own implementation due to its intricacy. The VM is open source so this isn't the biggest deal, but having multiple implementations is a big deal, especially for something intended to allow works to be preserved through the ages.
Whereas the Inform ecosystem went with Glulx and the Glk I/O system, TADS chose to adopt HTML to facilitate formatting and multimedia functionality. This seemed like a natural choice, yet I distinctly recall finding it hard to find HTML TADS implementations for non-Windows platforms years ago. In the modern era, where people want to play IF in a browser, you would expect TADS to come into its own, but this has not been so. In a remarkably strange and in my view mistaken move, TADS chose to add web functionality by allowing (if I recall correctly) TADS projects to be recompiled so that the VM hosts a web server. Since it requires projects to be recompiled, and for two images to be shipped - one non-web, one web - it seems like an incredibly bad decision and undermines the whole point of having a universal image.
There are countless other engines, of course - ADRIFT, which was popular due to its GUI-based editor. "Hugo", which was used for the commercial game "Future Boy" and which emphasized multimedia capabilities.
Another angle to consider is sandboxing - all of these VM systems were designed to offer good sandboxing. Arguably the wider world is only just catching up with this now with the rising popularity of WebAssembly for non-web applications. The growth of the non-web WebAssembly ecosystem and sheer availability of different runtimes is really nice to see and the ready availability of VM systems which are both sandboxed and architecture-independent seems to be enabling all sort of interesting research and development. Who knows, maybe we'll see WebAssembly be adopted for IF-related use in the future.
I'd like to add that, perhaps surprisingly given how niche a field it is, the interactive fiction community keeps producing new languages and tools. In recent years, two new parser game programming languages have appeared: Dialog by Linus Åkesson (https://www.linusakesson.net/dialog/docs/index.html), a full-featured language inspired by Prolog; and Gruescript by Robin Johnson (https://github.com/robindouglasjohnson/gruescript), simpler but focused on creating web games, playable without writing, with a verb+object model like parser games.
One of the annoying things about TADS games from the user perspective was the limited selection of interpreters, because it wasn't open source. The Z-machine interpreters could be pretty nice and were widely available.
> TADS projects to be recompiled so that the VM hosts a web server
I don't know how long ago that was, but it wasn't always obvious that moving everything to JavaScript was the way to go for stuff like this. At one point that might have been a reasonable technical choice.
Well, Inform6-7 and the Z-Machine from mainframes like the TOPS20 OS from Ka10 made in the 70's to pocket devices with Android/iOS wins by a huge margin on freedom and sharing the game to near anywhere.
And with Puny Inform you could adapt a relatively small game to even the Commodore 64.
>(though I believe that source is now released for those with historical interest).
No. There was (and still it's) a huge ecosystem made with Inform6, even targetting the web if you chose GLULX and some of the settings which export the game for you.
There's Inform6, the Inform6 English Library (and some other s such as INFSP6 for Spanish, kinda close to the English one, the syntax is the same, even for the objects), and two manuals: the IBG, and DM4, the Designers' Manual, for hardcore people who want to create for example new libraries doing unusual things.
I'm unsure what you're responding to. The part you quoted refers to the original language used to produce Z-Machine files, ZIL. We know what ZIL looked like:
Ah, ok you meant ZIL and Muddle. Yes, I've know them, but I never used them.
Nowadays I've tried to ask some Dungeon/MIT maintainers to set Dungeon (Pre-Zork prototype which has the Zork I-II-III games condensed) under a free license, but I had no luck.
EDIT: Also, IF6 it's pretty good by itself, the included English library it's pretty good for a common game, reimplementing new objects it's trivial.
IF7 makes that easier, but forget about playing your games on DOS and Amiga machines.
For sandboxing and historical preservation, it helps that interactive fiction is text-based, single-player, and non-networked. I wonder if they've added any way to connect to a server?
There was a mud based implementation of Inform 7 based multi player IF platform called Guncho, but it’s not maintained. It was an interesting experiment.
assuming you're talking about z-machines, the only functioning way i've seen to get data out is to use savefiles. there is an editor written in inform that does this. otherwise the interpreter has to be modified, see multizork for example.
+1 for a nice review. You may be interested to know that there's been some success cross-compiling the command-line version of the TADS 3 VM interpreter to Javascript, I think you can play T3 games in Parchment now.
I have quite a bit of respect for the fact that this is a successful, real-world program developed using Literate Programming. It's a style of programming which has interested me before, but like many other people, I've found it hard to do in practice, and tools to be lacking.
As an aside, the interactive fiction community is from a technological perspective a fascinating microcosm, including from a CS perspective. You have not just one toolchain, but an entire ecosystem of competing virtual machine specifications (Z-Machine, Glulx, TADS, Hugo), compilers, and source languages, all intending to deliver architecture-independence and the ability to preserve IF for the ages, yet apart from all general-purpose technologies typically used for the task.
Glulx is a simple, 32-bit virtual machine created to replace the Z-Machine. Both have numerous implementations. Glulx is itself used with an extensible I/O abstraction layer, and as I recall has been used with numerous I/O systems. Usually it is used with Glk, but I recall some outfits trying to sell commercial IF defined their own custom I/O system using the same Glulx virtual machine to provide greater capabilities.
Inform 7, as people are probably aware, is itself an experiment in source languages which read like natural language. The compiler produces Inform 6 as an intermediate language, and then invokes the Inform 6 compiler. The Inform 6 language as far as I'm aware was a product of reverse engineering the Z-Machine, and is completely different to the language Infocom originally used to produce Z-Machine images (though I believe that source is now released for those with historical interest).
It wasn't all Inform, though. TADS was an interesting second fiddle and one I personally preferred, being designed to appeal as far as I can tell more to programmers. The downside is it probably led to less popularity; though I personally don't really find myself thrilled at the prospect of writing Inform 7 with its unusual language, it's clearly won.
TADS 3 in particular featured an extremely sophisticated object-oriented virtual machine, which was very complex compared to the simplicity of the 32-bit Glulx machine. It's an impressive piece of technical work which I find fascinating, but my understanding is that despite fairly good documentation on the system's internals, nobody besides its original author ever managed to write their own implementation due to its intricacy. The VM is open source so this isn't the biggest deal, but having multiple implementations is a big deal, especially for something intended to allow works to be preserved through the ages.
Whereas the Inform ecosystem went with Glulx and the Glk I/O system, TADS chose to adopt HTML to facilitate formatting and multimedia functionality. This seemed like a natural choice, yet I distinctly recall finding it hard to find HTML TADS implementations for non-Windows platforms years ago. In the modern era, where people want to play IF in a browser, you would expect TADS to come into its own, but this has not been so. In a remarkably strange and in my view mistaken move, TADS chose to add web functionality by allowing (if I recall correctly) TADS projects to be recompiled so that the VM hosts a web server. Since it requires projects to be recompiled, and for two images to be shipped - one non-web, one web - it seems like an incredibly bad decision and undermines the whole point of having a universal image.
There are countless other engines, of course - ADRIFT, which was popular due to its GUI-based editor. "Hugo", which was used for the commercial game "Future Boy" and which emphasized multimedia capabilities.
Another angle to consider is sandboxing - all of these VM systems were designed to offer good sandboxing. Arguably the wider world is only just catching up with this now with the rising popularity of WebAssembly for non-web applications. The growth of the non-web WebAssembly ecosystem and sheer availability of different runtimes is really nice to see and the ready availability of VM systems which are both sandboxed and architecture-independent seems to be enabling all sort of interesting research and development. Who knows, maybe we'll see WebAssembly be adopted for IF-related use in the future.