Multi- interpreters. Spatterlight, Gargoyle, Fabularium, Parchment, Lectrote, ScummVM etc.: Portable "terps" and preservation of too many IF interpreters

Technical Development Interpreters
1

Hello.

I’m a newcomer that is discovering the world of interactive fiction. Maybe my opinion is quite different and erratic, so I would love to see diverse comments and opinions.

I’m mostly interested in retrogaming, specially in digital preservation by open source software.

At first, I tought there were just a few IF systems such as Z-Code and a few more. Then I discovered projects such as Gargoyle and Mac-centric Spatterlight, using “terps” to add them by the Glk (API?). To me, its quite comfortable to have all IF interpreters in the same interface.

A but later, I discovered an uglier reality toe. Some IF interpreters lacked a portable and Open Source implementation between them, had one but not integrated in multi-interpreters or available anywhere:

  • ScummVM’s ScummGLK: It implemented support for Archetype by reimplenting Pascal code to C++ and Comprehend by merging and heavily modifying a Comprehend interpreter.
  • Spatterlight added Quill support by adding an John Elliott’s UnQuill terp, but nor Gargoyle nor ScummVM has it. It seems to convert to Z-Code to play not sure if that conversion makes it lack certain stuff such as graphics. No idea about unqbbc usage, as BBC Micro support is absent in UnQuill.
  • John Elliott’s unplad and unphipps code is still there but it seem to not be interpreters at all.
  • Gackle exists to support GAC interpreter, but no other interpreter support it and less by using a terp. The same about Ascape for Adventurescape, developed by same developer (tautology0 at GitHub).
  • There are some interesting interpreters of PAWS for Z80 machines by saimazoom on GitHub and DAAD for MSX by nataliapc on GitHub. Those are not truly portable and feature complete. There aren’t others for the diverse (more than it seems) Quill/PAW(S) family at all too, forget about SWAN and many less known ones.

The list goes nearly to the infinite if your threshold of obscure old games gets to the max.

I understand constructive and proactive software R&D preservation is quite massive and difficult, requiring reverse engineering and using tools such as disassemblers and decompilers. This makes support lots of IF interpreters in portable form a daunting task.

Why a few metainterpreters instead a massively portable one? What about merging code and develop a portable one such as Gargoyle and ScummVM? I understand native widgets and such are nice, but compromises and backend code for each platform may solve this liking. ScummVM is based in Gargoyle/Garglk code, AFAIK.

I see an IF project needs to gain a lot more critical mass to see interested developers implement old interpreters and such (terps?). This critical mass may attract more developers and even participate in events such as Google Summer of Code.

I like features of both Gargoyle and Spatterlight, I consider them to be great projects. Fabularium and Hunky Punk are quite interesting, but they seem dead. Gelek Vanilla seems not so active too. Parchment and Lectrote seem quite interesting. ElseIFPlayer seems interesting but a other inactive project.

ScummVM has potential, despite supporting RPG and point & click graphical adventure games too.

I consider dividing efforts and public visibility is not so good for IF survival. There’s need of a MAME/MESS-like effort, IMHO.

Native vs non-native isn’t a so big problem, there are ways to compile C/C++ cofe to Javascript and WASM. Emstriptem is a valid way, for example. I prefer natuve, but web apps might be a preference or useful in certain conditions.

IF Archives and databases such as IFDB and CASA are amazing. Treaty of Babel is a great idea. That’s a great goal achievef, it just needs to be even more popularized too.

Glk seems a great concept. Not sure about limitations and if it’s focused on old of new IF systems, anyway.

What do you think?

Thanks in advance!

2 Likes
2

xkcd 927?

5 Likes
3

Would that be reasonably solved by merging two or more projects into one instead forking and mixing them?

Or making code reuse a lot easier between projects? Terps are a good concept, for example. But many projects use C++ and may need to convert the original code from C, such as ScummVM.

DreamMaster wrote the following in ScummVM Glk wiki article:

Whilst at first I tried to keep the sub-engines as close to the original source they’re derived from as possible, this quickly proved impossible. Not only did I have to add in proper C++ namespaces to encapsulate all the code, but I also had to do various conversions to change them over from using STL to using ScummVM classes. So don’t anticipate that it’ll be easy to take any interpreters converted specifically for ScummVM Glk and simply drop them into any other Glk implementations.

4

A lot of it is driven by user demand. No doubt Gargoyle could add some other Glk-based interpreters, but has anyone actually asked? And are those interpreters being maintained, or would the Gargoyle “team” (ie, Chris) be taking on a maintenance burden for an unmaintained terp?

On the other hand, old obscure formats are probably best served by whole-system emulators. For example, archive.org now supports pretty much every DOS game by a WASM port of DosBox. Other old systems have other capable emulators. There’s not much to be gained by pulling those in all together, all it would really help is help people find the right emulator for each game. But archive.org can probably do that for a lot of them.

