When I came up with these specs, I was still using MacOS Classic, which did not rely on suffixes for filenames at all. (And Graham Nelson was still using the Acorn, where I think “.” was a directory separator!) And DOS 8.3 limitations were still current, too. So it was important to leave this up to the interpreter.
Today everybody has standardized on dot-suffix for (approximate) file typing. (I hate it, but OSX gave in several years ago, so there we are.) I’d say the best option is for Glk libraries (and therefore interpreters) to agree on common file suffixes for the various uses.
At the moment, of course, we have all sorts of variation – in fact OSX Zoom creates save files as packages, rather than a flat quetzal file. So it’s going to be a bit of a patchwork. But do people agree in principle?
Switching this over is going to have some cost; old data files lying around might stop working, if you upgrade to an interpreter that uses a different file suffix.
A second path, not necessarily exclusive: allow a way to embed data files in the Blorb file. (This idea has come up before, but I’ve never followed it up.) All modern interpreters can read Blorb data.
This would also allow games to work correctly in web interpreters. If you distribute a separate file along with your game file, there’s no convenient way to get that into a web interpreter environment, except for Blorb.
The blorb idea is to allow the game author to store put a read-only data file in the Blorb package.
(I guess you could put a read-only save file there too, although I can’t see what that would accomplish that couldn’t be better served by smart game setup code.)
That definitely sounds like a good idea. I’m not sure however what big difference it would make if you could add files to a blorb package though. Wasn’t the idea of external files that they could later be modified and work with every version of a given game (or exported to another game for that matter)? What advantages would it bring to tie them up? (It would probably be less chaotic for once and the web stuff is obvious too but is there anything else? Seeing as the same could be accomplished without using external files at all, or am I missing something? [Ok, the map import stuff from R&D would probably be an exception but a rare one at best])
Well, you’ve mentioned two possible uses. Since this is an optional feature (authors don’t have to put their external files in the blorb), the fact that there are a few good uses seems like enough…doesn’t it?
Sure thing. You never know when these extra features might get handy after all. It was more of a ‘Worth the effort?’ kind of question but I wouldn’t know how much effort it would require anyway so the question might be mood.
Author distributes a data file which every player will need to load.
Player saves a data file for later use.
The first requires a reliable way to get at the data on every platform, every interpreter. For the second, this is less important (but not negligible) – it’s not usual for a player to want to transfer data from one interpreter to a different one. (It happens, but it’s not the common case.)
Having a reliable read-only option is valuable for the first case. It does nothing for the second case, but it’s still worth doing, I think.
Note that this might be more common in beta-testing. Especially with a game like Kerkerkruip (which is also not–yet–a common case), being able to try out different stages of the game out with different interpreters is useful, and thus being able to move files is also useful. (Kerkerkruip has anti-cheating protocols that require your saved games and externally written files to be in sync with one another.)
If you open a resource as text and read it with glk_get_line_stream, am I right that the only recognised line separator should be ASCII 10? It wouldn’t make sense to do platform-specific newline translations here.
It’s not very likely to matter, but maybe it’s worth having a note somewhere to tell authors composing text resources on Windows to save them with Unix line endings before blorbing them.
A few thoughts:* What happens if a game tries to write to such a read-only stream? Is it undefined bevaiour?
“The library should take the given filename argument, and delete any slashes or backslashes.” It might be worth noting here that libraries may remove other characters - for example, on Windows, colons, asterisks and question marks will also need to be removed.
Is stripping off any extension on the name supplied by the game a good idea? Wouldn’t it be better to respect any extension provided by the game instead, using that in preference to “.glkdata” etc.?
“When opening an existing file (that is, not in a write-only mode) it may be worth looking under the older name (suffix) before the newer one.” This might lead to problems if an new-style file exists too - would it be better to look for a file under an old name/suffix only if the new name/suffix doesn’t exist?
If data files are saved in a common directory, then collisions between filenames could be an issue. For example there might be a popular extension that saves data files under a specific name.
Perhaps there could be a new file usage mode to mark Public Data - then authors and extension writers could opt-in to the data sharing.
Yes. Same as if you tried to write to a file stream that was opened with filemode_Read. All of my library will fatal-error if you try this.
Geez, really? How 90s.
For the sake of simplicity, I’m going to say yes.
Right. I should have thought that through better.
True, but I think that this is too hypothetical to start engineering a solution right now. Game (and extension) authors can negotiate this on a case-by-case basis, and we’ll see how that goes.
