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.)
Obvious ironies that I didn't want to include in the main post:
- Inform 7 is not open source. I know. I think it should be. I send Graham email every five years to remind him of this. (Don't want to nag.)
- The IF Archive has been sort of broken recently. (In particular the mirrors are all way behind, because we've screwed up the rsync daemon.) This will be worked on.
The reason I threw this rule in was mostly experimental. ShuffleComp is mostly made up of experiments. (That was also a big part of why we agreed to exclude Barbetween: experiments aren't of much value if you throw out the results you don't like.)
Immediately, the answer to 'what happens if we...' is: people will get excited about an idea for an archive-unfriendly platform, forget the rule (because some people will always forget some rules) and get kicked out. Which is no fun. I wouldn't want a rule like this in IF Comp. (The occasional minicomp with this rule, though, would at least keep people thinking about it.)
It's worth mentioning that this isn't just a matter of platform: I've encountered a number of conventional, single-file parser games, listed on IFDB but only ever hosted on the author's now-defunct site.
Available source code is awfully nice - forget data archaeology, it's a massive help for crit writing now, because I don't want to have to replay an entire game just to pull a quote or check that I'm correct about how something works. I think there can be reasons for authors not doing this that are pretty good, but I think there are a good number that tend to be bullshit. ('It'll ruin the fun!' is, 90% of the time, bullshit.)
I used to think that keeping the source code private was important to not spoil the fun. But now I don't know why I used to think that.
For a comp game I'd release it as part of a post-comp release, though.
I guess this means I should spend some time packaging and uploading source for all of my old games.
I'm ashamed to say I never even considered the helpfulness of source code to reviewers. I just assumed that the only reason to share source was to share coding tricks, and since I am such a suck programmer, this would just never even come up.
Indeed, I recently needed to look something up in Photopia, and because the source isn't available I had to decompile the game (sorry, Mr. Cadre). Here's what I wrote about it:
But being able to do it at all was better than nothing. And having the source code would have been easier than trying to locate a decompiler that's both still available AND working, building it from source code and so on. What if I had failed in my search?
IF games in my world can nearly always be distributed as simple files -- one game, one file.
This is a great assumption for "modern" (Inform / Tads / Hugo) hobbyist-developed stuff, but for commercial titles and earlier homebrew efforts (typically one-off wheel-reinventions) of course that expectation is way out of line. (Granted, the first 20 years of text adventures have, by and large, completely faded into well-deserved obscurity. We've done our bit to document them and move on.)
ARG-style games that are hosted on social media services for reasons of authenticity
I know that I felt burned for living in the wrong blasted part of Canada when I heard that occasional IF author Jim Munroe had written a real-life ARG for the enjoyment of the citizens of Toronto and wished that there was some way of documenting it in a remotely-enjoyable form.
...?
My poor colleagues at MobyGames were unimpressed with my efforts to document Best Before over there, though it was undeniably a computer game. Our newfound acknowledgement of IF's fellow travellers in the realms of gamebooks and hyperfiction puts a lot of well-thumbed children's paperbacks (and pricey experiments in the Eastgate Systems vaults) under our purview. (Then there are things like my musical CYOA or these lovely weirdos who posted CYOA pages in public locations where basically the best we can hope for is that the project is well-documented. With sufficient documentation, any element of gameplay experience can be at least simulated down the line barring perhaps randomness and game logic... but for CYOAs these elements aren't usually in play 8)
When you talk about source code I think about all the early BASIC text adventures where the game was the source code, but of course despite the plain English pseudocode readability of Inform 7 those days are far behind us now.
I think "oh, there are precedents, if enough people are interested in something they will reverse-engineer it" like was done with the Z-machine and as the somewhat paranoid DEC engineer did with Zork. But of course these were mass cultural phenomena whose lightning is unlikely to strike again twice and furthermore I imagine that the IF community having done the heavy lifting of engine emulation once (well, twice, three times... for Scott Adams, Magnetic Fields, Level 9 ... OK, then we really hit the point of diminishing returns), they're not in a hurry to have to do it again in the future. I get that we are not SCUMMVM nor do we aspire to be.
Sorry, scattered 2-cents thinking. Here's a penny here and another one over there.