In the old days, to be a vassal meant that you would agree to submit to a king in exchange for their protection against other kings and lords. We’ve moved past those days; today in the gaming field it means to submit your board game to someone for creating a Vassal module. Since most of the folks who follow this field don’t have much free time (the exception being our fortunate retired chaps), creating online play kits are important to playing. In game development though, this becomes pivotal since you can design an entire virtual game (including graphics) and do all the development work without ever creating any real playtest kits. Once you create a Vassal module, you have unlimited playtest kits.
My introduction to the online gaming world began in 2005 when I had to play Triumph of Chaos and really wanted to do it virtually. At the time, I had only a faint idea what that entailed. After many months of playing around on Cyberboard, in addition to learning a wide range of graphics editing tools, I somehow managed to finish the playkit. Fortunately, I had a good friend on hand to get me going on Photoshop and I developed a skill set for making all the pieces needed for a virtual game. Fast forward 10ish years and 12+ playkits later, Cyberboard is no longer the king – that honor now belongs to Vassal.
I am not going to claim to be any sort of Vassal Master by any stretch. I have to defer the genius trophy to folks like Joel Toppen (so many modules I can’t list them here; his biggest gift is an excellent series of videos for those folks wanting to begin), Rob Doane with his excellent Flying Colors and American Revolution Series modules, and Judd Vance with his current Hands in the Sea module which could be one of the best modules I’ve ever seen. I could go on all day with folks who are better at module creation, and my apology for any Vassalizers I’ve left out. At the end of the day, developers need to either have the module creation skills or have someone on the team who can do the Vassal lifting.
Vassal work is divided into two parts – the creation of all the graphics needed for the module and adding those pieces along with the maps and any player aids to the module itself. For the advanced developer, there’s the whole creating functionality inside the module to aid the play of the game – like deck shuffling, moving pieces around in respond to events, making the maps sensitive to game events and so on. There’s quite a bit of work that can go into a module. For development (and playtesting), these bells and whistles are not quite as important. Nice to have, but the most important consideration is to create the playtest module.
For Bayonets and Tomahawks, I’ve been working on prepping graphics for the upcoming Vassal module. Marc has done excellent (probable printable as-is) graphics, but those still need to be cut up into the images to be used inside of the module. That’s where I come in. For the last month I have been working the graphics into the module pieces. Here is a snapshot of the images as they’ve been developed:
Note that both sides of the counter need to have graphics. Fancier modules could have multiple graphics for different unit states, but in B&T, that’s just not necessary as all counters only have two sides. They just need a front and back graphic for the counters in the module.
Above is a sneak preview of what the images will look like inside of the Vassal module. In Photoshop, you can get a feel for how they will look by using the game map as a base layer and then adding the game piece images on top just to see how it will look. Not too shabby so far.
Next up will be to work all these images into a working module, which is where the project is at this point. I should have a completed module right after Thanksgiving, so with a few weeks of playing with it to make sure everything is correct, the module should be ready for prime time testing right before Christmas. Now that’s when the rubber hits the road – getting serious playtesting underway. Stay tuned for further details.