Kind of off-topic, so I created a new one, but I’m curious what kind of older hardware people are running IF games on.
I’m making my own IF authoring system and I’m wondering whether or not I should try to target glulx or z-machine, or if compiling to WASM and compiling to a teeny-tiny CLI program is just as well.
It sounds like glulx is pretty assembly-like, similar to a more domain-specific WASM, and z-macine had more IF-specific functionality, but I don’t know how low-level z-machine is.
So I’m not sure what the difficulty level is there, but I wanted to know how much motivation there should be to even try targeting those.
Personally, I think VM technology is outdated and restricts a lot of modern design patterns. Its existence was a requirement in the floppy disk days and when PCs had very little memory or disk space. TADS and Inform are probably the standard for VM platforms.
I mostly play only Z-machine and Glulx games (and a spattering of TADS and Hugo and ADRIFT, none of which you need to worry about supporting) in part because I organize my IF library with Spatterlight. If your game isn’t in one of those formats (or the Å-machine, whenever that gets interpreter support), it gets sorted to the bottom of my “to play” list.
Actually, there’s one more exception: games for the Commodore 64. Supporting at least one of Z-machine, Glulx, or the C64 makes it vastly more likely that I’ll play it.
I would say the largest audience nowadays plays via web browser, so being able to turn your game into a playable standalone web page should be a high priority.
For Glulx and the Z-machine, generating the assembly/machine code will probably not be that hard. The Z-machine has 200-some registers and a stack, for example, so switching from another kind of assembly (whether stack- or register-based) to Z-machine assembly shouldn’t be too rough. The biggest problem is the lack of a full-address-range jump instruction (computed or not).
The harder part is that they’ve got very particular ideas about how I/O should work, and circumventing those ideas can range from difficult to impossible. If your system does anything fancier than classic stdin/stdout, retrofitting Z-machine/Glulx support onto it later is not going to be a fun time.
Well I would say that I am at the other end as I do not play anything on the Web nor Phone. I prefer to download the game and be able to play it offline.
True, but for me the browser it not an ideal place to play IF, e.g. the fonts may be harder to read, certain keys may not work the same, saving games is not as convenient, etc…
Mobile experiences are pretty uneven due to hardware variations, platform inflexibilities, and who knows what else. I believe a lot of people would play mobile games if they were able, especially young people.
I think a lot of us here know what we like to do and will probably keep doing it, but making tech accessible to younger and inexperienced audiences seems worthwhile.
I too prefer playing off line, preferably in a cli interpreter. Then again, I’m also a Linux user and I do everything I don’t do in a web browser from the command line.
That said, my current machine is only a few years old(it’s a 2021 model bought in 2022 if memory serves), though it did replace a vintage 2011 system when I bought it, and I bought it because its predecessor finally broke down after a decade of service.
Your question forks into two topics I believe: maximum adressable player base and the effort you put into targeting certain standards.
I would say it strongly depends on what you consider as older hardware. But if you want to target the maximum addressable player base, you will have to include the retro scene. And that means embrace things like the Commodore 64, the Amstrad CPC or the Apple II for example. My game Hibernated has been downloaded more than 70.000 times from itch, my game Ghosts of Blackwood Manor around 60.000 times, and the phyiscal releases sold thousands of boxed copies. This is also a group where the majority are not authors but mainly “just” players. Ref. https://8bitgames.itch.io/ghosts and Hibernated 1 (Director's Cut) by Stefan Vogt.
With retro targets in mind, there is no reason to assume that games will be less quality. @mathbrush gave Hibernated a five-star review and FWIW Amy Briggs played Hibernated too, as the first piece of IF she played this millenium (her words).
Supporting the Z-machine buys you the ability to roll out to pretty much any system out there, from very retro to modern. You could use for example my Puny BuildTools to roll out the game to all the retro systems out there in under 10 seconds, packaged properly in perfectly running disk images. The BuildTools include five of my own Z-machine interpreters and countless from other authors. You will not have to waste time on: how do I get this running on system X?
This answers your question on adressable players. Now. The thing where I see you struggle the most is that Inform 7 is hungry. Even the tiniest Inform 7 game does not run on retro systems. The library alone will eat the ceiling of any 8-bit computer diskette with the blink of an eye, not even considering the demand on RAM. 64k for sure will be something between a real challenge close to impossible.
Based on this I would conclude that the question is not how low-level Z-machine is but whether it is doable on your system. I personally don’t think so. If you own the compiler (which I guess you do?) you might be able to optimize the Z-machine output though. And if you mean Z-machine yes, but only on modern systems, that is something I see adding value to your IF system.
I recently published my own modern programming language and compiler for the Z-machine. The language sits somewhere between Dialog and Inform 7 and borrows from both systems, but also invents many features on its own. I am able to create highly optimised direct Z-code instructions from the source that runs well on both retro and modern systems. But that is mostly due to the fact that I own the whole value chain, including the syntax. Owning the synxtax is an advantage you don’t have with Inform 7.
For me, the level of complexity of interactive fiction that I want to write, and I want to play, falls well within the capabilities of the Z machine. I pretty much don’t play anything that won’t run on the Z machine, but I’m sure I’m in the minority on that.
C64 with a RAM expander can run anything up to Z8 easily via Ozmoo. I’m not sure how you get a file bigger than a C64 floppy to run though. My own Apple 2 interpreter can run Z8 stories as well (still some bugs) but the bigger issue is floppy disks max out well under the 512K limit, so that interpreter requires a SmartPort (or suitable emulation).
Like Stefan, I have my own compiler that targets the Z machine and I’ve taken great pains to generate decent-quality code, including optimizing for Z3 where possible.
However, I would posit the vast majority of people playing IF these days are most likely to play it in a web browser and not really care what’s going on under the hood. Any consumer machine sold in the last 30 years should have enough horsepower to run just about any IF ever written under those constraints.
Ah that’s interesting! I am currently creating my own set of interpreters for the Z-machine. So far I have done five. Haumea for example, the Z5 interpreter for Atari 8-bit, has disk swapping capabilities. It’s something the interpreter has to handle and the disk builder has to divide the story file reasonably. I would love to point you to the sources but I have not published those yet as I tested everything against my yet unreleased Hibernated 2. Will be happy to ping you once the interpreter sources are out.
I have used Hibernated 1 as one of my test cases for my two interpreters, thank you for writing it! I hadn’t noticed/realized it wasn’t written in ZIL or Inform! Nicely done.
I can’t agree more. “Membership” is the key to growth of a community. I mean no disrespect when I say that the game engine I’m making is not meant for the veterans here. Veterans have already spent years and even decades becoming proficient with their toolchains. Trying to convince them to change is futile and only frustrates the person who is making the tool. That’s why I stopped asking questions about it. One goal of mine is to “recruit” the next generation with a visual tool that makes games that play on a native mobile app and can be shared by sending that game file, some call it a “cartridge”, around.
If you’re using old hardware (and I mean 30- or 40-year-old hardware), then you’re probably a retro enthusiast. With just a few exceptions, retro enthusiasts don’t hang out here, so you’re not likely to get many responses with an explicit answer to your question.
The BDB Project supports a number of retro platforms, but we have to promote the games in the retro communities to get any interest. Of the platforms we support, I’d say the Commodore 64 and Atari 8-bit are the most popular, but I’m sure we could drum up more interest in the others if we were to promote the games more widely.
There are no Glulx interpreters for any retro platforms, so that’s a write-off. Inform 7 games compiled to Z-code run like a dog on retro platforms. Your best bet is ZIL, Dialog or Inform using the PunyInform library. There seems to have been a huge resurgence of interest in Z-code games on retro platforms with new interpreters and new languages popping up on a regular basis, but most of these are works in progress.
I provide all my own games as a web-playable version and a downloadable version. Both versions have a large user base, so I’d recommend you do the same.
Personally, I prefer to download all games to ensure that they’re always available to play if the web site disappears or I lose internet access. I can then play them in my interpreter of choice, do screen grabs, keep transcripts and save games locally whenever I want. It’s certainly easier to double-click on a file and run it instantly, rather than try to remember where it lives on the internet (that’s if you can remember it at all) and go looking for it.
My understanding is that the Z-machine interpreters came about so that old games could be played on new hardware.
This may be a hot take, but if you are making a new system to create new games, then it doesn’t make sense to target the z-machine. If it’s so folks can run your game in a web browser, why not just target web to begin with and cut out the middle-ware?
If you’re making a new system to make new games you probably want as many people as possible to play it.
Due to the nature of interactive fiction, much of it runs well on old machines (Not I7 obviously, but PunyInform or ZIL are great choices if you want something already established). While many people are happy to play games on web browsers (I do at work because I can’t install whatever I want on a work machine) some others are likely to notice your work because new games on old hardware are not particularly common.
But as Garry pointed out, you have to work for it.
Another advantage of targeting the Z machine is that there is a huge ecosystem of interpreters, both web-based and otherwise, that will already be able to run your game on potentially any piece of consumer computing hardware produced since 1977.
Whether that’s important to you as an author or not, is of course your choice.
That’s certainly not true. Z-machine interpreters came about so that new games could be played on any hardware that had an interpreter. Given that the concept was “invented” in the late 1970s (based on the P-code Pascal interpreters), it’s been the most successful text adventure engine of all time. It’s still in use something like 50 years later and will probably still be in use for another 50 years.
Whereas your modern web-based stuff is here today, gone tomorrow according to the ever-changing world of web standards.
