If I’m creating an IF title that plays in a webpage (not using Twine or Quest), is there a specific way I should embed the IFID string…? Do any IF tools/services have a way of reading an IFID from a Twine game, for example?
Just wanna make sure I’m following standards.
Thanks!
The Treaty of Babel suggests: a meta tag, e.g. <meta property="ifiction:ifid" content="448E73DF-2D2F-47E7-A494-A46B40D4CFB3">
(Note also the advice at that link about adding RDFa stuff, to keep other HTML validators happy.)
I tested the <meta> tag method (per Josh) with some non-interactive hand-written HTML and the version of the babel tool I have lying around (which I know works for Twine). It works:
<html>
<head>
<title>Stoats</title>
<meta property="ifiction:ifid" content="448E73DF-2D2F-47E7-A494-A46B40D4CFB3">
</head>
<body>
<p>Weasels</p>
</body>
</html>
Result:
$ ~/src/babel-tool-git/babel -ifid test.html
IFID: 448E73DF-2D2F-47E7-A494-A46B40D4CFB3
Note that Twine works often do something different (embedding it in a <tw-storydata> tag), but Twine has special permission in the Treaty to do that.
(This section also suggests another method you can use if you can’t add the <meta> tag, but hopefully you can.)
Awesome!! 
Thank you so much!
The <meta> tag is perfect! Thank you both for the info!
I have a question about this Babel malarkey;
The “treaty” talks about reading a “story file” or a “wrapped” story file in order to extract meta-data.
Modern works will consist of multiple files not wrapped in a container, such as a “story file” together with several media files and perhaps others.
For example a web game will not be able to run from inside a wrapper and it will need media in separate file so as to fetch them from the server on demand.
Is the system module allowed to examine the story file in order to then access other files to gather the data (eg for the cover art)? It would mean allowing file IO in the tool.
I see that the Twine module is unable to retrieve any covert art, which makes it rather lame.
It was rather the other way around when Babel was designed. An Infocom V6 game might have been stored as a bunch of Z-code, image, and font files in the 1990s. The new idea was packaging everything up in a blorb file.
Babel was intended to support the needs of the IF Archive, which was (and is) built on the idea that a game is a file with a URL. If you’re hosting a playable game on your web site, it probably won’t be a single file, but that’s not really the babel tool’s use case.
What we should think about, maybe, is the question of running the babel tool on a zip file.
That would definitely be a step forward.
The “story file” therein or perhaps another meta file could specify other assets that are assumed to reside in the same zip. for example the cover art and trailer video.
The method I’m using packages game assets in a wasm state, and then that wasm state is packaged in the html file in base64. This seems to sidestep the issues of slow loading times when packaging everything as individual base64 strings.
So while the game is a single html story file in my case, I’ll probably need to figure out how to let babel tools retrieve embedded cover art and other metadata.