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

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 numberd on a map image in a VASSAL module. 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 only VASSAL default toolbar buttons and icons for consistency between modules.  Custom toolbar graphics draw the eye away from the maps and counters and create another hurdle in the module learning curve with unfamiliar buttons.

5. Versioning

Modules on this site always start out as 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.
  • Because 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 typcially bare-bones - just map and counters. No charts and tables. No eye-candy toolbar buttons.
  • Some of the modules are experimental, as I explore the capabilities of the software.
  • Most have not been playtested. When they are, it is almost guaranteed that there will need to be edits and addenda.