Zarf Updates

(This has been widely noted, but I wanted to summarize what's known.)

At the beginning of September, some Dropbox users got email:

We’re writing to let you know that we’ll be discontinuing the ability to render HTML content in-browser via shared links or Public Folder. If you're using Dropbox shared links to host HTML files for a website, the content will no longer display in-browser.

(Text copied from a post on the ChoiceOfGames forum -- thanks jeantown.)

Dropbox has posted a more complete summary on their web site:

Dropbox Basic (free) users: Beginning October 3, 2016, you can no longer use shared links to render HTML content in a web browser. If you created a website that directly displays HTML content from your Dropbox, it will no longer render in the browser. The HTML content itself will still remain in your Dropbox and can be shared.

Dropbox Pro and Business users: Beginning September 1, 2017, you can no longer render HTML content.

In other words, in a month (for free users) or twelve months (for paid users), people will no longer be able to play your HTML-based games directly off of Dropbox. They'll either appear as raw HTML or as "download this file" links -- it's not clear which. (Other kinds of files, such as images or CSS files, will not be affected.)


Why are they doing this? I haven't seen a public explanation, but I assume it's because jerks are using Dropbox to anonymously host Javascript malware. Google Drive has announced a similar change.

Okay, you may ask, but does anybody publicize games this way? The ChoiceOfGames forum thread implies that the answer is yes. See also this thread and this thread.

In fact I've done this myself. When I first posted Bigger Than You Think as part of Yuletide 2012, I hosted it on Dropbox for the first seven days. Yuletide has a seven-day anonymity period, and Dropbox was an obvious short-term solution.

I know of games which only exist as Dropbox URLs, notably the creepy-comic Twine game Mastaba Snoopy. It was widely discussed in early 2013, but the only known source was this Dropbox URL. (Which currently redirects to this equivalent URL.) So that's a wee bit of history which will stop working in a month, or maybe twelve months.

To be sure, Mastaba Snoopy will not vanish. You will be able to download it as HTML (from the old URL) and play it locally. It will work fine that way. (In fact, it may work better. I've seen the Dropbox version mess up the game's Unicode something fierce.)

However, that only works because the game is a single self-contained HTML file. An HTML game with included images, sounds, JS/CSS files, or other resources would be harder to fetch. (BTYT included several JS/CSS files.) You'd have to download the HTML, ferret out all the relative URLs, and then download those too. This is always possible (unless the author has really worked to obfuscate the code!) but it may not be trivial.

---

Conclusions:

If you are the author of a Twine game (or other web-based game) on Dropbox, and you have abandoned it, then you're not reading this post. Drat!

(If you're reading this and you care about the future playability of your game, I count that as "not abandoned".)

Your game is not under threat of disappearance, but most casual players will think it is broken. Preservation-minded fans may pick it up and make copies -- probably without your permission, since you're not reading this post. Sorry! Deliberate non-archivability of games is an interesting subject, but chances are high that somebody will download a copy for posterity. I have downloaded a copy of Mastaba Snoopy for my own files.

If you are the author of such a game and you want to keep it easily playable, you have various options for reposting it:

• Itch.IO: Free. HTML games work fine, although they appear in an iframe. Probably you could launch the frame as a separate window if you tried.
  
• Github Pages: If you have a Github account, you can post HTML pages at username.github.io. This is a better fit for open-source projects, although the Pages repository is not required to be public.
  
• Philome.la: Free but you need a Twitter account. Intended for Twine games. I believe you can only upload a single HTML file, but I bet you could rig up a scheme where the HTML is on Philome.la and the resource files (images, JS, CSS) are on Dropbox. Let me know if you make that work.
  

I've seen people suggest the IF Archive, but this is not a great solution. Speaking with my Archive hat on, we prefer that HTML-based games be uploaded as archives (.zip files). We don't want to be a front-line resource for playing IF; we're just not set up for that.

(We're not enforcing this as a hard-and-fast rule. In particular the IF Competition folders on the Archive contain a lot of playable games. Sorry; a 25-year history makes for a lot of exceptions.)

(It would be interesting if iplayif.com or a similar site gained the ability to download a Twine .zip package off the Archive, unpack and cache it, and offer it as a playable game. Eh? Eh?)

---

I have a long-held view -- admittedly biased by my long history with the IF Archive -- that IF preservation is deeply tied to the notion of a single-file release format for games. Of course this goes back to the days when you put your .z5 or .gam file up on ftp.gmd.de and that was it; that's what people downloaded.

Years later, we caught on to the idea of making browser-playable IF. That left us in a weird state where authors were expected to release games twice, on a web page (a bunch of files) and on the Archive (a single file). The iplayif.com service helped stitch that divide back together -- you could just upload to the Archive and get browser-playability for free. (Although without stylistic customizability.)

But then Twine turned up, and life got messy again, because the Twine model only envisioned browser playability. Which was clearly sensible; downloading a file in a funny obscure format is obviously the wrong choice. Unless you think about archiving and preservation! Then having a file at a URL makes life so much easier.

And so we wind up back at this blog post. I have no concrete suggestions beyond the unpack-and-cache service I mentioned above. Which, yes, has its own security implications. (The same ones Dropbox faced in the first place.)