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.

1. Map

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.

2. Counters

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.

5. Versioning

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

These are provided as separate vsav files via the load game menu item, instead of being imported as pre-defined setups. Modules get tweaked a lot, so having to re-do scenario setups gets tiresome. At-start stacks are preferred where the initial setup is constant.

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.