[I6] Adding / embedding IFID into IF for IFComp?

I am preparing an I6 parser IF for IF Comp. Where in the source code should I add and or embed the IFID? And, how should I indicate the IFID on IFDB after the competition?

Thank you,

My Inform 6 is pretty much nil. However, the Inform 7 documentation explicitly says (in section 25.15 of Writing with Inform) that Inform 6 does not include any such facilities.

There are at least two workarounds that I can think of. One is that Inform 7 can be used to “wrap” an Inform 6 project and provide bibliographic data and cover art for the existing I6 project, and it doesn’t look like an arduous task, nor one that requires much general Inform 7 knowledge. The process of adding bibliographic information is covered throughout chapter 25 of Writing with Inform.

Alternately, there’s no reason why you couldn’t just handcode an appropriate iFicition.xml document describing metadata, including an IFID. The Treaty of Babel has all of the information needed if you want to go that route, and the relevant info is mostly concentrated in section 2.2.2 there.

1 Like

You should be able to just add it anywhere in the source, like this:

! Adventure's IFID -- see http://babel.ifarchive.org/
Array UUID_ARRAY string "UUID://E9FD3D87-DD2F-4005-B332-23557780B64E//"; 
#Ifdef UUID_ARRAY; #Endif;

(This particular IFID is for Adventure, don’t use that!)


I generated a new IFID for the story manually.

At this point, I am just adding it as a comment to the source code and have it display in the intro until I can figure something else that works better.

I only expect to compile to a z8 file to play with frotz or gargoyle.

Thank you, Jeff

1 Like

You’re just supposed to add it as an array like above - this will cause these characters to appear as an ASCII string in the story file - and an application which wants to know the IFID is supposed to scan through the byte-adressable part of the story file (the first 64 KB) looking for an ID like this. That’s the correct way of adding an IFID to a Z-code file. Good luck!

1 Like

Except the I6 compiler generates and error when I add the array code as above.

What was the error?

Did you copy the curly quotes in the code fredrik posted? They should be ASCII quotes, that’s the forum software being too smart.

Array UUID_ARRAY string "UUID://0D35EAE4-EF8B-44B3-81CF-8CC2366B6F88//";

Thank you Zarf and everyone,

All good!


Does this technique apply for a Glulx game as well?

Yes, Zarf’s code should work perfectly in Glulx too.

I thought it might matter where in the file the UUID appears, that you only needed to check the first X kilobytes, but I just checked the Babel spec and it seems to say that it can be anywhere.


With the latest version of I6, you can also declare the array static to put it in ROM instead of RAM. (But this very seldom actually matters; it’s mostly relevant for games targetting retro machines where RAM is precious.)


Under what circumstances do I need to generate a new IFID? Specifically:

  • If I release versions of the same game that run on different platforms (Z-code, Glulx, Adventuron), do I need to generate a unique IFID for each platform?
  • If I release a new version of the same game on the same platform, do I need to generate a new IFID?

I think the criterion or heuristic is basically whether you’d want the new version to replace the old version in archives and in the context of automatic processing by metadata tools (like retrieval of cover art & associated files, cataloguing, interpreter choice etc.).

So, for different platforms, I’d say you should generate a new IFID for each, because players will need a different interpreter, and archives will want to keep all the versions.

On the same platform, if it’s a bugfix release that’s intended to replace the previous version, you should keep the same IFID.

Here’s what the Treaty of Babel has to say on the subject (section 2.2):

As with published books, where an ISBN remains the same even if the book is reprinted with corrections, the IFID should be associated with a project, not a specific story file compiled from it. A re-release with bug fixes should have the same IFID.

If a game is ported from one system to another (other than simply being moved from one version of a system to the next, e.g., by being moved from TADS 2 to TADS 3), the port receives a new IFID. Again, this is analogous to books: a different-format reissue of a book, such as a paperback of what was previously hardback, gets a new ISBN.

1 Like

Thank you. That’s exactly what I needed to know. I’ve been wading through the Treaty of Babel. It’s hard to read and understand. I also found what I needed to know about cover art requirements and am trying to fathom the stuff on meta data.

It never ceases to amaze me that the whole world of interactive fiction is oriented around text, yet all the specifications and user documentation is written in gobbledegook. Haven’t they heard of “plain English”?

Specifications and standardese are always gobbledegook. It’s a side effect of trying to use precise language to nail things down, which ends up both using phrasing and style that our brains aren’t used to dealing with on a regular basis (because natural language is incredibly imprecise most of the time). Part of that is also often being written as concisely as possible, which again can cause mental disconnects since we’re usually wired to seek justifications for things, which are usually absent or insufficiently elaborated. So it takes a bit of gearshifting to get used to it.

Specifications have to be brain-meltingly precise so that when a bug turns up, everyone knows which piece of code to fix. Ideally there should also be plain-language documentation.

It’s important to note that the IFID is not (yet?) used this way. The IF Archive and IFDB each have their own ID system. As any librarian will tell you, two different ID systems can never be made to match up, and here we have three of them.

This becomes obvious when you look at https://ifdb.tads.org/viewgame?id=fft6pu91j85y4acv , the IFDB page for Adventure, which lists 19 IFIDs and dozens of IF Archive entries.

I would say that the Babel quote above is a good guiding principle, but nothing and nobody is in charge of applying it consistently, so it hasn’t been. (Whereas the Archive and IFDB both have human volunteers going over them with an eye to keeping the organization consistent.)

I’d assume that the intention of IFID is to act similarly to an ISBN number (or a serial number or barcode), identifying a specific work in cases where others may have a similar or identical name. You could give multiple “editions” a new IFID, such as if they are platform specific - the same as how ISBNs differentiate between paperback and hardcover editions of books, for example.

I don’t believe you’d change an IFID for normal updates - for that you probably want to increment a version number because it’s the same game. If you make a significant new re-release, such as a post-Comp version with additional content, or if you have a “graphical edition” that might warrant a new IFID to differentiate between the versions with and without the new content.

Most likely, a game should keep an original IFID - unless it’s something like Adventure which does have specified multiple different versions which people may want to identify.

I think the world needs another Adventure port. There aren’t enough out there.

1 Like