Multiple gblorb file game

Authoring Inform 7
1

I don’t have a specific question, as I don’t yet know anything about it. Can someone give some overview of how this is accomplished and point me toward a list of resources? I want to explore making one large game out of multiple files, and have the game be able to compile each “region”, each “gblorb” as I understand it, independently, but maybe allow some items to transfer in the core game to be accessible from one to the other.

Draconis gave me the idea that this was possible, but, again, I know nothing about how to proceed, so please share!

2

Blorb is just a container for a game file and some image/sound resources.

There’s been some discussion of of distributing several game files which are logically one game, and having them exchange data via external data files. I don’t think anybody’s done it but the features in the manual (23.11 through 23.15) are designed for that sort of thing.

See also: https://intfiction.org/t/i7-continuing-saves-between-different-games/3329/1

3

I guess I wasn’t thinking about releasing multiple games that you have to load up, save your progress to an external file, then load up the other game. The architecture I was thinking about was the reverse (or something like the reverse) where you have a single main game, and it stays loaded, but reaches out to external “content” files, one at a time when different conditions are met.

I read the external files documentation, and it looks like I can store a table in an external file. I have questions about this. If I am using an structure where 1 table is used to store the information about 1 object, would that mean if I had 1000 objects, each with their own table, that I’d have to have 1000 external files? I was hoping for a way to store external data in a single, or limited number, of files.

Is any of this making any sense, and if so, is it possible?

Also, reading these other topics, I keep running across people making claims that you should be able to have a game that is so large you could never write enough code to fill it, like multiple gigabytes worth, and that people have written games that have thousands of objects. If that is so, why is there this problem here:

A prop is a kind of thing.

The void is a room.

100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.

The kitchen is a room.

The player is in the kitchen.

This compiles without issue, but this does not (note there are 100 additional props):

A prop is a kind of thing.

The void is a room.

100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.

The kitchen is a room.

The player is in the kitchen.

So I try to up memory settings, and admittedly I have no idea what I am doing with these, but I just keep adding zeros:

Use MAX_PROP_TABLE_SIZE of 100000000.

Use MAX_OBJECTS of 10000000.

Use maximum things understood at once of at least 10000.

Use MAX_STATIC_DATA of 100000000.

A prop is a kind of thing.

The void is a room.

100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.

The kitchen is a room.

The player is in the kitchen.

This works, but adding another 100 props makes it fail again. Beyond this point, adding more zeros to the memory settings doesn’t allow for any more things. Now, there are only 1800 things here, and the game is as simple as can be, with no properties on those things, or any logic. That’s not “thousands” of things or anywhere close to 2 gigabytes of data. I realize I may sound dumb to those that understand the internal workings of the memory allocation mechanics, but that’s why I am asking the questions here. What am I missing to get a big application? Why is it that I am limited to less than 2000 things, without even having a real game, but people are saying that you should be able to make a game so big you never will be able to?

Are they using some kind of methodology similar to that of my OP in this thread, or how is this accomplished?

4

I used these settings and got up to three times as many objects as your example – that’s over 5000. Compilation got pretty slow, though.

Use MAX_OBJECTS of 10000.
Use MAX_PROP_TABLE_SIZE of 2000000.
Use MAX_STATIC_DATA of 1000000.
Use MAX_SYMBOLS of 40000.
Use MAX_ARRAYS of 40000.
Use MAX_NUM_STATIC_STRINGS of 40000.
5

I was able to replicate those results, about 5000 things, with those settings. Thank you for that, as I don’t really know what those settings do.

However, I added a property to each thing, and it broke again:

Use MAX_OBJECTS of 10000.
Use MAX_PROP_TABLE_SIZE of 2000000.
Use MAX_STATIC_DATA of 1000000.
Use MAX_SYMBOLS of 40000.
Use MAX_ARRAYS of 40000.
Use MAX_NUM_STATIC_STRINGS of 40000.

A prop is a kind of thing.

A prop has a text called stress.

The void is a room.

100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.
100 props are in the void.

The kitchen is a room.

The player is in the kitchen.

There are now 5000 things each with a text. This won’t compile. Obviously looping through or doing route-finding or various things on this would also be a problem, so that’s why I was hoping to be able to store items in external files, not all at once, and only look through relevant data stores for the “area” or “condition” of the game at a particular point in play. I would like to have a game that has “access” to 5000 (or whatever number) of things, but only have to deal with a much smaller number of them at a time.

6

Ok, so I’ve looked into this myself some more, and it seems clear that there is no way to split the game into multiple files, not really. You can have multiple games that the player can load up in succession, and pass save data between the games, but that’s not what I’m after.

Also, you can store information outside the game in external files, but this means that data stored in these external files needs to be copied for each “save”, and that’s also not what I’m looking for. Additionally, you cannot store rules in external tables, and that is also an issue for making the tables able to relate one item based on a table to another.

I did some testing, and it seems that it doesn’t really matter what the code element is, an object, a table, a rule, a property, etc… they all take up memory in the same way. I added hundreds of tables (created with unique names and data numerically by batch replace in another program), and this brought performance to it’s knees, so there was no reason to test the limits as it was obvious from that alone that multiple tables have a similar effect on the application as multiple objects.

I also added hundreds of rules, and this had the same effect on the application as objects and tables.

Then I tried adding tables with thousands of rows… and to my surprise, this was the best option so far. A table with 5000 rows is better than 600 tables with 1 row, by far, for performance and maximum compilability at all.

So, this has me thinking that the best architecture for maximizing stuff in the game (without resorting to external files, as that has caveats I don’t want) is to list parameters for many objects inside one table. Not using one table for all objects, but grouping like objects together in one table, and having a rule for each type of object. This way, I can have lots of records, but also limit how many rows repeats have to loop through by chunking out the data into logical groupings, and have only as many rules for “props becoming things” as I do tables of kinds of things.

If anyone read my rambling here and is following what I am trying to say, please comment on this high-level outline of my proposed approach and let me know what you think. Again, the idea isn’t to get infinite things, but to maximize the number of things presentable to the player with the minimal impact to performance possible.

7

Double MAX_SYMBOLS and MAX_NUM_STATIC_STRINGS.