I’ve added that.
3 Likes
Yes, these one and launcher thunderword.
1 Like
I don’t have an Android device so all these names are confusing me 
Could you share some links please?
1 Like
Thunderword:
1 Like
I’ve changed the first post here accordingly:
Gargoyle (Windows; Mac, HiDPI displays unsupported; FreeBSD; Linux)
Lecrote (Windows; Mac, HiDPI displays supported; Linux)
What’s the Mac display situation with Spatterlight?
1 Like
Spatterlight is Mac only and works great on all modern Macs.
3 Likes
Apologies for the necromancing (Is less than a year kosher? Do we have community standards on that?) but I’m honestly more confused now than when I started reading the thread. I feel like I need a venn diagram, or maybe a slap upside the head. Perhaps, I’m just a little slow.
From this, I tentatively understand that when someone casually says, “Try a different interpreter like Parchment or Gargoyle,” they’re technically referring to a Glk interface which has one of the three aforementioned interpreters imbedded into it, not the imbedded interpreter itself. At least I hope that’s the case, because that’s one if the few bits that I followed. If that isn’t true, I am beyond hopelessly lost here.
Also, is Vorple a library or a Glk interface? Not that I truly understand the difference. I’m honestly not sure when something is being used synonymously or as its own thing. Hell, let’s just get definitive here. I sincerely don’t understand the definitions of the following:
- Glulx Interpreters
- Glk Interfaces
- Glk Libraries
- *.gblorb Players
- Glulx/Z-code players
- Resource Streams
- Inform 7 templates
- User Interfaces
- Version Control Software
- Git SCM
- Glk API
- *.apk
- codebase
I also don’t understand the relations between them. Does anyone have the patience to explain this in little words? I keep reading through old threads like this one, but I find that I have less clarity than when I started.
1 Like
The thread is confusing mostly because people don’t use the terms consistently. I have my own personal definitions, but there are exceptions and corner cases.
Rather than trying to understand the terms for their own sake, I recommend that you just focus on finding an interpreter that you like and that works for you. Here’s a list. https://www.ifwiki.org/Glulx_interpreters
(The IFWiki team spent a loooong time trying to reach consensus about what’s an “interpreter” vs. what’s an “engine,” a “library,” an “app” etc. We didn’t really reach clear consensus, but we did agree that anything that wants to call itself an “interpreter” is one, and that we’d have a clickable “Recommended interpreter” checkbox that users could use to decide whether an interpreter would show up in lists like https://www.ifwiki.org/Glulx_interpreters.)
2 Likes
I think thats right. When we were discussing this while structuring the IFWiki software database the way I tried to understand it was that interpreters are bags of balls… the actual interpreters (like Glulxe) are the bags of balls; single-system/single-interpreter ports (like Windows Glulxe) are the same balls, maybe in a different bag; and things that just package up several actual interpreters (like Gargoyle does) are a big bag containing lots of small bags of balls, but that still makes them a bag of balls 
1 Like
Fair enough and that is certainly sound advice, but I had some intentions that went a quite a bit further than quietly enjoying IF in my home. Ultimately, I’d like to tear some of these apart and put them back together again, in much the way 8-year-old me disassembled my mother’s toaster and then reassembled it just to understand how it worked (it never toasted consistently again). I have some things I’d like to try implementing into an interpreter/interface/player/“thing that displays IF games”/whatever, but I fear speaking too early about such things will give the impression I’d like someone else to tackle the project, and that’s certainly not true. Putting the cart before the horse, let’s say.
That’s simultaneously clearer and more confusing.
There’s nothing like a good analogy…! 
1 Like
Nonetheless, if the first step of your project is to discover the True Meaning of “interpreter,” a clear definition that everyone shares, you’ll never succeed.
If you have questions about how to do something in particular, you can/should just ask how to do that thing. (Even if your question is, “how do I modify the code of X to make it do this thing I want Y?”)
3 Likes
Well you’re asking about 13 things there, though some of them are just different ways of referring to the same thing. It’s a big ask to request an explanation of them all. Also, five of them aren’t even IF-specific things!
I suggest you start with the Glk introduction it explains what Glk is and how it fits into the broader IF ecosystem.
Vorple though is a… special case. It’s not a full independent Glulx IO system (unlike FyreVM). It’s built on top of Glk. But it also doesn’t support most of the Glk functionality. It’s best to think of it as its own IO system which uses Glk as a hidden implementation detail.
1 Like
Agreed, in principle. However, I don’t know enough to even know what specific questions I should ask, let alone understand the answers.
For the sake of transparency of my motivations, but at the risk of severely derailing this whole thing after necromancing it in the first place:
Likely Ill-advised Idea:
I’ve had something bouncing around my brain for awhile now. Even though it currently seems insurmountable, I’d like to learn how to either alter an existing interface like Parchment, or write my own from scratch. I don’t wish to change how it interprets the game files, I only want to tweak the players’ interface with those game files. This is why I’m leaning toward simply creating an alternate version of an existing interface.
The interface I keep imagining has clickable verb slots. These slots begin empty and the interface leaves it to the player to assign the verbs they most frequently use. Any verbs not assigned to a slot are left to the parser (although, if you chose, you would still be able to manually type in a verb that was assigned to a slot). The player could then make changes as certain verbs fall out of favor or new verbs are needed more frequently. Not using “scream” as much, but “mug” is becoming pretty useful? Then replace the verb slot you assigned as “scream” with “mug” instead. That way you achieve a friendly point-and-click user interface, while preserving the broad nature of a parser system. I can envision this set up in conjunction with a basic navigation compass rose (8 cardinal directions) radiating around a circle cut into quadrants; in/out & up/down for the four quadrants. Allowing only a limited number of re-assignable verb slots avoids cluttering up the screen with too many verbs.
While this system could be built into a game, I think it would be more useful built into an interpreter. That way this isn’t a custom solution being laboriously written for a single game. In fact, ideally, it would be backwards compatible, making this UI feature available for past parser titles.
I was contemplating the following features:
- Allowing the player to toggle this optional interpreter feature on and off would make everyone happy. Those that don’t wish to use it don’t need to.
- Attaching the state of the verb slots to any save files made with that interpreter (accompanying text file? special save file? not sure), allowing the player to restore their game with the verb slots as they were at the time they created that save file.
- Make every single individual word of the displayed text selectable; I imagine each word lightly highlighting as the mouse hovers over it. You can then select a word from the displayed text and it will send it to the parser. If you did this after selecting a verb slot you could form simple commands like “look me” or “smell apple.” People have pointed out that highlighting just the implemented nouns in a game’s text is problematic as it gives away too much to the player. By making every single word selectable, you sidestep the issue entirely. Sure, this would allow the player to construct nonsense command strings using the Point & Click interface, but how is that any different than simply typing them in?
- Single-clicking would send a selection to the parser, double-clicking would send that selection to the parser and then submit whatever was in the command line at that point. For example, double-clicking a verb slot would send it to the parser and immediately submit it, as in the stand-alone use of the “look” or “smell” commands. A single click would send the verb to the parser without submitting it, allowing the player to append a noun by clicking on the word in the text. You could single-click your verb slot “take” and then double-click the word “potato” in the displayed room text, which would submit the phrase “take potato” to the game’s parser.
- Allow the player to adjust how many verb slots they wish to appear (within common-sense limits). This serves multiple demographics, from those approaching the parser genre with an apprehension to typing, to those parser pros who wish to include only a button or two for take all and examine out of simple convenience.
- Touch absolutely NOTHING ELSE below the hood. I’d like the interface to work otherwise identically to the interface it was tweaked from.
Obviously, this wouldn’t be a small undertaking, but there is certainly value in it. Not only can I see it being a useful crutch for new players, but it could be a significant quality-of-life improvement for some existing veteran IF players as well. I know there are some very long-time players who have developed motor difficulties (arthritis commonly) that extract a steep price for typing. This might make parser games more accessible to them; reducing the volume of typing as opposed to eliminating it altogether.
I know if I want this to happen, I have to make it so, but to even start this journey, I must first have basic understanding of what I’m even working with. Thus, here I am. That was probably much more than anyone wanted, but hopefully it was at least slightly interesting. If not, I’m sorry for the drag on your time.
1 Like
That is certainly true! I suppose I assumed that a document working all of this up already existed somewhere and someone would simply pop up a link and be done. I wasn’t thinking someone would write a book to answer me, nor would I honestly want them to. I’m sorry if I’m making a pest of myself.
Anyway, I appreciate the three of you responding. I’m not trying to rope anyone into my project, I just don’t know how or where to start. I guess I’ll plow into the link @Dannii shared and hope I come out of the other end with a bit more clarity.
Thanks,
-Pinkunz
1 Like
Here is my layperson understanding of the various things that are colloquially referred to as interpreters:
-
Interpreter “Engines”: Some things that people call interpreters are like an engine. If you want to play a game, an engine is a key component, but by itself, it is not going to get you where you want to go. Analogy: If you want to drive somewhere, you can’t just buy a car engine. You need to put it into a car first. An example of an interpreter “engine” would be Glulxe.
-
Interpreter “Single-engine apps”: Some things that people call an interpreter are like a car. It includes the engine AND the controls that allow the user to operate it (the steering wheel, pedals, etc.) An example of a “Single-engine app” would be Windows Glulxe.
-
Interpreter “Multi-engine apps”: Some things that people call interpreters are like a car that has several different engines built into it, and you can switch back and forth between which engine you want to use. Example: Lectrote.
The names I have listed for these categories are not official. I’m just trying to distinguish between them. There is disagreement about what they should be called, and whether all of the things in all of these categories can even be considered interpreters. Also, it’s possible I’ve got something wrong.
“Version control” is something that I’m not sure why it’s on your list, but basically (again, layperson definition) it’s software that you can use to keep track of changes that you make to your files over time. It’s helpful when you are working on a project, and you want to be able to go back and see what your project looked like several drafts ago, without saving each individual draft as a separate file.
4 Likes
Thank you for taking the time to rough that out. That makes much more sense now (It also helps shed some light on @Jonathan 's bag of balls analogy). As for the mixed list of terms, I started with the interpreters and then realized there were a bunch of terms being used throughout the conversation that I didn’t know the definition of nor did I know if they were IF specific (As in: I googled ‘IO System’ after Dannii last replied), so I said screw it and threw them all in. In hindsight, probably a bad impulse I shouldn’t have caved to. If I understand what you said regarding Version Control, would the edit history of individual posts on this forum be considered a rudimentary form of version control? Finally, it didn’t occur to me that there would be disagreement about this. I sort of assumed much of this type of software had been around for decades, so surely the naming conventions had been settled, right? I need to either start assuming less or state my assumptions up front so they can be dispelled if I’m wrong. Thanks again for the explanation.
Glulx and the Z-Machine are both the names of “virtual machines” – fake computers that are simulated on other computers. An interpreter is what does that simulation. It could be described as interpreting the glulx code or z-code or as emulating a virtual machine running a particular program; we use the “interpret” description.
The Z-Machine has its I/O (input/output) options baked in, part of its specification. Glulx was designed to isolate the application logic (processing user input, changing the world state, deciding what the output should be from the I/O details (actually receiving the user input and actually displaying it). Glk is what takes care of the I/O details.
The Glk specification defines the Glk API (application program interface) – the functions you have to write and what their arguments are if you want to create a particular Glk implementation, which is sometimes used interchangeably with “Glk library”, though “implementation” more connotes the “how” – what choices did you make that shaped how you wrote this, and “library” more connotes the “what” – what file is the representation of this implementation that will become a part of a larger project.
“User interface” is a vague term referring to how people interact with computers, including what devices are in use. Older interfaces were dominated by keyboard input and text output. Modern interfaces are dominated by pointers (mouse/trackball/trackpad) and windows and icons.
But “Glk interface” as used above means some particular Glk library.
There are two kinds of Inform templates: website templates and interpreter templates (though ultimately the same template can be both at once but no one does that and it’s a detail I probably shouldn’t have brought up because it just confuses things). Website templates produce some web pages about your program, including the source text. There are two included with I7, “Standard” and “Classic”. I’ve seen one other in the wild, Iridium. They’re pretty easy for a web developer to make and I’m surprised there aren’t more.
There are three interpreter templates, Quixe, Parchment, and Vorple, though these things have a lot of differences from each other.
Outside of the context of the I7 template, when we say “Quixe”, we mean Quixe, a glulx interpreter in javascript. The Quixe template includes Quixe the interpreter, plus Glkote, a Glk library in javascript, plus a couple of other javascript libraries and some HTML and CSS. When you release along with a "Quixe" interpreter you get a website built with the Standard website template that includes a page in which you can play the game in your browser. You can only use the Quixe template with games compiled for glulx.
The Parchment template includes Quixe the interpreter, plus ifvms, a z-code interpreter in javascript, and Glkote (but a different version than in the Quixe template), plus some javascript to make the decision on whether it should use Quixe or ifvms. You can use this for z-code or Glulx.
Vorple colors outside the lines. Vorple collectively refers to both a collection of extensions and the I7 Vorple template. Vorple games can only be played in the browser (well, a browser-like environment – one could build an Electron app to run a Vorple game). And then Vorple lets you write I7 that embeds stuff in its output that doesn’t get displayed directly to the user, but gets intercepted and interpreted by javascript in the Vorple template that can call other javascript functions you might have written, and now basically anything you can do with javascript/HTML/CSS is open to you.
3 Likes