I7: I want to keep a story file as zblorb

Authoring Inform 7
1

I have a small dilemma with my IFComp game Threediopolis. It was originally a zblorb, but the debug version spilled over into gblorb. I commented out some kind of bulky test modules, and it’s ok.

But it’s still in danger of needing gblorb, which isn’t so big in itself, but I’d like to keep it as a zblorb file, because that means changing fewer dropbox links etc., and I’d just like the game to still be playable in WinFrotz. But it’s not critical.

So I wanted to zap commands and actions I wasn’t using.

understand "rub" as something new

And that sort of thing didn’t seem to decrease the file size. Neither did changing various constants like

Use NUM_VERBS of 500.

(Okay, I would expect this to increase the file size, but…I’m just trying experiments.)

Now I could technically gut the Standard Rules for this game only, but that’d be too much work.

So I’m wondering if there’re any ways to keep down the need for gblorb, or anything specific to I7 that I could/should vet my code for. Perhaps anything (in general) where I7 eats up resources, but I6 wouldn’t.

For instance, I already know that tables are preferable to lists, and I’m wondering if it’s worthwhile to go with I6 arrays (which I do understand) instead of the “[one of] … [or] [cycling]” syntax.

I suspect there are also places where my code isn’t economical, but that’s my own problem.

Thanks for any and all help!

…and, by the way, is there any way to tell how close you are to needing a gblorb file? Like with the diagnostics such as txd on certain settings or something?

2

If you’re still using 6G60, avoiding indexed texts and lists completely will help a lot.

3

I assume you are running into the 64K RAM limit rather than the 512K file size limit (for Z8). This topic comes up a lot and there isn’t an easy answer.

Avoiding indexed text and dynamic lists is the lowest-hanging fruit. But perhaps that ship has already sailed for your game.

Limit properties to sub-kinds where possible. “A thing has a text called the color” allocates property space for every thing. “A jewel has a text called the color” only allocates space per jewel.

The “[one of] … [or] [cycling]” syntax is efficient; it only costs one RAM word per usage.

Most of the memory settings (like MAX_VERBS) control internal allocations in the I6 compiler. They have no effect on your game size at all.

Removing unused actions will save a small amount of RAM. Probably not worth it.

4

You can throw in the line

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

…to display a chart of the game file layout. This appears in the Results/Console tab (6L02) or the Errors/Progress tab (6G60). The second double-line (after “dictionary”) has a hexadecimal indicator of how much RAM is used. When this passes 0FFFF, you’ve broken the Z-machine.

5

Thanks to both of you. Wow!

There’s no way I can avoid using indexed text, due to the game mechanic and also to an important shortcut for player-friendliness. I don’t think I can fully avoid lists, either.

It’s great to know what is relatively effective and relatively ineffective, so I’m not working hard for little result.

Fortunately, I don’t have much to add for this next release, beyond random text. So breaking the z-machine shouldn’t be a problem. But it’s great to have that one-line diagnostic.

6

Slight clarification to my earlier post: if you have any indexed text or lists in your game, a significant amount of (virtual) RAM is set aside for indexed texts and lists to draw from as they get larger. If you remove them entirely, this heap is left out and your game uses a lot less RAM. But if you’re already using them, reducing your usage won’t help very much.

7

I just found this in the DM4, and figured it would be good to put it here for future reference. I modified this slightly to use I7 terminology where possible, and removed things which can’t be controlled in I7 (such as types of array).

Readable Memory Consumed
Each …					Costs …
Routine					0
Text in double-quotes			0
Object or class				26
Common property value			3
Non-common property value		5
"Understand" word or topic		9
Verb					3
Action					4
Table entry				2

Note that this refers only to readable memory, but that’s what you’re most likely to run out of.

8

Wow! This is really helpful. I’ll poke around to see more. I found out I was just under f100 in my own project, so I have enough wiggle room, unless I start adding a lot of text.

It’s neat to see where a lot of memory goes, and what’s most likely to push a game into GBlorb territory. The sort of question I’d wondered about but never sat down rigorously enough to ask.

9

Note that that table describes the I6 system (and it predates Glulx).

I7 implements properties and tables in a more complicated way, so more memory is used. In 6L02, text also becomes more complicated (because it’s all indexed).