EctoComp game maxed out Z8 format!

I am busily writing my EctoComp 2023 game. I have been able to solve or work around most of the obstacles for my ideas, so far.

However, the game has maxed out the Z8 format. The source text is only about 5300 words, 24 rooms and 91 things.

I never thought my modest story would need to be compiled with Glulx. I intend to release with Glulx anyway but I thought Z8 would also be a good alternative for players.

Yeah, that happens more and more easily with “modern” I7 (read: ever since indexed text was removed in…6G60, was it?). It used to be that almost all games could fit into Z8, and most even into Z5; nowadays only the smallest projects can still fit into the Z-machine, since Flex (i.e. the memory heap) has to be included by default, and RAM is precious on the Z-machine.

But! There are still some tricks you can use to save space, if you’d prefer a Z-machine version. If you turn on OMIT_UNUSED_ROUTINES, for example, it’ll optimize the code by jettisoning any routines that are never called (i.e. ones that were automatically generated or included as part of a library without ever being used in your code). You likely know this already, but I think it’s good to mention for anyone else coming across this thread.


Thank you for the info. I was wondering if I had written the story with I6 if it would have made a difference. Af this point, I just need to finish the game, get it tested and make it in time to enter EctoComp.

The clock is ticking.

Thanks again.

I don’t know about Inform 7, but Inform 6 has Abbreviations. I used it to keep Across The Stars at 512kb. I’ve also thought about getting my current game down to .z5, and I’d have to use this to pull it off.

Might not help, but I thought I’d throw it out there.

1 Like

Abbreviations help, but mostly with reducing the overall file size. The main reason I7 struggles to fit into the Z-machine is because the Z-machine has no dynamic memory allocation, so Inform needs to claim a huge chunk of its very limited and finite RAM to make its heap. Which means a game that, on its own, would not need very much RAM can still end up hitting the limit.

Most things written in I6 can still fit into the Z-machine because it doesn’t do those fancy memory tricks. If you switch to a size-optimized library, like PunyInform, or use a version of Inform before it added object-oriented features, like Inform 5, you can even get down to Z3 for most comp-sized games.


There was some size bloat somewhere back in 2014. I think it was 6L or 6M. The payoff was worth it for most people. It allowed the player to define parser messages more quickly. So rolling back to 6g60 is probably not an option. From @Draconis’s comments, and from what I’ve seen, using indexed text causes Flex/the memory heap to need a bigger default size.

So if you could get rid of all indexed text, that’d potentially help, but it could be a lot of work and it might zap some user-friendliness features (post-processing the command line.)

I agree it’s neat to have the z-machine as a goal for a project so it doesn’t get too big & you can ask yourself “do I really need this?”

One other thing–this is your first project so you may not notice that. Maybe if it’s the test build that just tipped the z-machine limits, release mode won’t, because it will be missing a lot of debug verbs and variables.

I have a weird case where my test build of Low-Key Learny Jokey Journey (on 6G60) is compileable in release mode with Z8, but it needs to be in Glulx in debug mode–unless I disable the HINT feature. (I put it in a separate extension.) This is really playing with fire, as the danger of course is sending out something without that feature. But if you want to test on the z-machine (using scripts it’s a bit faster) that’s a possibility.

1 Like

Unfortunately, it was the rease version that overmaxed Z8. Glulx it is. I will on other options if I do a re-release after the comp.

Thank you, Jeff

1 Like

If you haven’t done so, you can also try adding the following to your code:

Use memory economy.

This could help to keep it within Z-machine limits, if it’s a close thing. Docs: 2.14. Limits and the Settings panel


This is not small! A quick test here showed that my project, at 7ca98 before, dropped to 73118 after. So it’s quite significant! (I already had the OMIT_UNUSED_CODE flag set.)

By the way, to track things after it compiles,

Include (- Switches z; -) after "ICL Commands" in "Output.i6t".

and you will see memory allocation in a tab. Here’s how it looks in 6G.

1 Like

This is a good addition for the code. I was wondering how to get detailed data with I7.

Unfortunately, this code fails to work with the new version of I7 (v10.1.2). It produces a conflict the the kits that are in use.

No matter. Interpreters for Glulx are readily available for just about every platform and is certainly the future. It is a brilliant system and a vast improvement over the Z machine.

The I6 inclusion ( Include (- Switches z; -) ...) which Andrew used to show the memory allocation diagram doesn’t work in v10.1.2, but the line

Use memory economy.

by itself does work in v10.1.2. The memory savings can be compared in the “Console” subtab of the “Results” tab in the IDE, before and after adding that line. As mentioned above, it might just be enough to keep it in the Z-machine limits.

(Although of course, as you said, there’s nothing wrong with going for Glulx either.)


Yeah, the way I6 inclusions are integrated into the I7 code has completely changed in version 10. That’s actually one of the main reasons (if not the main reason) it took so much time and work compared to previous releases: putting a game together is no longer a matter of stitching together snippets of I6 and passing the result to the I6 compiler.

I believe you can pass the z switch to I6 on the command line to get that debugging output, but it’s not as easy as it used to be.