Zarf Updates

This was a big week for IF events -- Spring Thing ended and ShuffleComp voting started. There were unexpected wrinkles in both of them, but I want to discuss the less dramatic one.

ShuffleComp is a music-themed game-jam-like event. I won't do the whole spiel; basically you get a song list and you're supposed to write a short game inspired by one of the songs. I didn't enter, but Jmac did, and he got all electrified about the idea of using Seltani. (Which is... do you read this blog? It's my multiplayer text Myst MUD project from last year.)

So Jmac implemented his idea, and that was great until he re-read the rules and saw:

The only restriction on platforms is that the game you submit must be playable as-is, not reliant on being hosted on a specific server or website. (This doesn't forbid hosting elsewhere - but if your game breaks if hosted on the IF Archive or played offline, that's a problem.)

Our topic for today is: why is the IF Archive, and how does that role change as IF changes?

(Spoiler: I do not have tidy answers. Best I can do is pare the questions into neat slices.)

(Footnote: The ShuffleComp organizer wound up disqualifying Jmac's game, with apologies all round and no ill will. Jmac has posted his game link on his own web site. You should jump into Seltani and try it.)

---

That ShuffleComp rule implies (and supports) a particular view of how games are to be managed. People write games; the organizer collects them; the organizer posts them as a big zip file; players download them and play them; the Archive saves them forever. There may be additional affordances for online play, but the big zip file is fundamental.

This set of assumptions is neither universal nor arbitrary. Various events and competitions in the IF world have different rules and models. But they generally represent the general consensus agreements of the IF community, which include "long-term archiving is good" and "players should be able to save playable copies of games".

...Except of course "the IF community" covers a lot more ground than it used to. The IF Archive accepts Twine games, but the Twine community has no general consensus that all their games should be uploaded to the Archive. (Some authors do, the majority don't.) There are hosting sites for Twine games (e.g. philome.la) but I don't know if they are operated with the same assumptions of long-term archiving.

These are technical issues as well as cultural issues. Or, I should say, cultural issues define technical issues. IF games in my world can nearly always be distributed as simple files -- one game, one file. Why? Because I wanted a way for people to upload IF games with graphics to the IF Archive! A single-file format fit the way we did things in the 90s, so I wrote up the Blorb spec. That let us keep doing things that way. But Twine came out of a different community.

(Okay, Twine came from Chris Klimas who was also in our community in the 90s. Nonetheless -- different goals, different needs.)

Obviously, Seltani also breaks the one-downloadable-file assumption. Let's not get into the question of whether Jmac's game needed to be built in Seltani. Assume that in the future, more IF will come along that undermines our archiving assumptions. We can imagine many possible reasons:

• Inherently multiplayer games
• Games that draw on real-time Internet data (Twitter, current news headlines, etc)
• ARG-style games that are hosted on social media services for reasons of authenticity
• "Living" games, where only one "live" copy exists and is passed from player to player
• Games built in proprietary web services
• Commercial games, where the author does not want free copies distributed
• Games that run afoul of parochial laws
• ...?

These are not hypotheticals in the IF world. Consider Blueful, Winterstrike, Naked Shades, the whole Versu story, etc.

The question is, how do we support our desire to save stuff without stifling or rejecting IF in these categories?

---

Archiving covers many needs, so let's split that up as well.

• Long-term preservation: you want to play a game years after the original web site has vanished.
• Short-term offline use: you want to download a game and play it without direct Internet access.
• Medium-term reference: you are writing a web page about IF games (i.e. your games, or a specific competition) and you want to link to the games without hosting your own copies.
• Discoverability: having all games on the same web site makes it easier to find things.
• Academic study: you want to learn how a game was constructed.

We should note that the IF community (and IF Archive) are not equally interested in all of these things. The Archive is famously terrible for search -- or it was, until IFDB came along. (And IFDB can index games anywhere, so it does not directly boost the "all games on the same server" goal.)

Also, while we're fans of archiving games, there's no broad agreement to archive source code. Future academics may be more interested in source files than in game files, but most game authors don't upload it. (I have posted source for some of my games, but on my web site rather than the Archive.)

(Ironically, Twine is more accessible in this way, because Twine games are constructed in Javascript. They always contain their own source.)

Here, too, culture influences goals. And vice versa. It's not a stretch to say that the IF community-as-we-know-it is the Archive; we're the people who have this shared history. But also: by clinging to this shared history, we are conservative. (In all senses.) We are biased against completely new solutions, because they don't fit our models.

So we come back to the topic: how do we proceed?

The immediate answer is, as usual, save something. Save some files. Seltani has an export facility, so you can get the "source code" of your Age. It's not playable (since I never got around to an import facility) but it may make an academic happy someday.

Besides, I will write that import facility someday. Then it will be easier to try out Seltani worlds offline. Not easy, because the software is a hassle to set up -- but if my server dies someday, somebody else could reinstate some part of it.

This demonstrates the next answer, which is that if you're designing an IF system... think about this stuff. There are no requirements, but there are questions. Does it make sense to export source? Does it make sense to build a single-file package of a game? Can you document your format? (You've already thought about whether you can be open-source; that question hovers around every software design project.)

I will say, from the perspective of having done this for twenty years -- the history is important. I can talk about the games I wrote in 1995 and people can play them. Twine was invented five years ago and didn't start to boom for a couple of years after that. In 2030, the early history of Twine will be important! People will want to know what was going down! That history is part of what you are building today; don't neglect it.

Okay end of lecture.

I expect that IF events will continue to say either "must be archivable" (like ShuffleComp) or "is your game archivable?" (like IFComp). All the reasons above apply. Maybe we'll even make more of a swing towards releasing game source code.

I encourage people to chime in on this. Which of the above goals of archiving are important to you? Or did I miss some? What games have come out that slid past the IF community because they didn't fit our way of thinking?

---

(See also previous post: Everything I know about digital preservation.)