Zarf: to really optimise for smaller memory snapshots, it would help if Inform 6 gave us more control over the memory map, such as setting particular arrays as static. But that would be a really big change to introduce, so I don’t expect it to happen.
Angstsmurf, what do you know about the proferring relationship? It produces a 1.1MB array, which from what I can tell is only rarely modified, and I think it is most of the 6KB snapshot increase I listed above. I think it could probably be replaced with a function based system, probably through an overloaded phrase “to decide whether (X) proffers (Y):”
Yes, the proffering relation is of course what keeps track of how things are created from other things. If we letter-remove the apple to create ale, the apple now proffers the ale and the ale is proffered by the apple, and I always get these confused.
It is complicated by the fact that a thing can be proffered by (and proffer) an arbitrary number of things. There are safety mechanisms in place that make sure that we don’t create infinite loops of things that proffer themselves.
Just like we have done with the mentioning relation, it could be replaced with a list property (or two in in this case, one for proffered by and one for proffers) that every thing has. When we replaced the mentioning relation, it made things much faster, and I have a hunch it might have saved memory as well. But perhaps there are downsides that I haven’t thought of. Well, apart from being a lot of work and a source of lots of potential bugs.
EDIT: If we just want to reduce the snapshot size, it would be much easier to declare in the source that things already have the proffering relations that the initialization rule (the setting proffered rule) gives them. A thousand lines like “The spill proffers the spill” etc.
Just a small update on this: I tried replacing the proffering relation with list properties, and while it reduced the number of opcodes called by quite a lot, nearly 14 million fewer in a full game test, it actually increased the amount of memory used: the startup data file grew from 42K to 98K, and the final undo files from 84K to 143K. This also meant that the total speed increase was no more than about 4 seconds for the entire game, i.e. the increase from fewer opcodes is offset by the overhead of creating and saving those larger undo snapshots.
This is likely because I used two list properties rather than one, in order to not have to iterate through every thing in the game world to check if something is proffered by something else. I don’t know if it would be worth the trouble to try doing it with just one list property instead.
In other news, the map and the initial question now work at tass.neocities.org. It still crashes on my phone, though.
EDIT: With undo file saving forced on (rather than saving undo snapshots to memory) the game actually seems to work fine on my phone. So far I’ve completed the first two acts. Any testing of the url above on mobile devices is welcome!
EDIT 2: Oops, I tried to save and the game crashed with the QuotaExceededError mentioned earlier. Don’t try that!
Right, I think I have a rough idea of what is going on.
QuotaExceededError obviously means that the allotted local storage space for the current browser session is full. Actually, if private mode is active in Safari, no local storage at all is allowed. There are apparently ways to check for this and avoid crashing. I guess I should open a feature request on the Glkote Github page.
If private mode is off, there is still only just enough storage for our ten allowed undo snapshots and a save file or two at the beginning of the game. As we get further and more of the game state changes, the size grows of both undo snapshots and save files. Then the storage space will no longer be enough, and we eventually get the QuotaExceededError crash again.
I’ve reduced the maximum number of undo snapshots from 10 to 5 now and use only a single save file. We’ll see how far I get this time.
Well, (ab)using Ultra Undo snapshots is the only way I have found so far to avoid the out of RAM related crashes mentioned above (“A problem occurred with this web page so it was reloaded”). Only to run into out of local storage crashes, of course. These seem to be easier to handle, though. Not only can we reduce the number of allowed undo files, it is also possible to delete leftover files with the built-in Quixe file manager.
EDIT: Thanks for reporting the problem, by the way!