How to upload modules to the Game Library

Documentation
29

Is there a question in there?

World in Flames is a monster - not only the physical game, but also the Vassal module. Great that you can get it down in size (from 928 MB to 500+ MB) thought it is still big.

Previously there’s been some thoughts on how to make the module smaller. That included

  • Scale down images by a factor of 2
    • This will not affect the usability of the module - there’s still plenty of resolution to zoom in to at least 300% magnification.
  • Do not make embedded definitions of pieces for Place Marker and Replace with Other traits.
    • This very much affect the size of the .vsav files - both those embedded in the module and - more significantly - those produced by players.
    • It also affects the in-memory footprint of the module and the amount of data transferred in networked games, slowing down the module both in local and networked games (especially over long lines of communications - Think moving a Tiger I versus a Mathilda II (image) across North Africa, though not a perfect allegory because of the engine in the Tiger I :smile:).
  • …

One thing is how big the module is on disk - quite another how big it is in memory. One would have monitor the memory usage of the Vassal process, when playing the game, to understand that.

There’s no reason why you could not leave out the manual from the module itself, and provide it in a different Package - one that presumably rarely changes.

Similarly, the various embedded .vsav could be extracted and provided as separate files - either in same package as the module or in a different package.

If you adopt a convention that

  • The patch version number is incremented when small and non-breaking (i.e., piece or prototype definitions) changes are made.
  • The minor version number is incremented when breaking (i.e. piece or prototype definitions) changes are made.
  • The major version is incremented on larger overhauls.

Then you could have the packages

  • Module: This is where the .vmod goes and will have release numbers like
    1.2.3, 1.2.4, 1.3.0, 2.0.0, …
  • Scenarios: This is where the .vsav files go. This will only have releases corresponding to minor version increments of the module, e.g., 1.2.0, 1.3.0, 2.0.0.

then you would not need to upload new .vsav files everytime you change minor things in the module, and you would make it clear to users that a .vsav in release 1.3.0 goes with any module in releases 1.3.X but not with modules in say releases 1.2.X.

This is, more or less, how Semantic Versioning (semver) dictates how version numbers should be treated (OK, semver says the major version number should be incremented on breaking changes, but above I argued that we should move that down to the minor version, and leave the major version to signal radical changes to the modules - changes where the user experience changes significantly.)

Yours,
Christian