“Talon Tuesdays” is an article series appearing on InsideGMT periodically on Tuesdays.  It features articles from the Talon development team regarding the game’s design, development and release of the Talon 1000 expansion. Since Space Empires:4x Replicators is also releasing soon and there is crossover between the two development teams, Replicator articles will be featured as well.

Issue #46 Vassal Update for Talon – Stefano Tinè

The Making of Talon/Talon 1000 Vassal Module

It all started back in February of 2016, when Talon first came out and people started asking on the BGG forum if a Vassal module for Talon was in the making.

Bob Seifert, the game developer for Talon and tireless creator of many Talon Tuesday’s reports on the InsideGMT blog, answered that it seemed impossible to render the complex overlapping of counters (e.g. reinforced shields, damage and jury rigged tokens) in fixed positions over other counters (=the ships themselves) in the current Vassal framework. The problem being compounded by the need to rotate the ships, and write on them, while preserving all counters in the proper position.

Enter myself, Stefano, who was at the time surfing the BGG forum and was intrigued by this new game (blame it on BGG’s Hotness List, I guess) and could not keep my mouth shut and had to chime in saying something like “it should be doable”.

This proved the start of a long a proficuous partnership with Bob to get this actually done. Needless to say, I had underestimated the game’s peculiar requirements but I had a reputation to keep (with my cat, at least, used to my long sitting session at the PC, time wasting on Complex Useless Projects™) and there was no giving up.

What I find interesting in a Vassal project (or any type of project which is interesting, perhaps) is when you can’t just limit yourself to simple straightforward applications of a few basic processes, but there are actually things, procedures or tricks you need to invent ex novo. Not as a sterile exercise, but as an actual conditio sine qua non. And this project, as I will relate shortly, sure required a lot of new (or less new) ideas and solutions to be implemented.

The very first thing that needed finding a novel way around was just the original sin mentioned above, i.e. how to render all the overlapping parts in a proper (and properly rotating) way. We experimented with having all those extra tokens (for reinforced shields and the like) be freely place-able on top of ships, like in real life. This might seem the obvious solution, and it’s definitively the preferred one, when feasible, because it makes the Vassal implementation just like the real life game and everybody is immediately comfortable with that. But how to make ship rotate properly, dragging along all pieces at the same time? A reinforced front shield showing “A”, for example, will not rotate properly if you rotate the underlying ship (“rotate” is a standard Vassal command). In fact, it will just stay fixed where it was.

Therefore, you would want triggers (another standard Vassal feature) to fire automatic movement of those tokens in the right position when the ship they belong to is rotated. But then the “A” would not rotate properly, always looking vertical, like it is written in this text. So, unless you are happy with having those counters always look vertical and then partially overlap underlying ship features, you would need to automatically send it to the right x,y coordinates and rotate it as well (in multiples of 60°, like the ship counters). With Vassal 3.2.0 you can actually calculate things on the fly, but this seemed too much of a complex calculation to force it to, implying lots of IF statements and the like.

Moreover, how to render all those “pips” which you are supposed to black out when charging a weapon or damaging the hull or a shield? Perhaps we could implement tons of hot spots (called Action Buttons in Vassal), one for each pip for all ship types. So that by clicking on the spot a player would turn on/off the blacking out of the pip. Neat. But keeping in mind that defining an hot spot means giving x,y coordinates plus width-height of each area.. for each ship type… this was never going to be feasible.

Therefore, enter Layers. This is a Vassal feature where you just add images to a piece (in our case the ship counters themselves) and it goes on top of it. It can be of the same size, with transparent parts perhaps, or it can be of another size, smaller perhaps, and perhaps be offset as you wish. Keeping in mind the need to rotate things properly, we went for layers of the same size of the ship hexagon. One layer for each feature. Consider a ship Hull pips, for example. The given ship type (Terran DD for example) has a Hull layer with multiple levels/images: each image is of the same size of the ship counter and is completely transparent except for 1 black pip black, 2 black pips etc. Bob volunteered the ungrateful task of providing the tons of images needed for each ship feature with pips and each ship type. I am glad he did because I can’t figure out an image manipulation program if my life depended on it.

