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 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 impractical due to the amount of time required to edit the image in GIMP. But a few of my modules do use scanned maps with hex numbering erased.

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).

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 upon 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 - rdma, rdmb, rdmc, etc - (although the filename will remain unchanged). The relevant information will always be the internal "version" property, as listed in Module Manager.

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.