This page is for module designers who need tips on reducing the size of their modules. Some of the tips can have a dramatic effect, others less so. Maps typically make up the largest part of any module, followed by Rule tables and Charts. Small decreases in counter size can have a major effect in large modules that might contain thousands of counter images. Predefined Setups can also take up significant space within a module and some techniques can be applied to manage this.
First things first
The module file might have a name ending with .vmod. However, to manipulate your module as a zip file, you might have to change its extension (at least in Windows).
Remove old versions of images
As you build up your module, you copy additional images into the ‘images’ sub-folder within your module zip file. If you change the name of any images, the old versions of those images will not be deleted unless you specifically delete them.
You can remove unused images in the Editor. Select “Remove Unused Images” from the Tools menu. Be sure to make a backup copy of your module before using the Removed Unused Images tool.
Benefit can be large, especially if there are a couple of copies of old maps still in the module!
Optimize your PNG images
Most programs which write PNG images do not write them with the smallest file size possible. Run a PNG optimizer (e.g., optipng) on your PNG images to reduce their file size without altering their image content.
PNG optimizers remove alpha channels from images which have no transparency, reduce the bit depth of images which use few colors, and recompress the image data tighter, resulting in smaller PNG files which are still equivalent to the orignals.
Benefit is often large.
Re-zip your module
Modules are ZIP archives. If files in your module were not compressed with maximum compression, you might be able to reduce the size of your module by recompressing on a higher compression setting.
Unzip your module and rezip it using a ZIP program such as 7zip, and select the highest compression level available.
Benefit small to medium, but likely very little if you have already optimized your PNG images.
Image Color Depth
Bitmap images reserve a particular number of bits for each color channel (and possibly also for the alpha channel, used for transparency) for each pixel. The number of bits per pixel determines how many colors can be represented in an image. Typical PNG images these days are 24 bits per pixel for the colors (8 bits each for red, green, and blue) and optionally 8 bits for transparency.
You can dramatically reduce the file size of an image by reducing the color depth to 8 bits per pixel, but the tradeoff is that at 8 bits per pixel, your image may contain at most 256 colors—far, far less than the 16.7 million colors you can have at 24 bits per pixel.
Reducing the color depth of an image which has more than 256 colors in it to only 256 colors will typically make it look like garbage and we strongly recommend against doing this. No one will thank you for making the game map look bad in order to shave a few megabytes off your module.
However, if your image already has 256 colors or fewer in it, running it through a PNG optimizer can reduce the color depth without removing any colors, which will reduce the file size at no cost to appearance. We recommend letting a PNG optimizer do this work for you rather than manually modifying the bit depth of your images.
Remove redundant Predefined Setups
For modules containing PreDefined Setups, it is worthwhile to ensure that no orphan files exist within the module. A module may contain Predefined Setup files that are no longer used (presumably overridden at some point with a differently named file). Such files can be detected within the uncompressed zip file after a Predefined Setups Refresh (Editor Tools menu). They will have an earlier timestamp than the most recent Refresh. It’s even possible that a vmod file has been accidently included by some erroneous maintenance. Once this simple check has been done, recompress the module.
If each Predefined Setup file is particularly large due to the pieces that it contains, there are two module design techniques that can reduce initial game file size and, therefore, module size dramatically. Both of these are applied in the Editor, changing how the module is initialised. These are described below.
Scalable Vector Graphics (SVGs)
SVG files are text files and take up considerably less space than bit-map formats. They are preferred by some module designers as images can be scaled to any size without negatively impacting their quality. They take extra effort to produce unless you have access to original graphics files in that format.
One particular area that is practical for all designers is to use SVG for simple outlines such as required by the Non-Rectangular trait. Suitable outlines can be generated using a tool such as Inkscape. You can also use AI tools to generate very simple shapes to help you get started. The Non-Rectangular trait, when used with bitmap images, may demand significant space because, unlike all other image references in the Vassal module, the image for this trait is embedded directly into each game file. Module size will reduce in proportion to the number of Predefined Setups and the number of pieces using such converted traits. Furthermore, you may notice a reduction in the size of log files.
At-Start-Stacks & Decks
At-Start Stacks or, more typically, Decks may demand considerable space within a Game File, if the pieces concerned have a long trait list. Rather than having such pieces setup within the Predefined Setup file, you may instead devise a setup routine so that the pieces are not deployed until a game is started. As an additional benefit, if a module is set up in this way, it is very easy to apply changes to At-Start-Stacks or Decks. For example, to add a new deck as an option for game setup.
This is method requires a little care and effort to implement and will only deliver significant reductions for the most feature-rich modules with at least 10s of Predefined Setup files. By way of example, applying this technique to such a module with 210 cards in each of 190 files reduced module size from 300 Mb to 145 Mb. As with most of the other techniques, it will not reduce the size of an in-progress game or log file.
The core of the method is to place the individual pieces at their starting locations from a control piece, using the Place Marker trait. For identical pieces, this should be done within a Trigger Action loop. Such identical pieces will share the same PieceId. If your module uses the PieceId property to identify unique pieces then you will need to convert it to use UniqueId instead.
The setup routine may be triggered automatically using a Startup Global Key Command or by a user action. In both cases, the module setup must ensure that the setup routine only runs once.
Helper Pieces
A module may have common features across many pieces. For this kind of module, you may see a size reduction in Predefined Setup files and log files by consolidating those features into a helper piece. Using the ability of Global Key Commands to pass data and the Attachment trait from the helper piece, you will be able to provide services to the client pieces without adding additional traits to the pieces, beyond setting up the GKC action. Reporting would be a typical such service. Direct the GKC to the specific location for helper piece to limit the performance overhead of this technique.
This technique will only generate a size reduction if you are able to offload several large traits across many pieces to one or more helper pieces. In terms of module size, this saving will multiply up by the the number of Predefined Setup files.