Vassal 4:Design Blog 1
1-Aug-17 Game Piece Definitions stored in saved games and log files
There has been some discussion over the 'problem' in V3 that a definition of each Game Pieces is copied from the module and stored in each Save Game and Log File and how this will be fixed in V4. In V4, minimal information about the structure of a game Piece will be stored in Save and Log files, the structure of the piece will be sourced from the module.
I have no opinion on whether the V3 way or V4 way is better, however, there are significant implications of changing this that need to be appreciated and should be taken into account in the design of V4.
Implications of the V3 way
The original designer of Vassal considered it an important design goal that when a log file was played back, it would always show exactly what occurred during the original creation of the log file, even on a later version of the module where the Game Piece definitions may have been modified.
Pros
- Playback guaranteed to reproduce original game moves.
- Don't need to keep track of old versions of modules to play back old log files. (Except where a module has undergone major surgery and become incompatible).
- There is consistent behavior if players are playing with two different versions of the module. A particular Game Piece will behave the same for both players.
Cons
- Increases size of log and save files.
- Save files require conversion to update the definitions of pieces they contain.
- There is no way to update save files if there have been structural changes to the module (add/remove map windows, move/change Decks).
Implications of the V4 way
It is not clear exactly what information will be contained in V4 save and log files, but the general consensus seems to be that people would like to move away from the current system to one where the Game Piece definitions are not stored in save and log files.
Pros
- Smaller log & save files
- Log and save files will auto-update to match the version of the module they are running on.
- (Possibly) No need to convert save files to work on a new version of the module.
Cons
- If a log file is replayed on any version of the module except for EXACTLY the same one the log file was created with, there is no guarantee you will see what actually happened in the initial creation of the log file. It is up to players to keep track of every version of every module they have ever used if they want ensure log file replayability.
- Inconsistent behavior if players are using different versions of the module. A single game Piece may behave differently for each player.
Issues
- It will probably require players to be far more aware of what version of the module is being used by other players.
- Playing rooms on servers should probably have default setting that players are not allowed to join a game unless that have the same version of the module.
- We will probably need a different structure for the module manager where save and log files are grouped and displayed with the version of the module they where created with.