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.
- Stock toolbar buttons and icons.
- No charts and tables.
- Credit the source when borrowing graphics.
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 a hex grid overlay and provide hex ID on mouse-over, even on empty hexes. Numbering of every hex is unnecessary in vassal, and removing hex numbers improves appearance. It is time-consuming due to the having to edit each separate hex in a graphics program.
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'm not a fan of corner rounding or edge beveling.
If the boardgame has status markers for units, these can almost always be incorporated as game-piece layers. 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, 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 charts and tables as originally published is preferable to reading them on screen, where they cover much of the board. 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.
Not needed. Just refer to the date and time stamp of the vmod file.
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 "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?
- I want to create modules for games by SPI, which is a banned publisher according to the vassalengine wiki. (Update, December 2020: vassalengine.org module repository is now accepting most SPI and Decision Games titles.)
- 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 playtested.