We adopted this same solution to render all counters such as Reinforced Shield, Side Slip, Initiative, Destroyed Weapon, Jury Rigged Weapons etc. They are just layers turned on/off as needed.

The end of this part of the story is that each ship you see in the Vassal main map is made by a single counter with a dozen overlapping layers (hull, shields, reinforced shields etc). As it turns out, this can make all but the fastest systems take some time to first render a ship when it enters the main map. Especially charging up all weapons when a ship first enters play is slow. It seems to double rendering times (this is due to the “charging” having the need to use the same Vassal command used for the “erasing”, i.e. depleting the weapon completely, and thus the need to run If statements).

This was and is the most annoying feature of this module: it is laggy, especially on older systems. We don’t like it, we wish we could avoid it and, believe me, we tried lots of alternative ways (not discussed here) but in the end this is the best we could up with. (And I challenge anyone to come up with better/faster solutions in the current Vassal framework!)

Moving on, there was then the need to setup all those default scenarios included in the base game. There is something called Predefined Setup in Vassal, where a module designer just starts a game, moves counters in places as required, saves the game like “Scenario #3” or something and then adds it as a predefined setup to the module. Then players will find it in the Vassal File->New Game menu.

However, this is never recommended for module designers, except for the most basic games/modules, imho. This is because if you later need to make any single change to the module (a bug fix, a new feature, an expansion) in 98% of the case you will need to rebuild the predefined setup again. Much better to put in place lots of At Start Stacks (the most basic Vassal command which just places a piece in some fixed position of your choosing) and lots of automation to move/replace/clone those around as needed. This is lots more work, surely, but work you don’t need to redo every time you realize you had forgotten a quote or a comma in a statement/command elsewhere.

In this module, loading all those Scenarios can take a long time. It might appear the game/Vassal is frozen. But don’t despair.. This is only a consequence of needing to place multiple ships on the map, with weapons fully charged etc, and the lag mentioned above increases accordingly.

Finally, there was the other complex issue (but fun.. yeah, I guess I should get out more often) of dealing with the whole Empire War situation. To start with, as I designed it in the module, this implies asking players to pick a faction. Why not ask them to pick Terran or Talon when starting a new game? After all most Vassal modules do that, i.e. ask you to pick a Side when starting a new game, especially if the game has hidden information (e.g. private hands of cards or, here, fleet composition/distribution).

But keep in mind one might want to play Talon solitaire (as it turns out now that Talon 1000 is out) or multiplayer solitaire. Other modules resolve that adding a “solitaire” player to the list of player “Sides” one has to choose from when starting a new game. However, that also implies adding logic in the module to distinguish when thing can be seen (proper player side or solitaire) or should not be seen (opponent’s side in non solitaire).

Therefore, as in other modules I have made, I thought easiest to avoid asking to pick a specific side at game start. After all, in a Custom scenario, since ships come in play from the piece palette face down (masked in Vassal jargon), only the player who placed them on the map will be able to peek at them and reveal them, becoming automatically the owner of that ship (and thus that Side, unless one wants to experiment mixed Terran/Talon fleets..)

Then, for Empire War, I can’t avoid having to know who is playing what, so to make their EW fleet composition, treasury and such visible to him/her exclusively. Therefore, in Talon’s Empire War you are asked to pick side, then place your free couple of bases and finally reveal them (you are supposed to reveal them only after the opponent has also agreed to do so). This gives you ownership/visibility of your dedicated EW fleet window. Incidentally, for Talon 1000 you don’t get to place bases, as you get a couple bases and starbases in fixed positions already, so you get to skip the place bases/reveal bases step.