The retrogaming community is really quite distinct from the IF community. There are of course a lot of overlaps, but the purposes and values of each are distinct. I’m not really part of the retrogaming community, but I’d expect that for a lot of people, part of the fun of the hobby is the process of working out how to best revive the experience of play decades-old games in the most authentic way possible. Many emulators aim to run at original CPU speeds, sometimes because the games won’t actually run if they emulate faster, but sometimes just for authenticity. There are even emulators with fake CRT flicker effects!

So I’m not sure how many retrogaming fans would be interested in Parchment adding support for more old formats. The fans who want to play Infocom games on an old Apple II vs those who want to play in a modern interpreter with crisp 4K text wouldn’t have much overlap. As the maintainer of Parchment I’m serving the latter. If I received a request for a new format to be supported in Parchment I’d consider it, but after 10 years or so of maintaining it I can say that I don’t get requests from retrogamers. In fact almost no one asks me to add support for new formats to Parchment, even of those more from the modern IF community!

9 Likes
5

I’m the (de facto) Gargoyle maintainer; I’ll give my thoughts on some of these questions here from that perspective.

If you mean, why do Gargoyle + Spatterlight + ScummVM exist all to do the same thing, when you could devote resources to one of them, a primary answer (beyond “we want to”, which, in such a niche area with zero/negative monetary incentive, can’t be dismissed) is that consolidating these so-called “metainterpreters” wouldn’t really do anything. The magic that makes them work is Glk, which means that once an interpreter is written, it takes effectively no work to get it working with existing Glk implementations such as Gargoyle or Spatterlight. The work is in the interpreter, not the Glk implementation.

Related to the above, if anybody wants to implement new interpreters, we already do have a single target interface for them to use: Glk. If an old game is roughly shaped like an Infocom game, then there’s effectively no reason not to just write an interpreter against Glk.

I’m not against adding new interpreters to Gargoyle, by the way, but my experience is the same as Dannii’s: there’s just not demand for them. I’ll seriously consider any new Glk interpreters for Gargoyle if somebody makes a request, but I’m just not sure how much interest anybody has in writing new interpreters for obscure old platforms/games, beyond what we already have.

First, I don’t think IF’s in any danger of dying.

Second, I’m not sure what would be gained by combining anything. How would you even start to combine Parchment and Gargoyle, for example? And while there’s definitely overlap between Spatterlight and Gargoyle, combining them won’t really have any effect. It won’t make interpreters start appearing any faster. And there’s already collaboration occurring among us all.

Glk really is the glue that you’re looking for.

ScummVM didn’t need to convert anything: it chose to. Gargoyle is C++, and most interpreters are C, and they’re being used with no issue. Glk defines a C API, and most languages are able to work with a C API. ScummVM had an existing framework they needed to fit into, and modifying interpreters made sense for them, but it does diverge from Glk.

A fun(?) project could be to write a compatibility layer between ScummVM’s Glk for and proper Glk, so the ScummVM-specific interpreters could be used elsewhere, but I’m not sure anybody’d be willing to do that work.

4 Likes
6

I should point out (at risk of repeating common knowledge) that Glk is a most common IF features interface, not a supports absolutely everything that every IF system does interface.

When I came up with the idea 25 years ago, I envisioned Glk as a completely universal interface. But that proved to be impractical and is no longer a goal.

This is why Gargoyle (and Lectrote, which takes a similar approach) is many interpreters with a common interface. This is great for some purposes! (You can set your display preferences once and all interpreters in the app will use them.) But some platform features (notably Z-code color) require extra hacks and don’t necessarily fit in well. Other platform features (like Vorple) will never be part of these universal intepreters.

So a one-universal-app-does-everything approach does not make sense on the face of it.

2 Likes
7

I’m not sure if I understand your opinion correctly.
I would say, in my opinion, that there are two philosophies that goes in parallel: preservation/retrocomputing and accessibility/play in a modern way. One that would be interested in emulating a system and the other in to play a game on any platform.

The way of playing IF as [interface | api | interpreter | game data] is, again in my opinion, the most versatile way of doing this as having one huge code, I think, would fail in supporting everything and would be difficult to maintain.

Some other random thoughts:

The DAAD development has been quite uninterrupted since Aventuras AD broke. Check the repor of Uto Utodev (Uto) · GitHub that has everything you could imagine.
It would be cool to have a glk layer for the DAAD interpreter? Yep. Possible? I don’t think so.

There’s also an IDE / terp implementation in python GitHub - daad-adventure-writer/NAPS: The New Age PAW-like System - Herramientas para sistemas PAW-like

SWAN was an «intermediate step between» (in a lot of inverted commas) PAWS and DAAD with ¿1? game made for it?

I hadn’t time to update it, but I plan to do it (now that Ubuntu Touch upgrades to new version of the OS) but think about it as an experiment. I’m a terrible programmer and GeLeK is sort of a try to learn and set a build system, sort of a Gargoyle for mobile. It uses the same terps and the glk layer, the only new is the frontend. See? If we had only one huge interpreter I probably couldn’t have built it for the mobile OS. In the end, I may be the only one using it.

Anyhow…

1 Like