Text adventure framework with transpiler - crazy idea?

What about the language you’re transpiling from ?

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.

A domain specific declarative language for IF.

Has there been any work in this area?

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!)

1 Like

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 :slight_smile:

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?

1 Like

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.

1 Like

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.

1 Like

The main objections I have to creating a z-machine instead of an a-machine are:-

  1. It would only teach me something new
  2. 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.

1 Like

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?

A-code can be thought of as the machine code of Level 9’s A-machine. The A-machine is an 8-bit virtual machine with a 64 KB address space and whose machine code (i.e. the A-code) is specially designed for writing text adventure games.

I would assume that Level 9 used a high-level language when writing their games and compiled this to A-code or used some authoring tool which generated A-code. Hopefully, we will know more about this when @8bit_era’s and Mike Austin’s work with preserving the original Level 9 development tools is done.


I can’t help wondering if they reused some of their work on extending Nascom BASIC when creating their compiler.

I would say A-code is very similar to Z-code. It’s mainly generic low level instructions, with a few high-level instructions tailored to what text adventure authors need.

It looks to me like the designers of A-code have been thinking more like Basic programmers than the designers of Z-code, e.g. there are subroutines and they don’t have local variables. I would think Level 9 used some kind of Basic to program their games, and this code was then compiled to A-code.

PM me if you want to join in on the fun of figuring out the A-code format.


There need to be changes in both ends. The z-code compiler needs to compress with a new algorithm and the z-machine needs to know how to decompress this new algorithm. With these kind of changes it stops being a “z-machine”, though.

1 Like

That’s what I thought, which would mean using a different compiler as well as a different interpreter.

There’s a major obvious issue, and one minor but serious issue, in my krazy idea (actually a wet dream…): using the GCC (GNU compilers collection) concept, a front-end for the languages and a back-end for the binaries, linked with an intermediate pseudocode language. compiling a TADS source into glulx story file or an Inform 6/7 into TADS story file, or even writing with multiple language and releasing in multiple story files (as noted in my debate on strengths of IF language, writing the room descriptions in Inform 7 and his powerful adaptive prose support, and implementing the NPC in TADS 3, eventually with a parser written from scratch in Alan 3, and then successfully compiling all this indifferently in glulx, T3 or even hugo story files, isn’t the perfect ideal IF environment ? is obvious why I call this my major wet dream in IF coding

(being a Naval historian, I often use Fortran together with C in my research coding, so I know personally the vantage of using the specific strenght of languages)

the catches are first, that the coding work is perhaps beyond the coding prowess we have around, and second, that if one don’t start from true scratch, but from the GCC codebase, ALL the languages/sory file formats should be compatible with the GPL or the LGPL, and I don’t think is easy tracking and coaxing every language/story file author into relicensing into a (L)GPL compatible license…

Sorry for the inevitable igniting of the debate, and

Best regards from Italy,
dott. Piergiorgio.

1 Like

Maybe I’m misunderstanding your description, but it seems to me that it would be easier to create a new language with the features and syntax you need, and transpile that into several output formats.

The licenses for the programs which use the output formats shouldn’t matter, as this system would work independently of the other systems without involving their source code.

Most of these languages are tailor-made for their respective target formats, and the target formats support specialized commands and data structures. They won’t mix well.

1 Like