In creating a VASSAL module, the goal is not to copy every component of the boardgame and implement it in exactly the same way. I start with the Best Practices chapter of the VASSAL 3.1 Designers Guide. The big three are:
- Don't Try to Enforce the Rules
- Limit Automation
- Leverage Programmatic Efficiencies
To these I add:
- The primary focus of a module should be the map and counters.
- Use only stock toolbar buttons and icons (no thematic bling)
- No charts and tables.
- Credit the source when re-using graphics.
Use a clean scan of the printed map. Make a custom map if there is no good scan available (or just abandon the module until there is).
If the map has a hex grid, include a hex overlay and provide hex identification on mouse-over (even on empty hexes).
There is no need for individual hex numbers on a map image in VASSAL. Numbering of every hex is information overload/text clutter - which helps in the printed game as a setup aid, but is unnecessary in VASSAL, given that the mouse-over stack viewer can provide this information. At-start stacks and vsav files are available for setups. Removing hex numbers from a scanned map is time-consuming due to the having to edit each separate hex in GIMP. But where practical, I would opt to use scanned maps with hex numbers erased.
Sometimes a map just needs to be built from scratch because scanning a mounted board is impractical. For example, Avalon Hill Bull Run.
Use VASSAL's Game-Piece Image Definitions where possible. This yields consistent game-piece size, edge rendering, and color; better legibility when zooming out. Even when using scans of the counters, incorporate them in to a Game-Piece layout as an image component (centered within the layout).
If the boardgame has status markers for units, these should be game-piece layers in VASSAL. A perfect example of this is the GCACW series games, such as Roads to Gettysburg which has markers for strength, fatigue, demoralization, entrenchment, out of supply/ammo.
3. Rules, Charts and Tables
The player is expected to have access to the printed rules, charts, and tables. Exceptions are (1) where a table or chart appears only on the published game map, or (2) when the paper version can be improved as a VASSAL component.
4. Toolbar Icons
Use VASSAL default toolbar buttons and icons for consistency between modules. If custom icons are to be used, they should be no larger than 30 x 30 pixels. Button text is not usually necessary as long as mouse-over text is available.
Modules on this site are all version "rdm" and include these three letters in the file name. Further versions of a module may append a letter in alphabetical sequence - such as rdm-b.
6. Scenario setups
Why Not Post to the VASSAL Website?
- I'm building modules for my own use, not trying make a definitive or authorized version. This site simply offers them as alternatives and explains why I made them as they are.
- My modules are always subject to being tweaked, it is easier for me to just upload a replacement file to my own file host.
- There is no obvious method for deleting a module from the VASSAL website. There is no reason to retain old versions of modules after bugs have been fixed.
- I want to create modules for games by SPI, which is a banned publisher according to the vassalengine wiki.
- My modules are usually bare-bones, mainly just map and counters. No charts and tables.
- Some of the modules are experimental, as I explore the capabilities of the software.
- Many have not been playtested. When they are, it is almost guaranteed that there will need to be edits.