I make VASSAL modules for my own use and because it gives me a creative outlet to occupy my leisure time. So the intended audience for this blog is mainly just me, although I am happy if others find the articles and the modules of interest.
Some modules on this site are simple - the results of the module-design learning process. Others are more complex as my facility with the software improves.
In creating a module, my aim 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 is necessary beyond the map and counters.
- No charts and tables. Less mod bloat, and players will have paper copies of these, which are more readable than scans on screen.
- Credit the source when borrowing graphics.
Use a clean scan of the printed map where available. Make a custom map if there is no good scan available (or just abandon the module until there is a good scan: I made an exception with Operation Jubilee).
If the map has hexes, include a hex grid overlay and provide hex ID 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, but it is seen as essential in printed games as a setup aid. But setups in VASSAL are done with at-start stacks and vsav files, so printed hex numbering is not needed, and removing them improves the appearance of the map.
Erasing hex numbers from a scanned map is time-consuming due to the having to edit each separate hex in GIMP. But whenever practical, my vmods maps will be free of hex numbering.
It is common for a printed map to have the majority of its location text (and hex numbering) 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 one's head. This sometimes means that "north" is not toward the top of the screen. Terrain keys and turn tracks may need to be reoriented (in an image editor) to conform to this "right side up" requirement.
I seldom use scanned images of original counters, opting instead for VASSAL Game-Piece Image Definitions. This yields uniform game-piece sizes, edge rendering, and color, as well as better scalability when changing the zoom factor. Even when using scans of the counters, I would incorporate them in to a Game-Piece layout as an image component (centered within the layout) and use VASSAL's native game-piece borders for 3D effect. I'm not a fan of corner rounding or accentuated edge beveling.
If the boardgame has status markers for units, these should almost always be incorporated as game-piece layers in the module. 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. This is a personal preference due to my own low vision condition (retina detachment and repair). 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 published 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 for consistency between modules. Button text is not usually necessary as long as mouse-over text is available. It is fairly common to see modules with custom toolbar buttons that seem to be aiming for a thematic feel. This is not necessary for boiler-plate components.
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. Version numbering in software is wholly subjective. What does each digit of a version number represents? How much of a change to the product requires a new version number? Which digit gets changed?
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.