I’m looking for a tool to create text (only) adventures on a Windows PC that can also be exported to 8-bit retro machines that load programs from cassette tape rather than disk.
Think Level 9 rather than Infocom.
I’m particularly interested in supporting less popular computers, such as MSX, Sharp MZ series, Enterprise, Dragon etc., so being able to easily modify the export formats is a high priority.
Having the source code for the authoring tools and the interpreters would be ideal.
Scott Adams type games.
Interpreters (with source): ScottFree, PerlScott, …
Authoring tools (with source): ScottKit, sk2sadat
Infocom type games.
Even though you exclude these they are absolutely available for 8-bit computers (from tape) if you author them with one of the small libraries (Puny, ZIL,…) and limit the game size to under 50 kB.
I don’t know about z-machine interpreters for platforms you mention but the source for a z-machine interpreter is certainly available.
The only interpreters I know of that supports Z-code format games to be loaded from tape are Infocom’s own interpreter for Mini-Zork 1 for C64, and Ozmoo for C64, and Ozmoo’s support is really not that great considering save/restore still requires a diskdrive and restart is disabled.
Modifying terps if of course an option, but then you need to be a good assembler programmer and you should be prepared to spend a lot of time on this modding.
DAAD is probably a good option for this kind of project.
Anyway, Z-code games would have to be crazy small to work from tape if the computer has less than 64 KB of RAM, so a lot of 8-bits wouldn’t make good targets.
You can still purchase cassette tape drives for the C64 on the big auction site. The C64 has a command to save files to the tape drive. I imagine you could load the playable game file to the machine and then store it to tape. (?) I use one of the SD drive adapters with my C64. It is pretty reliable and quick.
As for me, I’m not interested in going back to the cassette tape days. Juggling volume and tone and loading a large file that takes 20 minutes and then doesn’t work anyway. Ugh
I was thinking the size of MiniZork 1 & 2. But that, of course, was for 64kB. If you’re targeting a 48kB system then the z3-file could only be about 20-25 kB, “crazy small”…
Indeed, the C64 isn’t the problem here. OP wants to publish their games for lots of other 8-bit platforms.
As for just loading the program from disk and saving it to tape… That’s only possible if the interpreter can handle the case that all game data is loaded into memory with the interpreter. For Z-code, that’s not the way it usually works. Game data is placed on a disk, and the interpreter loads the parts it needs as you play. The two terps I mentioned for C64 are the only ones I know of which can play a game that’s held completely in RAM.
You can always play The Dragon and the Troll, weighing in at 3.5 KB (available at Index of /if-archive/games/zcode ), but that’s more of a fun experiment than a serious game, although it does have a plot and a few puzzles.
My favorite game on the TRS-80 Model 1 Level II with 16 K Memory ($1600 circa 1977) was SubLogic’s FS-1 Flight Simulator. (it wasn’t a text game but I was an aviator at the time) It was on cassette tape and actually took about 20 minutes to load. It was amazingly good for an 8 bit machine! It was ultimately bought out by M$ and is still being produced to this day as Microsoft’s Flight Simulator 2020.
My port of “Craverly Heights” currently clocks in at 48kB. I guess that with optimization like moving common phrases to constants and using optimal abbreviations you could easily shave off about 10kB.
The most obvious choice would be to take a fairly portable BASIC text adventure engine and use that across your target platforms. There were various “engines” created back in the day that featured in programming books and magazines.
DAAD is an easy option, but doesn’t yet target the platforms that you specifically mentioned. Definitely comes highly recommended if you’re targeting most of the common 8-bit platforms, though.
The Quill covers a whole host of platforms too, but not necessarily all the ones you mentioned. (I think it is a dream of Tim Gilberts to eventually get the Quill running on the Dragon). There is no easy way to code a Quill game on a PC and export to multiple-platforms at the moment, though.
The biggest drawback is that BASIC games don’t compress the text. Better to use ScottAdams system if you can. That being said, you may even have an advantage with BASIC because it’s very flexible. For example, you may chain several games in a row, by having one way passages and requiring the players to carry over certain items, thus having a larger game than what the memory allows.
Level9 system has great advantage in text compression and graphics. I wonder if there’s a compiler for it.
I love reading these archaeological minimal-coding posts. It does make me wonder though, do you guys even have time left to play interactive fiction, or do you get your fun from the technological side of things?
It really does seem quite the absorbing hobby. It makes me jealous sometimes that I don’t have the knack for that side of IF.
As far as I know, a third-party hasn’t managed to produce any system that’s compatible with Level 9’s A-Code.
I’ve played hundreds (and hundreds) of text adventures over the years and still play plenty of new ones each year. Interactive Fiction doesn’t interest me, though.
There’s one system nobody has mentioned yet, and that is the Scott Adams’ TI-99 system. The TRS-80 format has been mentioned, but the TI-99 format runs from tape, with the adventure cartridge. You can use ScottCom to compile them and Bunyon to play them on PC. You’re limited exclusively to the TI-99 and PC, which isn’t exactly what you wanted, but it’s an option in case you wanted to check it out.
There’s also DAAD, which supports a crapload of 8-bit platforms, but none of the systems you mentioned except the MSX.
The Adams games on VIC were on cartridge. Still a feat and the story goes that they had to be carefully crammed down to fit, but storing the gamecode on ROM helped.
Presumably you could get some space back also by cutting out the “override ZILF stdlib behavior, make it feel like I7 defaults” stuff?
