Fine, ok, let’s split hairs, if you’d rather.
Right. Completely unguessable, since I had just said I didn’t use Gargoyle and the question specifically targeted the PC.
I’ll rephrase.
“I never used Gargoyle because it doesn’t support v6, or graphics in HTML TADS, and I figure I might as well stick to the “official” interpreters of each language, which do support everything for that particular language.”
I’m not splitting hairs, I’m trying to unclog your post for newbies. The terminology around Glulx is already very confusing and, especially for authors who are trying to get a handle on what’s out there (like the OP), it’s very helpful if things are not over-muddied. But the way I did it was subject to misinterpretation, so let me give it another go:
There are really only two Glulx interpreters, called “Git” and “Glulxe”. Those two are the basis for all of the various Glulx applications, from Gargoyle to Zoom to Windows Glulxe and Windows Git. Those applications also incorporate a Glk library and display and UI libraries:
There are other Glk implementations (CheapGlk, for example), but they don’t provide multimedia support.
The situation is probably even more complex than this, but that’s about as deep as my understanding goes… Probably someone will offer some corrections.
There are no “official” interpreters that are really consumer-grade, except perhaps for Mike Robert’s TADS interpreters, which also serve as the reference implementations for TADS (I think). If you are going to develop games for Glulx, though, you need to be sure that your game runs well on the interpreters in the bulleted list above. (I wouldn’t worry about Spatterlight too much. It’s no longer updated, a bit buggy, and a bit slow. Major new features are being incorporated into Glulx this year, and Spatterlight is unlikely to get any of them.)
–Erik
Ah. In that case, I apologise for the sarcasm in my reply. Cheers.
If you don’t mind unclogging it a little more, what is Glk exactly? What is a “Glk library,” and what’s the significance of different Glk implementations?
Glk is code that sits between a Glulx interpreter and the operating system. It takes care of stuff like reading input from the player, data from files, opening windows and displaying stuff on them, etc. It has been used for VMs other than Glulx too though.
If someone implements Glk for a new operating system, then porting all interpreters that use Glk to that system is much easier, because Glk contains the bulk of the system-specific code. The rest of the code is portable which compiles and runs everywhere.
You can imagine Glk as being a cross-platform, IF-specific, text, graphics and sound library.
No matter what interactive fiction system you use, there are going to be a lot of operations that they all provide: draw text, request user input, show a save-file dialog, and so on. The problem is that each operating system has its own method for doing these things. If I wrote code to display text on a Unix terminal, that same code would not work to display in a window on a Windows system.
Glk serves as a layer between an interpreter and the operating system. Instead of writing Unix-specific code, you instead write Glk-specific code. Once this is done, the same interpreter can be built to run on any system for which a Glk library is available.
So a Glk library contains the operating system-specific code, which means you have one Glk implementation for Windows, another for Unix, and so on. The advantage to this is analogous to the advantage of using the Z-machine instead of writing your game for a particular operating system. Once you’ve written an interpreter that uses Glk, it will run wherever Glk is ported, much the way that a game written for the Z-machine will run everywhere a Z-machine interpreter has been written.
Different Glk libraries provide different user interfaces, more or less. Windows Glk, for example, provides an interface that is familiar to Windows users, complete with Windows-based file dialogs. glkterm, on the other hand, is a completely text-based interface for Unix users, presenting an interface similar to, say, Infocom’s games on MS-DOS. However, an interpreter doesn’t have to care which version is being used: the programmer’s interface is identical for all Glk libraries; it’s just the user interface that varies.
As such, end-users need not care about Glk. If you use Gargoyle, for example, you’re using a Glk library, but that knowledge is immaterial. Glk should be invisible to the end-user. If you’re writing an interpreter, on the other hand, using Glk is probably a smart choice. By using Glk, you’ll get an interpreter that works on at least Unix, MacOS, and Windows; and what’s more, when a new Glk library is released (say, for a smartphone), your interpreter will automatically work with it.
The biggest downside to Glk, currently, is probably the lack of control over text styles. This is an understandable choice, because Glk has to cater to systems where text style support might be minimal or non-existent, but it does limit fine-grained control over text appearance (you can say text is emphasized, or is being used as a header, and so on, but ultimately the Glk library gets to choose what happens). And if you’re writing a Z-machine interpreter, you will not be able to support version 6 stories, at least not properly. Zarf made the reasonable choice to accommodate future games rather than ensuring that Journey, Shogun, and Arthur will be playable on Glk interpreters. I’ve tried shoehorning V6 support into a Glk interpreter and it just doesn’t work.
Thanks for the explanations!
Yes, this has cleared up a heap of stuff for me. Thanks.