I just used the -s switch on my z8 I6 WIP and froze in utter terror. I have 539 objects, which according to the compiler is exactly 100 below maximum. 639? I mean, talk about an arbitrary number! Is there any way I can increase this whimsical “maximum”? I also have 1503 dictionary entries, the maximum being 2000.
o_O Same problem here: 405/639 objects, 206/233 global vars…
Some limits can be increased by passing arguments to inform:
inform '$MAX_OBJECTS=1000' '$MAX_DICT_ENTRIES=3000'
I’m not sure if there is a master list of such variables, but in any case Inform should tell you how to increase a limit if you run into one (and if it’s possible to increase that particular limit).
There is no maximum number of objects in V4+ games, apart from limitations due to memory. With memory constraints in mind, the absolute maximum number of objects you might cram into a game is something like 4500. If your objects actually have properties, though, that number drops…
The number of dictionary entries, like objects, is limited only by memory.
As for global variables, Grueslayer, the 233 is a hard limit (the library uses around 100 of those itself). You really shouldn’t be using too many globals, though; as with most languages, globals should be used sparingly in Inform, and if you find yourself hitting the limit, there are probably better ways to achieve your desired outcome.
Oh dear. I’m doing everything with global variables, like flags and stati of puzzles. Hm, probably need to turn a few of them into properties then…
So how do you explain I7?
I suppose it depends on how you define a global, but if you narrow it down to only actual global variables (and not objects etc) people tend to abuse them in I7 just like in any other language.
But does it count as abuse when sometimes it’s the only way to pass additional data to a function? That seems to me like it’s just normal use. Also, aren’t built-in phrases like “we have taken the book” and “the Dungeon has been lit for at least three turns” modeled using global variables?
IF languages (including both I6 and I7) usually put every game object in a global namespace. So the principle of avoiding global variables is more or less meaningless. I6 just happens to be short on them, so there’s a practical reason to avoid them. Instead, you wind up making a two-level namespace (properties and attributes of the global objects).
This turns out to fit most IF programming pretty well; you often do think about states in association with objects.
Since I7 was built on I6, by people familiar with I6, it retains this orientation – it gives you several ways to store your state object-wise. (Properties, relations on objects, tables with an object column, etc.) But then there are global variables, tables with other formats, properties of scenes, and so on. None of these are limited (well, not nearly as tightly as I6’s global variables) so you can really handle them however is comfortable.
The forum is scolding me for thread-necromancy, but this nine-year-old answer was very helpful to me just now. I was surprised by this as well, as I am working on an ozmoo/PunyInform game right now and paying close attention to these maxima. I was surprised to see that even a
$huge z8 file listed 639 objects max, when the z-machine format comparisons all say that z5 and later can hold 65536 objects!
The trick is to run
inform6 '$list', which in 6.34 on Linux gets me the following results for the three different memory strategies (an empty cell means no change from the value to the left):
I am building a
$small z5 game (which only seems to be 1k larger on disk than the z3 build) to run under ozmoo, but it’s nice to know I could tune up any of these settings individually without blowing my RAM budget on all the other ones.
Oh, it’s also handy to query these with the
$?<name> syntax, as mentioned on page 288 of the IDM4 (print edition):
$ inform6 '$?MAX_LINESPACE' Inform 6.34 for Unix (21st May 2020) MAX_LINESPACE is the size of workspace used to store grammar lines, so may need increasing in games with complex or extensive grammars. [No compilation requested]