Okay, let’s try and come at this from another direction.
Even if it was practical to create a tape-based z-machine, the system I am proposing would still be more memory efficient (which is important for retro machines).
For example, if you created a game that did not have containers or doors, the z-machine file would still contain routines to handle those (and use up memory) even though you didn’t use them.
This is one of the drawbacks to using virtual machines and interpreters.
In the system I envision, only code that’s actually needed would end up in the final executable.
This is why I don’t understand why Adventuron is online only. Why can’t I just download a directory in a zip file and be done with it? That way, I don’t have to deal with flaky online connection, as well as worry about updates that will mess up with WIP.
I did check out Adventuron and I think that it’s a beautiful system. Alas, my brain is still thinking primitive, and so keep looking for arrays instead of lists.
Also, a compiler to compile source code from vim.
To be honest, I’m not entirely sure what this thread is for anymore. Are you trying to convince us to give you permission to write this? Because it feels less like “What do you think about this idea?” and more like “Let me convince you as to why this is something that needs to be done.” Which, I mean, I don’t care either way, honestly. I was never the target audience.
It seems like an absolute ton of work with the most miniscule nichest market of IF players (which is saying something), but if you really want to make it, you should just make it. You don’t need to convince us.
Whilst Adventuron Classroom is not (yet) open source, the online (distributed) version of Adventuron is actually available offline, via archive dot org, as a zipfile. I care very much about digital rot, and all game generated by Adventuron are DRM free with no “phoning home” or active DRM:
With regards to Adventuron Pico, Pico is essentially a well defined data structure along with the code generation templates. The front-end DSL can be whatever you like, defined in whatever editor you want.
Pico doesn’t technically use the Adventuron codebase but uses a well defined subset of the syntax, which you can assume is approximately the same as the 8-bit mode of the current version of Adventuron.
The one hard limit of Pico (version 1) is that it is VERB NOUN only. But I still believe there is a lot of fun to be had with VERB NOUN, and it also presents opportunities for presenting keyboardless UIs on certain platforms (Pico 8 is a goal).
If people ask how/why this system would be better than something else (which is a legitimate question), then it makes sense for me to explain.
The two main objectives of this thread are to find out whether anyone else would find the system useful and if so, how to best go about creating it to benefit the largest audience.
Oh, I must have missed it. I’ll double check then. Thanks.
Pico 8, the hardware? That’s really cool! I’m looking forward to it! I don’t mind VERB NOUN only, although if you can somehow do VNN, that’s fine, too.
Nope. The Z-machine doesn’t know anything about specific types of objects. The library adds (or doesn’t add) properties, attributes and routines to handle things like doors, containers, light sources etc. You can create your own library, or remove parts you don’t like from an existing library. If you write in Inform 6 you can even add a commandline option to say “remove all routines that are never called”. Using this switch is part of standard operating procedure for PunyInform programmers. I.e. if you don’t start any daemons in your code, the StartDaemon routine is left out.
What the Z-machine provides is basically:
Generic machine code level instructions (Z-machine assembly language), like “compare a and b and jump if a < b”, or “add a and b, put the result in c”
A stack
Routines to read a line of input from the keyboard, split the input into words, lookup the words in a dictionary which the programmer provides
A routine to draw a statusline (only z1-z3).
A screen model which works on all target platforms. For most platforms you can split the screen into two areas, typically used to create a statusline, menus etc.
Routines to save and restore the current state of the virtual machine
(optionally) Routines to handle undo
(optionally) Routines to print output to a file or printer
An object datatype, where objects can be arranged into object trees and objects can have properties (8-bit or 16-bit values) and attributes (1-bit values).
A standardized header which has information about the game, and can be used for (limited) communication between the game and the interpreter, i.e. the game can set a flag to say “I’d like to use different colours” and the interpreter can clear the flag to say “No”
Maybe that was a bad example. I don’t know the details of what a z-machine includes.
Regardless, a z-machine has certain built-in features that you cannot easily add to or remove, which is why there are several versions (so you can choose one with the features you need).
It strikes me that this would benefit from being a purely declarative language. Something that describes “what” but not “how”.
It would then be the job of the transpiler to create the “how”, but crucially, it would be in control of all necessary parts to support this. Like this you could be sure you have the minimum baggage, as required by tape based systems.
Isn’t that Inform 7? All those is statements are declarative.
(Of course, In order for the player to take actions in the game, you also need a declarative rules engine, declaring under which conditions the rules fire, and then some typically imperative commands to run when the rule’s preconditions have occurred. Inform 7 provides this, also!)
Here’s my take. If you want to write a text-adventure platform for an 8KB MSX machine, do it, but I think you would benefit from implementing a toy Z-machine interpreter first. Understand what it does and doesn’t do, and how you would improve upon it, and what parts of the Z-machine design you’d want to reuse.
Which is to say, I’m pretty sure you’ll find that there are parts that you’d want to reuse; quite a lot of parts, actually.
If the end result is a Z-machine transpiler that can take Z-machine games written in PunyInform and run them in 8KB environments, well, great! If the end result is a “Wys-machine” that compiles PunyInform directly into something else, that’s fine, too.
And if you want to design your own language, do it, but just be aware that recruiting authors will be extremely difficult. If you’d have fun with this even if nobody else used it, then definitely do it.
But if you won’t have fun (or feel accomplished) unless you can recruit authors, then, beware, because that is the hardest task you’ve discussed on this thread, by far, and the most likely to actually Fail to occur. As I’ve said to other would-be designers of IF languages, the path up this mountain is littered with the frozen corpses of others who have tried and failed to reach the top.
You could do. What i would do is go for the absolute simplest system i could possibly imagine. Something like either, choices + a few flags, or a 2 word parser + a state table (a bit like Scott Adams).
Then I’d try to get it working.
Having done some development on retro computers i can highly recommend keeping things super simple. I have a rule: No CPU, no memory and no performance. That’s what you’ve got to work with
The flipside, is that it’s quite a lot of fun getting anything at all working on these old machines.
Also, how do you know those frozen corpses aren’t actually on the way down?
Regarding the Z-machine and tape, Infocom did it for a couple demos for C64 tape. The Ozmoo team was experimenting with that too, but I’m not clear on how far that effort went. It’s doable as long as the game can be made to fit in RAM.
@jkj_yuio : Creating an unusual coding language for an unusual system would put a lot of potential users off even trying it.
I used to code in BASIC on several retro machines when they were new, and I found that half the fun with creating text adventures was trying to squeeze as much text into memory as possible.
I even played around with storing text in video memory on one machine. It was slow, but it worked.
@dfabulich : 8Kb is taking things a little too far. I had imagined a minimum of 32Kb with a preference for 64 (or more).
If I were to try creating a virtual machine or interpreter, I’d be more likely to use Level 9’s a-machine as inspiration, as despite info on it being harder to find, it was made for tape-based systems with 16Kb memory.
The language I’m still not sure about. It would definitely have to be similar to one or more existing languages.
Of all the authoring languages I’ve looked at so far, ALAN seems to be the best balance between natural English and traditional programming code.
Out of the general purpose programming languages I’ve tried, I prefer structured BASIC and Pascal.
There’s, as many other have stated, nothing in the z-machine that stops it from being run from tape. You obviously have to limit the game size so all of the game + the interpreter fits inside the available memory.
I made a single PRG z5 file of the ZIL version of “Craverly Heights” for C64 with Ozmoo yesterday without problem. This file loads completely into memory and easily could be saved to tape.
Personally I would try to write a minimal z-machine, maybe only support z3. Then strip down a existing library (Puny or Zilf) to remove unused functions. I think I read somewhere that 70% of a game is text so text compression is important. One modification to the z-machine, that would break the games compatibilty to other z-machines, would be to improve the text compression algorithm. Here one could experiment with lzw or try Level 9’s compressing scheme.
It would be interesting to make a proper comparison between Z-code and Level 9 A-code text compression. When compiling Craverly Heights for PunyInform, using Hugo Labrande’s abbreviation finding algorithm and the latest compiler patch to apply abbreviations in the best way, the game text (41688 characters) is compressed to 56% of its original size (not sure if the size of the abbreviations used is accounted for though). I don’t think that’s alarmingly bad, considering we’re dealing with short string compression, and unpacking must be doable by a small and fast routine.
I made some calculations over here and if I made them correctly the text is compressed to 17.687 bytes (42.4%) of the original text size on the ZIL version of Craverly Heights. The z5 version are 47.464 bytes and if I compress it with LZW (zip) the file is compressed to 32.371 bytes. That would be some kind of theoretical lower limit. My guess would be that you could cram out maybe 4-5 kB more with a optimal compression but the real time decompression on a 8-bit computer is a challenge.
The main objections I have to creating a z-machine instead of an a-machine are:-
It would only teach me something new
The end result would not be very unique or useful
However, I would probably research how a z-machine is put together to compare it with other systems.
Is there much information available on Level 9’s compression system? I thought that reverse engineering had only gained insight into how to decompress their data?
Also, does anyone know if a-code was a high level programming language, some sort of low level assembly language or a specialised database/spreadsheet system?
I think a low footprint z-machine with highly optimized compression that leave an additional 4-5 kB for game-data would be greatly appreciated by the 8-bit guys and gals.
There’s actually two different compression algorithms used in L9, one in v1-2 and another in v3-4. I and @fredrik are working on a document and have quite a bit of understanding of them. If you have insight on how to decompress you’ll also know how to compress. For version 1 and 2 you only need an algorithm to find 162 abbreviations and this would be practically the same as finding abbreviations for z-machine games. For version 3 and 4 you’ll need an algorithm to find an optimal set of words for the dictionary. You could probably use the one existing in current L9 games otherwise a script that count word frequency could work.
I would say that with the information known to me now that it’s pretty low-level. The opcodes for a-code are a minimal set. The L9 compiler tools could have been more complex and supported a higher level, though. It would be reatively easy to write an a-machine interpreter. It would be much harder/more work to design a language and a compiler.
You’re certainly welcome to join the effort of documenting the L9 format.
I thought the text compression was done during the code and build processes? If that is the case, then wouldn’t any improvements need to be made to the z-code compiler rather than the z-machine?
For the a-machine, it was the routines for choosing the best phrases to optimise I was wondering about. I wouldn’t have thought that knowing which phrases were actually chosen would give that much insight.
I was hoping to be able to transpile to a-code, once the Level 9 code archive is released, and have always wondered if it resembles ZIL in any way.
How would I go about doing that? Is there a Google Group or some sort of central repository for information gained so far?
Are you trying to convince us to give you permission to write this? Because it feels less like “What do you think about this idea?” and more like “Let me convince you as to why this is something that needs to be done.” Which, I mean, I don’t care either way, honestly. I was never the target audience.