We want the IF community to help keep this database current! Here’s how you can help:
Add or update the infobox information on existing pages. Go to the page of an interpreter or authoring system, click on the Actions menu, and choose “Edit with form.”
Add new software pages. If there’s an interpreter or IF authoring system that doesn’t have a page yet on IFWiki, you can add it by going to the software form page and typing in the name of the software. That will take you to a form where you can fill out the information.
Spread the word! We can always use more help! (And no, there’s no rule against updating the information about your own authoring system or interpreter. We encourage it!)
Many thanks to @Jonathan and the IFWiki team for organizing and implementing these improvements!
Now that the infobox content on software pages is saved to a database, we have been able to add a new feature to the Main Page – an automatically generated list of recently updated software.
It is hoped that this will encourage software developers and others to keep the relevant software pages up to date!
The text will change over time, but currently this is what we have:
The TADS - IFWiki page lists it as both an interpreter and authoring system, and for formats the following boxes have been ticked: Browser, Windows, Mac, Linux, iOS, Android.
I’ve never used TADS but see from TADS Overview: Web Play that the authoring system can be download for Windows, Mac and Linux, and from TADS Overview: Web Play that games can be made for playing in a browser (with no need for the player to download an interpreter).
I don’t know why Android and iOS were ticked. Maybe because the browser games can be played on Android and iOS devices. Anyway, I’ve unticked them for now. I have left “Browser” there but maybe it should go too.
Frotz (iOS) and Fabularium (Android) are able to play TADS games, and Fabularium also bundles the T3 compiler. I guess there is some confusion on what the “Platforms” of an authoring system should be. (Compiler available vs. Interpreters available, and official support from the author vs. third-party 'terps like Fabularium).
Edit: Also, Parchment/Emglken now runs TADS games in the browser, so that’s probably why that’s checked. Perhaps it would be preferable to have separate articles for TADS as an authoring system, and MJR’s official interpreter.
I think you’re right. I’ve added an explanation to the data entry form:
For authoring systems, please only include systems on which the authoring system can run. For example, TADS games can run on the Android app Fabularium but please don’t include “Android” as a system on the TADS page.
No doubt the wording can be improved.
If there were possible it would be great. Maybe the existing page could be for the authoring system and you could create a new page like “TADS (official interpreter)”, or whatever it’s called, for the interpreter. There are quite a few TADS-related pages already.
I am browsing my history web pages and I can’t find it right now but I am sure that at some point there is a mention as Tads interpreter for Android hosted in Tads page. I have early visited that page for a couple times.
I’m trying to get my head around the way the wiki is set up.
Is there any way of automatically populating a game author or software publisher’s entry as new games are added?
At the moment it seems like you have to duplicate everything manually across the author’s page, the publisher’s page and then onto pages like “Works released in…”.
Are there any “good practise” entries/pages, for each of the page types, that you would point new editors towards; that highlight how you want things to be set out going forward?
I’m mostly a lurker and player of IF, not a developer, but one thing has always confused me, and this new wiki database doesn’t help to clear it up.
There seem to be two different kinds of interpreters, back-end and front-end interpreters (for lack of better terms). Front-end interpreters like Gargoyle, Lectrote and Parchment run back-end interpreters like Glulxe and a bunch of others. But some of these back-end interpreters might also be able to run as front-end interpreters?
I realize it might be too late to coin a new term for one of the types of interpreters, and I also see that the database tries to classify them with the “uses” and “used by” metadata, as well as sometimes a “note” saying if a certain interpreter cannot be run standalone, but this kind of metadata isn’t very easy to sort by or collate.
Not sure if this is criticism of the database or just a way for me to show my confusion, but it’s something I’ve been wondering for a while. I’m sure there’s some Zarf documentation I can read to clear it all up though!
Well, there are a bunch of interpreters. Traditionally, this was what everyone used. An interpreter can typically play one type of game (Z-code OR Glulx OR Tads etc) and is available for one or more platforms (Windows, Mac etc).
Then came the multi-format-interpreters - One interpreter that can play several game formats.
Then came another way of building multi-format interpreters. Rather than writing a new interpreter or extending an existing one, someone wrote a new frontend and connected several different existing interpreters to the same frontend. This is Gargoyle, Parchment et al. As far as I know, they all rely on interpreters which were already available as stand-alone interpreters.
You will laugh when you realise how much we discussed this before settling on the structure we have now! At some point that discussion could form the basis of a good wiki article to clarify everything.
Initially I didn’t think of Gargoyle etc as interpreters at all but as things that use interpreters. Until I thought that if I bought a few bags of balls and sold them in a bigger bag, I’d still be selling a bag of balls It’s not the perfect analogy but it helped me… and everybody uses the word “interpreter” liberally so we couldn’t unilaterally change that anyway.
Right, this makes sense and is basically what I thought, although I assume(d) that once these kinds of interpreters started appearing, people started writing back-end interpreters that don’t have a front-end, creating a new, fourth (?) type of interpreter that’s basically just a library that needs to be included in some sort of front-end in order to be useful.
Anyway, thanks for the explanation! In an attempt to stay on topic: What I was also trying to get at (besides understanding it personally) was that it’d be nice if the IFWiki database allowed me to filter by this information! Perhaps I want to write a front-end interpreter and want to find out what Z-Code (or whatever) interpreters I can use as back-ends? I suppose I can look at the other most popular interpreters in the database and identify their back-ends by the “uses” table row, go through that list to find the Z-Code one, and see if that one has a “note” column that says that it can’t be downloaded and used stand-alone, and assume that means it can be used as a library in my front-end.
Just an example I made up now, but maybe it shows why it’d be useful to have different classifications for these types of interpreters.
Yes please!
Good to know it’s not just newbies like me who get confused! And yeah, like I also said I guess it’s too late to make up a new term now. Oh well!
Something else:
I thought of another type of metadata that’d be interesting for me personally: Whether an interpreter is graphical or runs in a terminal. I guess it’s not too important since few modern interpreters run in a terminal nowadays, and that I can pick them out by looking at what multimedia they support (which is listed).
I tried to find Frotz, which is a terminal interpreter I’ve used in the past, but it doesn’t seem to be included in the interpreter database even though it has a page on IFWiki: Frotz - IFWiki – I’m not sure if that’s because it’s not actually an interpreter (per the discussion over), if nobody has added the metadata to its page yet, or something else. I see that Windows Frotz and Frotz for iOS are there though. Based on Frotz’s IFWiki page it seems it has been split into a front-end and a back-end, so perhaps frotz the Linux terminal program is a front-end known as “Linux Frotz” or something.
When someone fills out the form for a software page (by going to the actions menu and choosing “edit with form”), the page will get an infobox, and the data will automatically be added to the database. I think it’s just that no one has done that yet for the Frotz page.
Yeah, there are about a bazillion different programs called “Frotz” (or some variation thereof), that are all to some extent derived from the original Frotz interpreter written by Stefan Jokisch in the 90s. You’re probably thinking of the Curses version (aka “Unix Frotz”), or “Dumb Frotz” for the version that doesn’t even produce a status bar. Many of those don’t have their own entries in the database yet.
It’s not the perfect analogy but it helped me… and everybody uses the word “interpreter” liberally so we couldn’t unilaterally change that anyway.