I was thinking about whether using features that are not universally supported by interpreters (especially sound effects, but other examples would be unicode, text colors, graphics, etc.) might affect the longevity of a game. I wonder whether media formats that are usable now (like Ogg Vorbis) will still be widely playable in the future, and whether any Glulx interpreters that might be available in the future are likely to support less-used features like sound.
I’m thinking about how much effort to put into allowing for the possibility that these features will not always be supported. In some cases it can be difficult to find a workaround that is satisfying or appealing, and I’m not sure which is better–a not-very-appealing substitute/workaround, or just the ability to skip whatever it is.
Given that Ogg Vorbis is free and open source, I think it’s pretty unlikely that there would exist a future where it’s unplayable but the Glulx format is perfectly viable. (That is, if there’s a future where ogg is unreadable, glulx would probably also be unreadable in that future.)
Even if some other audio format one day becomes more popular than ogg, I don’t think support for ogg would suddenly vanish.
That probably applies to Unicode and most image formats as well.
For Unicode specifically, it’s been more and more supported over the years; I don’t foresee a future where it goes away but Latin-1 sticks around. And Z-machine version 6 interpreters are still being designed to work with Infocom’s archaic graphics formats which are used by nobody else.
So I don’t think that should be much of a concern. There will always be platforms that don’t support particular features (e.g. text color on Discord bots), so it’s good to think about alternatives, but I don’t expect any of them to truly disappear in the future—there will also always be dedicated interpreters like Gargoyle and Parchment that try to support as much as possible.
It’s kind of too bad that MOD and MIDI lost popularity. I suppose it’s because most of their benefits were in saving file size compared to pure audio, but…
If the interpreter uses the source of a decoder directly, then it should always be available. A lot of web based interpreters might expect the host browser to decode stuff, and it’s possible that a later browser might drop older formats. I see this with video formats.
I always felt that by sticking to audiovisual features of the Glulx spec, my game was more likely to be future-proof. As opposed to using any website-hybrid tech outside Glulx, etc.
The problem with MOD is that, in the context of IF, it’s really 4 formats. Blorb supports original mod, ImpulseTracker, FastTracker 2 Extended, and ScreamTracker 3. So the Blorb spec says “just use libmodplug to handle it”. Which is great if that works in your interpreter.
But for Parchment I couldn’t just plug libmodplug into its audio output because it doesn’t work the same as it would in a C program. I needed the Blorb audio files to be converted into WAV or MP3 for the browser to accept. I couldn’t find a JS MOD library that looked reliable, nor a Rust one, and libmodplug wasn’t straightforward to build to WASM (and I think I’d have to somehow hook its output up to an encoder etc.) I don’t think MOD files have even been used in Glulxe games outside of test files, so I decided it’s just not worth it to try getting support working.