This is a pedantic note, and not one with any immediate technical consequences. But it’s been suggested that we add “html” as a valid format in iFiction files, and generally in the Babel document ( babel.ifarchive.org/ ). I figure it’s a good idea.
This would describe games whose primary published form is an HTML file (perhaps with associated Javascript, CSS, etc). That is, games primarily intended to run in a web browser. Twine is the obvious example.
Note that a Parchment/Quixe package includes the original Zcode/Glulx game in its entirety, possibly still in its Blorb wrapper. So it still makes sense to describe those as “zcode” and “glulx” formats, rather than “html”.
In my collection, the “Twine” folder has roughly 2,300 subfolders, each of which is a game.
The “Web” folder, for other web-playable games, plus my “Undum” folder, have just over 600 subfolders. That might average about 300 games or less, as a lot of these games have subfolders with the files necessary to play them.
My point is, maybe Twine is worthy of being a “valid format” all by itself?.. Might be hard to distinguish between it and other HTMLs for Babel purposes, I know…
A Twine .html includes more or less similar info. Project settings and storymap positions aren’t included in the final output because they are author-time only items. Otherwise the entire Twine is interpreted at runtime.
It’s great to have the play system marked. Would it be time to also include a field for dev-system and make the distinction clearer?
I thought about that, but really, the intent is different. There’s no such thing as a “Twine interpreter” and Twine games are always published as HTML; the Twine project is treated as “source code”, available only if the author wants to display it for other authors. Whereas Z-code/Glulx games are almost always published as Z-code/Glulx files, with Parchment as a convenience addition for players.
“Regularly” is a relative term. I’m posting when I’m comfortable and I have something specific and short and definitely non-controversial and helpful to say. My PP persona is more comfortable elsewhere. Thanks for asking.
Tool-output: Tools encourage particular types of output. For example, it’s hard (but theoretically not impossible) to make music using Photoshop. This effect is comes from both the capabilities of the dev-system itself and the communities that form around dev-systems. Players may find a dev-system distinction helps locate IF that interests them.
Significant by usage: The number of dev-systems is diverse (also: anecdote by above). When searching by browsing, dev-system provides another method of splitting results. IF has a large enough corpus that there are unlikely to be many single-item categories.
Usefulness to authors: It’s easier for authors to understand their dev tools if they can find actual examples.
Future history: The book colophon began to include useful information on the production of the book. Colophons might be the only evidence we have then certain printers existed. Dev-system tags may also assist future digital archaeologists identify and debug particular dev-system quirks.
The specification (5.6.7) is vague. The difference in Inform / Infocom usages show a single field used for two different data-types: dev system / dev-org. That’s already a warning sign that the schema is insufficient to express current use.
If is tied so strongly to iTunes-like indexes then its intended usage is for linking related works between albums. In a meta-sense that assumes a way to provide an alternative linking of works that are already strongly collected (by album). As a spatial metaphor: Horizontal linking between members in vertical groups.
There is also an assumption that users can change to suit their preferences. In an authoritative index that is undesirable. There should be a single setting and user’s individual preferences accommodated in other ways.
looks like a field that was sorta-kinda useful then it’s specification became muddied over time.
Thanks for the thoughtful response. A criterion for spec additions is that someone cares enough to talk about it.
I think this would be part of the section – say a tag. This would be optional and the content would be up to the compiler supporter. (“Inform 6” and “Inform 7” are different devtools, but I don’t want to get into the question of whether to include compiler version numbers.)
(Perhaps rather than ? But that’s somewhat vague.)
I will bring the proposal over to the Babel-IF mailing list.
The spec hasn’t changed much. I think it started out muddled.
Makes sense: An optional tag in the section. Perhaps the spec can list suggested examples in order to give tool-creators guidance.
There was a similar discussion in the author’s forum over the review spreadsheet that’s being kept. Platform makes it ambiguous as to the dev-platform or compile-platform, runtime/reader-platform.
devtool seems unambiguous.
authortool seems more bibliographic?
Not sure if this is the right place to bring it up; I just wanted to say somewhere that I tried to integrate ChoiceScript with Babel but couldn’t figure out how to apply it.
A central assumption of Babel is that a game is a file.
ChoiceScript games can be distributed as HTML, but are not usually distributed that way; they’re usually run as apps for iOS, Android, or via executable wrappers on the Chrome Web Store or Steam; the executable wrappers vary by platform. When we do make them available on the web, we typically make only a partial free trial available, requiring users to login and pay to access the full game online.
What’s the MD5 of an iOS app? I don’t even think I have access to that; Apple signs it on their end. Maybe if I jailbreak the phone and poke around in the filesystem? But then who would use/benefit from that?
ChoiceScript doesn’t require an IDE. (There’s an unofficial one, but I think most authors don’t use it.) Most users create their ChoiceScript games in a simple text editor. How would I get users to create an IFID in this environment? Would I ask them to run uuidgen.exe on their machines? And what if they didn’t?
What is the “format” of a commercial multi-platform game release? It ain’t just “HTML,” that’s for sure.
It’s perhaps an old-fashioned assumption, but one shared by the IF Archive (which is itself old-fashioned). The idea that a game is a single file that you can download was somewhat revolutionary in Ye Old Days. For the Archive, it meant that a game wound up with a canonical URL; for players, it meant easy management of an IF library. The intent of Babel was to let an interpreter have library-management features built in. (Zoom was the reference example.)
This means that IFIDs, and the whole Babel notion, is kind of out-of-sync with games that don’t have a single-file representation. Not only is it hard to make an IFID for such a game, but it’s hard to think of a use for it. The canonical use case of Babel is “I have a mysterious file. I want to find out what game is in it, who wrote it, and how to run it.” But these questions don’t arise with an iOS app. Nor with a Twine web site.
(We could talk about standardizing a way to embed Babel info on a web page. But nobody has yet.)
None of this really answers your questions, except to say “Yep! Good questions!”
I believe there’s one key file that eg. AGiliTy will look for, the remainder of the files not being necessary with the interpreter doing the heavy lifting. This is an opinion pulled out of my derriere, however.
The spec says “assume it is in the AGX format”, which sounds like a one-file version. I never looked into AGT myself.
(Oh, once I tried to write a Glk AGT interpreter. But I quickly decided the format was too obtuse. Line breaks hard-coded in the game file, sort of thing.)
Maybe it’s just about spreading some tags on key files to stamp the unique id you have for your game. I mean those files you must have to run this game and not other. And that’s for new games. You just need to ensure that your game’s ID won’t be/wasn’t used on other games. How? You tell me. I saw an ifid generator on the tads site. I also read that the undum system’s author suggested for undum games something like using even some specific combination of your own email to extract a unique code no one could generate if you like…
That could work even for the non-html new choicescript games I guess, provided some tags somewhere for this purpose.
Though you can’t stamp IDs on the already released ones… But if you can assign an IFID to at least one of the wrappers of any of the versions, that’s it, that’ll do the trick of relating all these already-released versions to a unique code that you can save on a IF database somewhere.
