Beyond the IFID/UUID, is there a way to embed other story information?
It’s also entirely fine if I need to generate a *.iFiction file alongside the built game. I was just confused reading the Babel specs about if only the one attribute was able to be embedded or not.
Also I figured it would be handy to support *.iFiction, since my build process has the information for it anyway.
I’m gonna say “not for your use case.”
.iFiction files are only useful when they’re embedded in a file that another tool knows how to read; when you just create an .iFiction file by hand and distribute it alongside other files, no tool I’m aware of will know how to use it or read it.
And, considering that your use case is to distribute IF as an executable script, you’re not going to integrate with any IF interpreter, or with the Babel tool, so, there’s basically nothing left that would use this information.
Instead, consider distributing bibliographic information about your game on IFDB. Anyone who wants to read your bibliographic information in XML can use IFDB’s API to translate its known metadata about a game into iFiction XML, documented here: https://ifdb.org/api/viewgame
For example, here’s the iFiction XML for Counterfeit Monkey. https://ifdb.org/viewgame?id=aearuuxv83plclpl&ifiction
Ah, so the IFID gets embedded—for any automation where that’s useful, even if it’s in the future—and is displayed in the opening credits, and that is how I can ensure an exact match on the IFDB, where I will post the remaining information?
Even that sounds more ambitious than I think is likely.
Think of it this way: APIs and standards (like the iFiction standard) are designed to help you integrate with someone else’s software.
iFiction is designed to integrate with IF interpreters. But, your game doesn’t work with an interpreter, so it doesn’t really make sense to “integrate” with one.
Instead, I suggest you ask questions like:
IFDB answers those questions.
I think you might be trying to answer a question like this:
That’s a valid question when you’re distributing a blorb to players with many other blorbs. But, for a Node.js file, who would do that, and why?
Players can just run your game to find out its title, or read its file name. Then, they can search Google or IFDB to find out more about it. The IFID isn’t required.
What problem are you trying to solve?
Ah, fair point.
Twine games have a method of embedding an IFID to follow a standard, so I assumed there was a larger organizational reason for this, and even if I’m not entirely versed on why this standard exists, it seems to be a major logistical practice of some kind.
My build system exports both an all-in-one HTML game, and also a terminal-based version which runs in Node.js. For the HTML version, I followed Twine’s example, and then didn’t know what to do for Node.js.
“Metadata is a love letter to the future”, runs the saying. You can imagine someone coming across an unlabelled IF collection twenty years from now and saying “Hey, what’s in these files?” IFDB will probably still be around then – but maybe not. Running a JS program to see the title/author info will probably be possible – but maybe not.
I admit this is all speculation. Dan is right that nobody needs this today. But, as a matter of future-proofing, I would say you should (a) embed the IFID in the game source, and (b) generate an .iFiction file alongside the built game. (Easier to find as a separate file than by digging XML out of a JS file.)
This is exactly why the HTML version is being built to run from a single file, why it doesn’t require any https services, why it doesn’t require a web server, and why there’s also a Node.js version built alongside it. I don’t know what the future of technology is going to be, or if something is going to happen to me which would stop me from maintaining stuff, or what is going to happen to these game files after they hit the Internet.
I’d like for each individual file to carry as much context as usefully-possible, and not fail to run if they are separated from other files in the release package.
With that said, it might be worthwhile to add comments in these files which contain this information, because if all else fails and browsers/Node move to a point where these games don’t run, then I’d like for a simple text editor to be able to open these, and a user can quickly find these comments.
Automation might not support it, but it would be a nice final fallback: A message scratched into the front of the code, detailing what the game is, who made it, and what system/version it was designed to run on.
Might also look into adding electron as a build target, too.
I remain curious as to why there is Twine support in the Treaty, then. I’m not saying I doubt the conclusions given here; I’m genuinely confused about what situation came up which pushed the technologies to support IFID embedding in a Twine game.
Well, it would be tacky to leave Twine out.
I’d say that people have spent more time thinking about getting metadata into HTML than any other format around. And there are lots of workflows that involve looking at it. (Link previews in this forum, to reach for an obvious example.) So getting the IFID and ifiction data into HTML was both easy and an easy win.
This is less universally true for executables (including runnable scripts like JS). But, hey, I’m in favor of putting the metadata there anyhow.
Wholeheartedly agreed.
Ah, that makes sense, yeah.
Agreed. I’ll figure something out! 
I’ll probably have one or three solutions, because redundancy is nice.