From: Erik V. <eri...@hc...> - 2007-07-17 21:37:21
|
I am turning my attention to the long-awaited Save/Load options, as I believe we are now ready to start working on that. Save/Load amounts to somehow serializing (i.e., writing away to a file) and deserializing (reading) the current state of the program. Perhaps it stands to reason to use Java's inherent serialization feature for this purpose, but I have zero experience with it, so I'm looking for the best way to start with it. A while ago I thought that serialization of the Undo stack would be a simple approach, but recently it occurred to me that, now that we have unified all player actions as PossibleAction subclass objects, it might be even simpler to build a player action stack, and serialize that stack on a Save command. The main problem is, of course, to reconstruct the previous state during deserialization on a Load command. The action objects contain references to all kinds of permanent objects (i.e., which existed before the action), so we cannot let deserialization recreate those objects (tiles, companies, certificates, trains etc.). All these objects are static in the sense that they are created at game start and do not change except for the contained owner and other relational references. So I believe we should give each such object a unique identifier (String) and serialize that identifier. Deserialization then will include just a lookup of these objects rather than a recreation. This implies that all PossibleAction subclasses must get their own writeObject() and readObject() methods. The idea is, that a Load will first read the game, variant, and player names, after which the game is started normally. Then all the saved player actions are read and executed. UI updating will be suppressed until the load is complete. There may be other ways to save a game (such as serializing all state variables), but that approach looks much more complex to me, and in any case I shy away from such an approach. As always: comments welcome. Erik Vos |