See also: List of my modules

I make VASSAL modules for my own use, typically including only those images and features that are necessary for my own on-screen game-play. My aim is not to copy every component of the boardgame and implement it in exactly the same way. I start with a few Best Practices from the VASSAL Designers Guide:

  • Don't Try to Enforce the Rules
  • Limit Automation
  • Leverage Programmatic Efficiencies

To these I add:

  • Focus on the map and counters.
  • Use stock toolbar buttons and icons.
  • No charts and tables.
  • Credit the source when borrowing graphics.

1. Map

Use a clean scan of the printed map where available. Make a custom map if there is no suitable scan available.

It is common for a printed map to have the majority of its location text facing one way, while the game logo, turn track, and terrain key face different directions (i.e. two copies of the CRT, with one facing each player). Maps in VASSAL should be oriented (or modified) so that all text is readable on the computer screen without having to tilt the head. This sometimes means that "north" is not at the top of the screen. Terrain keys and turn tracks may need to be reoriented to conform to this "right side up" requirement.

If the map has hexes, include an invisible hex grid overlay and always provide hex ID on mouse-over, even on empty hexes. Hex numbering is unnecessary in vassal, and removing hex numbers improves appearance.

Sometimes a VASSAL map just has to be built from scratch because scanning a mounted board is impractical or the published map is faulty. Two examples: Bull Run and Light Division.

2. Counters

I seldom use scanned images of original counters, opting instead for VASSAL Game-Piece Images. This yields uniform game-piece sizes, edge rendering, and color, as well as better scalability when changing the zoom factor. I do not use corner rounding or edge beveling.

If the boardgame has status markers for unit properties, these can almost always be incorporated as game-piece layers. A perfect example of this is the GCACW series games, such as Stonewall Jackson's Way which has markers for strength, fatigue, demoralization, entrenchment, out of supply, and out of ammo. There is no reason to import counter clutter into a module.

3. Rules, Charts and Tables

The player is expected to have access to the printed rules, charts, and tables. Reading paper charts and tables is preferable to reading them on screen, where they cover much of the board while open. Exceptions are (1) where a table or chart appears only on the printed game map, or (2) when the paper version can be improved as a VASSAL component.

4. Toolbar Icons

I use VASSAL default toolbar buttons and icons. Button text is not usually necessary as long as mouse-over text is shown. It is fairly common to see modules with oversized, custom toolbar buttons that seem to be aiming for a thematic feel. This is not necessary for boiler-plate functions.

5. Versioning

I don't use version numbers. Just refer to the date and time stamp of the vmod file.

6. Scenario setups

These are sometimes provided as separate vsav files via the load game menu item, instead of being embedded as pre-defined setups. My modules get tweaked a lot, so having to re-do embedded scenario setups gets tiresome. At-start stacks are preferred because game-piece changes are automatically applied to at-start stacks (but not to saved game files).

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 "show and tell" 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. Why keep older versions of modules after bugs have been fixed or improvements made?
  • My modules are usually bare-bones, mainly just map and counters. No charts and tables.
  • Some of my modules are rudimentary or experimental, as I learn the capabilities of the software. Most need playtesting.

If you use any of these modules, I would appreciate suggestions for improvement and bug fixes (as with Solomon's Campaign).