A module has a deck with 100 cards. Many of the same type.
I add a few traits for card handling and the save game size soon grows from sub 200Kb towards 800Kb.
As an experiment, I thought of a way to contain this growth; using stub pieces for the cards on the draw deck and discard pile. The stub cards are reduced to Send to Location traits to allow automated draws and a Replace with Other trait along movement triggers to switch cards into full intelligence when they are brought into play. Additionally, the in-play cards will replace themselves with their stubs when discarded.
The fully defined cards are pieces on a hidden palette, 1 per type of card (about 35 of them). Since there are normally max 20 cards in play, I figured this might reduce the game save file size.
By using a Trigger to convert Replace with Other’s “after placement” key command into a movement key command for the map on which the card gets created, it was relatively easy to convert the original cards into the deck of stub card and the palette of “in-play” cards.
Sure enough, it seems to work; containing the game save size to sub 300 Kb. Caveat being that I have yet to try a full game or see what the effect is on log files.
Are there any obvious pitfalls with this idea that may have escaped me ?
Is it worth the effort to reduce the size of a saved game which is only 800KB?
It’s an experiment. In this case it saves 9Mb in the module overall (25%). Reduction should be more significant with much more heavily loaded cards & more preset files.
My main concern is to reduce log sizes. In particular, with one module, I am coming up against the fan website’s upload limit as a log can get to 5Mb (tournament players routinely upload a log of the entire game). In a less demanding module, PBEM players, used to accumulating log files on limited cloud storage will need more frequent housekeeping when the module’s typical log file jumps from 40Kb to nearer 1Mb.
To some extent it’s a perception issue; in that it is the “nice to have” features that create this overhead.
I have to declare my experiment a failure for now, at least for my application.
Using the technique will expose the module to a race condition whereby players in an online game take an action simultaneously, resulting in a piece replacing itself in both instances; this effectively becomes a “replace & clone” once the game instances synchronise. In my experiment, the trigger for replacement was movement to or from a deck, and the decks are already set up in numerous pre-set files, so I cannot change them to prevent players from manually discarding or drawing cards (not that I would want to).
I believe that the above loophole is more usually experienced in the relatively harmless form of duplicate “card discarded” messages in those modules that generate such messages.