Now enter the EW fleet windows. Here I designed it so that you get like a spreadsheet with each row being a galactic Sector and each column a ship type (or class, in Talon 1000). You drag and drop ships from the palette to here to build your EW fleet. Things like treasury, ship points and logistic points are all traced. But you don’t want/need to have full fledged “ships” counters here, I mean with all right click menu functionalities like Shields, Weapons etc. Unfortunately, there is currently no way to hide sub-menus in Vassal (like the Weapons sub menu). Moreover, ships enter/leave EW fully charged, maintaining only destroyed weapon status (destroyed or not). Therefore, every time you drag and drop a ship to the EW window (or, for similar reasons, to the Casualties window) it actually converts to a kind of simplified ship surrogate counter with only needed functionalities implemented. When you drag it back to the main map (send it to war) it will convert to a full fledged (and laggy..) ship.

Players would then reveal their fleet for a given sector and logic had to be put in place to send fleets back after battle with proper weapon destroyed status to the proper fleet window, appropriately hidden from the opponent. You can understand implementing all the EW logic and, especially (due to current Vassal idiosyncrasies), properly implementing the drag/drop/convert/move in place/reject illegal ships mechanisms was no easy or quick task.

Last but not least, Talon 1000 introduced AI ships, which are never masked don’t need to specify an owner (a solo player is supposed to use them, anyway) and thus don’t need to have a hidden fleet window.

It also introduced its own EW map. Originally with Bob we thought having a Talon 1000 extension to the existing Talon module was the way to go. That’s why we have separate Terran/Talon (and AI) fleet windows for the two EW maps (base vs 1000). There was no way to share the same fleet windows (and EW Mat window) without having to change things in the main module.

But as often happen in this type of work, it turned out later that to properly implement the AI stuff as well as the new EW mat some little updates were needed to the main module itself. We wanted to touch the main module anyway, to fix a couple minor bugs we noticed, so we ended up having to update it to a new version (1.1 at time of writing) that you find now on the GMT (in the “Online Resources” section of the Talon and Talon 1000 game pages) and Vassal websites, together with the extension for Talon 1000 (1.0 at time of writing). In retrospect, having had to change the main module itself, I guess I could have made the Talon/Terran/AI/Mat windows for EW be a single copy (and not separate copy for Base vs 1000) but this seemed like a complete waste of time. After all.. some hard core Talon players out there might want to play a huge campaign spawning both EW maps, each with their own fleet, at the same time!

Hey, this was a long journey. I have made other Vassal modules, each with their share of complexities and innovative solutions I had to come up with (and I am proud of.. one takes his joys were he can..), but this was definitively the one with the longest list of difficult puzzles to solve and the most hours spent working on. Thanks a lot to Jim for creating the game and expansion, to GMT for sending me a free copy of the game and expansion (at perhaps 0.02$/hour this turned profitable indeed … :-)))) and above all a big thanks from me and the thousands of Talon/Vassal players out there to Bob Seifert for his outstanding and patient work helping me out with all the painstaking image processing and creation, testing, gameplay explanations and awesome video tutorials.

P.S. Then there were missiles and the need to track them. This was fun. I wish I remember how we did it, perhaps Bob remembers it. Or should anybody have survived reading this bore till here and would want to know.. please do say so and I can dig it out.

Bob here, I second everything Stefano said above and I challenge anybody to do a better job implementing and automating features in the Vassal engine. I also don’t recall exactly how Missiles work in Vassal but they do track targets and are even aware when a target is destroyed! You didn’t mention a really cool feature you added which is the ships actually display their SP value right in the piece pallet. So whether you’re setting up a regular match or in EW you can easily see the cost of a unit. Smart!

I hope people that work on Vassal or want to put their game on Vassal find this article useful. I know I’ve stolen borrowed a lot of mechanics Stefano has used for my long-overdue overhaul to the Space Empires 4x module. Stefano, I’m pretty sure I owe you a beer or two. Thanks again!

---

Previous Article in the Series: Replicator Tuesday Issue #45: After Action Report

Next Article in the Series: Replicator Tuesday Issue #47: Vassal Update for Space Empires