Viola! A Z-Machine in Python

After only ten years, I’ve released another version of my Python Z-Machine interpreter, Viola. I’ve just uploaded it to the if-archive, so it’ll still take a while to find its place there, but in the meantime, you can find it all at https://github.com/DFillmore/viola.

I should note that it requires Python 3, and pygame.

Features!

  • Viola supports Z-Machine Versions 1-8, including full z6 support (with pictures! and sound!).
  • Viola complies with the Z-Machine Standards Document Version 1.1
  • Viola complies with the Blorb IF Resource Collection Format Standard Version 2.0-ish.
  • Viola complies with the Quetzal Z-machine Common Save-File Format Standard Version 1.4
  • Viola has most of the features of the current Z-Machine 1.2 Standard proposal implemented, for testing purposes (and it actually claims 1.2 spec compliance, even though that’s not a thing yet)
  • Viola is slow. Especially when running Inform 7 games.

So far, almost all testing has been done by me. If people could try it out, and give me some feedback, I’d be grateful.

Nitpick about the brief history of the Z-machine; aren’t most Z-machine games since Inform went out of business z8 games? Or at least, z5 or z8 games.

I wrote that 10 years ago, when it was almost certainly true. I wasn’t certain it still was, so I checked.

A quick scan of the text of http://ifarchive.org/indexes/if-archiveXgamesXzcode.html reveals 408 counts of ‘z5’, 83 counts of ‘z8’ and 164 counts of ‘zblorb’.

Interesting. I think the “release as a blorb” option is checked by default in Inform 7, so a lot of the more recent games are probably blorbed. But that’s still a pretty solid majority for z5 games.

…which is going to go downhill very quickly from now on, as I7 no longer compiles to .z5.

I still doubt the number of z8 games is going to go up very fast. z8 is barely big enough to handle a tiny Inform 7 game these days, and the latest I7 compiles to Glulx by default. Very few people are likely to want to even bother with the Z-Machine anymore.

True. Shame, because it’s still the most portable format, but time marches on, I guess.

I’m curious whether, someday, perhaps we will be able to optionally make I7 stories using some more-minimal version of the Standard Rules that omits certain things (I know not what; just spitballing here). A suite of built-in assumptions about the world is useful for joes like me who don’t want to build a world model from scratch, but I’d assume it can become a headache somewhat quickly for more advanced users who would rather trim or jettison some of that for efficiency’s sake… But I suppose Inform 6 is still available for people who seriously want to put in the effort for ultra-trim games.

Anyway, on topic: Boo, Python 3. <3 As a user of 2.7, I quietly grumble in the corner. I just haven’t bothered to try 3 because I’m already using 2.7 and feel like it might be a hassle to get both working on the same computer. (I’m somewhat lazy.)
This might make me want to try, though. Maybe examining the code for a Z-machine written in a language I understand will help me get a better grip on how Z-code works, and… know your format, and all that.

Viola was written in Python 2 for many years until I got completely fed up of the confusion and frustration I experienced every single time I tried to deal with Unicode.

As for the slowness of Viola when running Inform 7 games, further research indicates that this is mostly a problem when running games created with early versions of Inform 7. More recent Inform 7 releases seem to be designed to be a lot faster.

Well… Ron Newcombe has made an extension that fully replicates the parser in I7.

In a world where someone would do that, I’d imagine it’d be totally plausible that some day someone will present us with an alternative to Standard Rules, more lightweight, trimming a number of features the author might not require, bringing the complexity and file size down.

It’s a bit moot because even Glulx files are mostly small anyway, and because I7 no longer compiles to any zMachine smaller than z8. The biggest argument you’d have to do that (and it IS a valid argument) is that there are interpreters out there, for some devices (don’t ask me which right now) that don’t support Glulx.

It is difficult to trim down the I7 Standard Rules because things are generally integrated. Obvious example is indexed text and other dynamic heap objects. Up to 6G60 these were optional and were only included if used, but now that text and indexed text are the same, you can’t get rid of that code. You can’t get rid of the table code because the Standard Rules include a couple of tables. Etc.

Clearly it’s possible, but I don’t know if it’s worth it. Do you want to rip out the Table of Locale Priorities and rewrite chunks of the room-description algorithm just so that the table code can be discarded? Maybe.

I guess the first step is to inventory a one-room I7 game and see exactly how big each set of functions (and arrays, etc) are. I suspect that the biggest chunk will be eaten by indexed text and regular expressions – but that’s just a guess.

Regular expressions could still be excluded I would guess… just because the text types are unified doesn’t mean they’re used. But uncalled functions don’t impact performance, just file size.

Yeah, like I said, the only advantage to this would be getting back the serious possibility of compiling reallistically to the ZMachine. Not a serious worry for most people. If for anyone.

Also, if someone were really concerned with having to create a zCode game because they’re targetting a platform without Glulx support… I wouldn’t say they always have I6, but they certainly have the previous version of I7.

Still… in a world where someone replicates the whole parser, I still don’t think it’s unlikely at all that someone would do this. :slight_smile: