Since my first article on The History of the Z-machine was released, I’ve been working on a second article, which can be quickly summarised as a short tutorial on the basics of authoring in ZIL. However, as I reach the end of its second draft, I begin to wonder, what is my aim here?
Okay, that doesn’t make much sense. My point is, what are you interested in learning about? What articles on ZIL would you want to read? Anything is valid, as long as it’s about ZIL in some way!
I’m primarily interested in the syntax and some examples in action.
what can zil do easier or better than other languages and how? or what are its other advantages/quirks to know?
One feature ZIL has that most other IF languages don’t is compile-time macros (since its origins lie in LISP). It would be cool to see some different things that could be used for.
Staying on the good side of the Ghost of Stu Galley…
…if that’s even possible.
A few thoughts:
-I personally wonder how the Z-machine worked on smaller machines like the TRS-80 and Commodore 64. As the names might imply, these machines could not hold 64K of program in the ROM at a time. I wonder if earlier games used less dynamic memory, and so later Z3 games eventually “outgrew” the systems with less memory even if they technically fit the Z3 specification?
-What is the Z-machine good at, and what is it bad at? “Bad” in this case would especially apply to the kinds of things you’d want in a text adventure or would want to implement as the “state of the art” in a text adventure game. (i.e. how Z3 couldn’t do real-time processing, and thusly it would be “bad” for someone who wanted to write a game like Border Zone with real-time elements. I think every object, even yourself, rooms, and directions, counting towards the 255-object limit in Z3 was also a wild restriction. What is Z5 bad at? What things do we take for granted in later text adventure writing systems that the Z-machine just does not have - and what would Infocom have found lacking had they continued their game-making journey after… um… Journey, and tried to make more complex “hybrid” games? I know one particular bugbear that was never really done well was text compression, at least in comparison to some of the later UK houses like Level-9 and Magnetic Scrolls.)
-You’re not Graham Nelson, and this isn’t the 90s, and we have Glulx now, so this isn’t relevant, but just humor me: If you were him, and you had to extend the Z5 standard to make a Z7 standard, what would you have done beyond what he already did (mostly allowing bigger games)? Or was that single decision pretty much all that was needed in and of itself?
-As an author, do you prefer anything about ZIL to Inform/Glulx beyond the sentimental value?
-As an author, did you chafe up against any restrictions of the Z-machine - anything you wanted to do, but couldn’t?
-What are some ways the Z-machine has been “hacked” to do cool things while remaining within the standard/being runnable on unmodified interpreters? (The IFWiki calls these “abuses”, as in “abusing the system”.)
-What’s the biggest “abuse” you think the Z-Machine would support? A game in a different language? An RPG with a command menu and ASCII graphics? Real-time ASCII gameplay like ZZT? Further beyond?!? The seldom-used bitmap function in Z6 is intriguing, as you could start to get into the realm of graphical RPGs and beyond.
-You mentioned hacking in new things to ZIL like 3 nouns. What else did you add? How was the experience - was the codebase getting unwieldy to expand?
Yes, definitely. Infocom had a chart somewhere of how much dynamic memory each platform could support. If your game went over a limit, you were dropping that platform for that game.
One thing that tends to be overlooked is that Infocom always looked at their games from a commercial point of view. It wasn’t just about what was technically possible, but more about what did they think would sell well enough to make sense. E.g:
I for one didn’t have any idea what command-line history was until several years after playing Infocom games on the C64. (Maybe I was vaguely aware of it in DOS, but.)
Interesting that you mention color selection as that was actually an area where the later Infocom interpreters took away choice from the player. The oldest ones would just honor whatever colors you were using when you loaded the game, but the later ones overrode and forced the (depending on version) gray or black screen.
I used doskey in DOS for command history features, but yeah on C64 I just typed. 
I wonder if that really was the reason. Piracy was a thing on all platforms.
it could have simply been that the BBC Micro simply didn’t have enough available RAM. You only had 32k available minus the screen and you had to keep your VM itself resident plus a sufficient working set of game code. If this set is too small, it just isn’t viable.
Not on the C64. I definitely didn’t hook up two 1541 drives to copy disks automatically when you inserted a disk in each without a Commodore being connected to them. Come to think of it, that wouldn’t even technically be piracy on Commodore since there was no Commodore hooked up. Right?
That’s right. And i definitely didn’t use Nibbles Away II and Locksmith 4.1 to copy things on the Apple II. Except to make legal backups, of course!
If widespread piracy was indeed the reason why Infocom didn’t release any games for BBC/Acorn, and it was indeed a decision fully motivated by the business aspect, it means they thought piracy would cause the sales volume to be so low that it wasn’t worth the effort/risk/investment. They evidently thought the C64 market was worth the effort/risk/investment, as they kept releasing all games they reasonably could for that platform..
I agree. However, It occurred to me that if lack of RAM was the real issue, this could be investigated by asking;
Are there any z-machine interpreters working on the 32K BBC that play Infocom’s games?
If there are, and they work well, then the RAM problem is not the limiting factor.