I have enjoyed playing IF for decades, and would like to be able to play more often. Unfortunately my opportunities are infrequent, and when time does allow, I rarely find myself in front of the same machine where I last saved my progress. I must have started Anchorhead at least four times over the last decade or so, and have a comprehensive collection of non-interoperable save files.
My question is this: Is there any prospect for a cross platform interpreter (Windows, Mac, Linux, and ideally with a web play option like Parchment), that can save and retrieve game states and transcripts to/from an online storage set up by the user (perhaps sftp or something like Google Drive or Dropbox)?
My dream is to be able to sit in front of whatever machine I have to hand - one day it will be my work machine (a WIndows laptop), the next day my home Linux box, then on my mobile on the train - and simply resume play from wherever I got to on whatever machine.
I have tried various ways of syncing local storage to get Parchment working this way, but without any luck.
A related question would be, is there any prospect of a universal, interoprable save format that would allow game saves (state) to be passed between different interpreters? Or do the different feature sets and implementations of the various interpreters make such a thing unachievable?
Thereās sometimes a problem with filenames being recognized (interpreters can disagree on what the filename suffix is supposed to be). And getting save data into and out of a web interpreterās browser-storage is a headache. But the save files, as files, should always work.
Iām not sure whatās going on with your Anchorhead experience.
[deleted already-answered bit about Z-code/Glulx], except to add that I think Quetzalās been pretty much universally used since the last century, so I donāt think any interpreter youāre likely to have used for Anchorhead in the last decade is likely to have produced non-portable save files.
(Is it possible that you have been using different versions of Anchorhead story files? While cross-interpreter saves are a solved problem, cross-story-version saves are very much not.)
I donāt actually know what the situation is with other systems like TADS; I guess Iāve blithely assumed that they have portable savefiles too. Trying it now, a TADS 3 savefile from QTads seems to load into Gargoyle fine, for what thatās worth.
(Per your original question, I donāt know of a system built on this foundation to sync collections of savefiles/transcripts around in a cloudy way.)
I think that a more general format for savefile can be welcome, the main issue (ID not only what data set is (in our case, the VM, its version and story file, but also it byte order and word lenght) I think can be easily solved with a judicious, well-thought header.
if, for example, the first two bytes are z8 or t3 (that is, an ascii letter followed by a number, whose incidentally form a coarse indication of the story file format: if the first 16 bits, loaded as a (short) word, as pair of the bytes reveal the āsexā of the bytes in the savefile (8z vs. z8, I think that isalpha() and isdigit() are present in the standard C library since the days of Kernigan & Ritchie) and so onā¦
in a perfect computing organisation, the ideal is that if one types on the shell:
gargoyle byhut.sav
Gargoyle, or whatever multi-'terp is run, can figure from a standardised header what story file format is, and what story file is, and its release, and load the appropriate 'terp and story file. an userās QoL whose deserve the maximum coordination effort in our small and active codersās community, IMVHO.
personally, my organisation of if/bin directory is one where is no doubt what is ā¦/if/wrk/zcode/Curses/r12/sosostris.sav savefile, and that all I need is cd if/wrk/zcode/Curses/r12; frotz curses-r12.z5 followed by RESTORE sosostris.sav to be in front of a tarot diviner in an unreal but french-looking cityā¦
Thank you all for your kind and informative replies.
I had heard of Quetzal (donāt IF standards have the best names) but had wrongly assumed that some of my save files must have been using some other formats/standardss. On closer inspection not - and I think JTN hit on the reason for my present difficulties: Anchorhead has of course had several updates since my first attempt. It seems obvious now you say it, but of course my - yikes - 20-year-old save files wonāt work on the latest version.
I think my problem will be solved when I find a way of successfully roundtripping a .sav file from Parchment local storage into Gargoyle and back again. It sounds like it should be possible with a bit of effort on my part.
I promise I will pay more attention to versioning in future, and might even tidy up my own IF directory along the lines you suggest, Piergiorgio.
And again, thank you all for taking the time to reply.
For what itās worth, there are two extant versions of Anchorhead. Thereās the 1990s version (.z8, release 5 / serial 990206) and the modern version (Glulx, from itch.io.). Iām actually not sure what the serial number is on the latter; Mike sent me release 2 / serial number 180210 during development but the shipped version might be later. (The screenshot at itch.io says release 1 but I assume thatās out of date!)
Quetzal really contains as much of this as is needed. Thereās a āfingerprintā chunk which includes a piece of the game header. If the interpreter scans the available game files, it can match the quetzal save file against those and find the correct one.
Huh. When I bought the 20th anniversary edition from itch, in 2023, I got a game file identifying itself as āRelease 1 / Serial number 171017ā, as a member with a 2017-12 or 2018-01 timestamp, in archives with ā1.0.0ā in the filename. (Itch described the archives as dated āJan 18, 2018ā.)
Filename suffixes were indeed the cause of my problem. (Interesting that the Quetzal standard doesnāt madate a file suffix.) It appears that Gargoyle outputs ā.savā, and Fabularium looks for ā.glksaveā. A simple sync and rename script solves my problem. Thank you.