Gargoyle Interpreter Download
Joie Coffield
Most interactive fiction is distributed as portable game files. These portable game files come in many formats. In the past, you used to have to download a separate player (interpreter) for each format of IF you wanted to play.
Gargoyle is an interpreter program for interactive text adventure games, like 'Lost Pig', reviewed here recently. There are numerous text adventures available to download online, and if you are the sort of person who'd enjoy that type of thing, you'll need an Interpreter like Gargoyle.
It's now possible to make speech-dispatcher an optional dependency (-DWITH_TTS=DYNAMIC)! I've also made a few changes to the gargoyle package to fix the licenses and help it conform to the Arch package guidelines. You might want to have a look.
This package is now updated to Gargoyle 2022.1. Thank you for all the effort you've put into both developing it and making it easy to package, cspiegel! The current commit is mostly based on the gargoyle-git package, so thank you to dbedrenko for keeping that package building as Gargoyle evolves, too.
Gargoyle is a multi-platform, multi-if-system interpreter forInteractive Fiction. It focuses on good typography in games. Because ituses a Glk API library, it does not support anyadditional windows besides the status line. That said, there is supportfor both sound and graphics.
The more forceful approach is to use a library contribution likeGlk.h to determine if your game is being played on aGlk-based interpreter. If it is, you can choose to notplay the music file or display the graphic, giving Gargoyle nothing torip out of the resource file.
I've been bemoaning the slightly run-down state of IF interpreter software. (The confusing font preference system in Gargoyle is just one example.) The fact is that the big surge of open-source IF activity was the late 90s and early 00s. Since then, coders have been drifting out of the community, and the ones still around have gotten lazy. (I include myself in that indictment, for damn sure.)
Why CSS and Javascript? Because they have already conquered the universe, so we might as well give in to our anger and rule at their side. Also, the most commonly-used IF interpreters are written in Javascript, which makes adding these new features trivial. (If we plan correctly.)
I don't mean that your Inform code will output HTML. For simplicity, and to maintain a clean separation of concerns, the Glk calls in the Inform library will remain the same. You'll set a style and print some text. The interpreter's job will be to either translate those calls into HTML (as defined by the spec), or do the equivalent job of text display.
Nor do I mean that interpreters will have to support every crazy CSS trick that Firefox is capable of! Far from it. The idea is this: whatever display capabilities the interpreter does have, let CSS guide where it's used.
If an HTMLified Gargoyle had the CSS/Javascript support to run Twine games, it should also be able to run TADS 3 webui games. HTML TADS for Windows can run webui games on the desktop - it just starts the game as a server in the background, opens a window containing a browser widget, and directs the server output to the widget. I believe Mike Roberts intended for most TADS interpreters going forward to support webui games as well as traditional TADS UI games, but as with many other IF tech projects, nobody has yet had the time/energy to make that happen.
I do think Gargoyle is super important for parser IF. And especially for people using Macs at the moment. It's the most up to date Mac interpreter, the only one with sound (and the sound is no longer up to date, and there are sound bugs) and it's still out of date with glk per se, and there are the darn preferences that should be in a menu. The fact that people have hacked Gargoyle just to get a popular game to run (eg Counterfeit Monkey) shows how important it is that it needs to be fixed.
A developer's attitude may be: it's not Gargoyle that necessarily needs fixing, we just need a good new Mac interpreter. But I assume if all that work's already been done on it, why duplicate it? I also assume a result could be gained faster by building on what's already been done. And Dannii has pointed out why Gargoyle has qualities that are useful for IF in general.
It's been a couple years since I've had time to play much IF, which was always my primary motivation for working on the interpreter side of things. I suppose that puts me in either the "lazy developer" or "drifted away" camp, though my heart is still with the community and there's a lot I would like to do with Gargoyle if I could find the time.
If you settle on a patronage service I am happy to send money your way. I doubt you want to tackle another large IF project straight away, but one approach would be to tie the Glk changes to a new game that relied on them. From a fundraising perspective, that would bring together the people who care about the interpreter ecosystem and the people who love your games, and maximize the contributions from those in both camps (like me).
I also think that CocoaGlk is important -- Mac I7 is based on it, for one thing. If CocoaGlk gets bug fixes, then Zoom will be a viable Mac interpreter again (and I7 will be more stable.) That's not duplicating work; it needs to happen too.
In a way, I think garglk is the least important part of Gargoyle. I doubt it would take too much to swap it out for another glk implementation. That's the point of the glk api. The important part, what makes it more than a Glulx interpreter, are all the glkified VMs brought together into one makefile.
I started implementing an interpreter for the language described in the powerpoint slides, partly to see if I could in fact do it within a day. Although I don't have a full day to spend on it, what I have at least has legs and "undefined identifier" errors. When I can write Cloak Of Darkness in it, I can share it with everyone.
And I am in fact aiming at the latter: make an interpreter quickly/easily to prototype some of these ideas, and let Cloak of Darkness or whatever expose the issues empirically. It's a lot easier for others who don't geek out about PLs to understand the issues with [non-]working examples. More people = more ideas = higher % of getting a great one.
Download the demo game here. To play the demo, you will need the latest version of your favorite Glulx interpreter, such as Gargoyle, Windows Git, or Zoom (see links at right). Users of the Spatterlight interpreter are advised to upgrade to Gargoyle.
Gargoyle is an interactive fiction (IF) player that provides a cross-platform IO layer, supporting all the major IF formats. It offers a convenient way to play IF games, as it eliminates the need to download a separate player (interpreter) for each format.
In June 1977, Marc Blank, Bruce K. Daniels, Tim Anderson, and Dave Lebling began writing the mainframe version of Zork (also known as Dungeon), at the MIT Laboratory for Computer Science, directly inspired by Colossal Cave Adventure. The game was programmed in a computer language called MDL, a variant of LISP. The term Implementer was the self-given name of the creators of the text adventure series Zork. It is for this reason that game designers and programmers can be referred to as an implementer, often shortened to Imp, rather than a writer. In early 1979, the game was completed. Ten members of the MIT Dynamics Modelling Group went on to join Infocom when it was incorporated later that year. In order to make its games as portable as possible, Infocom developed the Z-machine, a custom virtual machine that could be implemented on a large number of platforms, and took standardized "story files" as input. In a non-technical sense, Infocom was responsible for developing the interactive style that would be emulated by many later interpreters. The Infocom parser was widely regarded as the best of its era. It accepted complex, complete sentence commands like "put the blue book on the writing desk" at a time when most of its competitors parsers were restricted to simple two-word verb-noun combinations such as "put book". The parser was actively upgraded with new features like undo and error correction, and later games would 'understand' multiple sentence input: 'pick up the gem and put it in my bag. take the newspaper clipping out of my bag then burn it with the book of matches'.
One of the most important early developments was the reverse-engineering of Infocom's Z-Code format and Z-Machine virtual machine in 1987 by a group of enthusiasts called the InfoTaskForce and the subsequent development of an interpreter for Z-Code story files. As a result, it became possible to play Infocom's work on modern computers.
Works may be distributed for playing with in a separate interpreter. In which case they are often made available in the Blorb package format that many interpreters support. A filename ending .zblorb is a story file intended for a Z-machine in a Blorb wrapper, while a filename ending .gblorb is a story file intended for a Glulx in a Blorb wrapper. It is not common but IF files are sometimes also seen without a Blorb wrapping, though this usually means cover art, help files, and so forth are missing, like a book with the covers torn off. Z-machine story files usually have names ending .z5 or .z8, the number being a version number, and Glulx story files usually end .ulx.
c) Find your TQ file (it's a file ending in .gblorb) and open it with the interpreter program (git, or gargoyle, or whatever you chose).
Tip: Just move the Trapquest game files to the folder where git.exe is located.
1) A glulxe interpreter program (you open this program and then select the game file): many are available, Windows Git is strongly recommended for any machine that can run it (if your overzealous antivirus has a problem with area57's improved speed version, there's an older official version here). Another interpreter called Gargoyle is available on multiple platforms but is more prone to crashes. If you're having trouble consult this page.
df19127ead