Moving Season and Year Markers on Main (Common) Map Window (a How-To Guide)

This describes how I got a button to automatically advance a couple markers the main map window that all players can see. Hopefully it will help folks new to Vassal (like me!). It works when I’m testing by myself, so hopefully it will work multi-player on the server, which I intend to test soon.

My game will have 4 years, each composed of the 4 seasons. It starts in Fall of Year 1. I have a button to advance the season one at a time. That took about, oh, six hours to get working. When it moves the marker back to Fall, it should move the Year marker to the next Year. This should all be done visually, and the season and year should be kept track of in some sort variable. Since the games rules are affected by the current season, it should be easy to see which it is, and dragging markers around seems silly to me. Little did I know how much work it would be to get this working (and who knows if this is the “correct” or easiest way to do it).

So how to do this? Click the “Fasten Your Seat Belt” toolbar button and let’s begin. I’ll try to list a lot of the gory details and explain things in a way that makes sense to newbies, but please ask any questions and I’ll try to respond. If more screenshots would help, let me know.

First, I have a board in the main window, and it has a Multi-zoned grid. This allows you to define a bunch of “zones” anywhere on the board. Zones are just shapes, often rectangles. On the board image (which is mostly the same as it would be on a physical game board), I have circles where markers can be placed for each of the season and another set of circles for each year. So I need 8 zones in all.

Next I need to keep track of the season and year. This is done by adding Global Properties to the Module. Year is numeric but season isn’t. I assign initial values to both, and you can assign a limited range to the numeric properties.

Then I need markers on the board. I have some shaded circle image files I made in Illustrator, but use whatever you are comfortable with. Save to a PNG file if you want transparency, which you want for non-rectangular game pieces. Anyway, to add the images to the board, add an At-Start Stack to the Map. I have one for the Season marker, and one for the Year marker. Set the initial locatoin to where the marker should start the game at (would be nice if you could list a zone, but it’s x and y coordinates.
The Stacks holds the actual markers. Stacks can have multiple markers but I just need one in each of the two Stacks. The marker is a game piece, so I add a single game piece to each Stack. One is call Season Marker, and the other is Year Marker.

Each marker has a bunch of traits. The easy one we add first is Basic Piece. This lets you set which image file is used.

OK, all the easy stuff is done. We need a button, and it needs to “tell” the Season Marker to change seasons (remember the Global Properties?), and move the marker to the right place on the board. This takes another 15 or so traits to accomplish, so at this point you may decide it’s not worth it to do what I did. But read on to see how I did it.

First, the button. The way to do this is to add a Global Key Command (called a “GKC”) to your module. I wasted a few hours trying to add an Action Button I think it was. The stuff I added to game piece to do all the work (described below) didn’t get activated. I finally noticed that the reference manual says:

For historical reasons, the term Key Commands is used to refer to Commands that are recognized by GamePiece traits (like Delete) and Hotkeys is used to refer to Commands that are recognized by Vassal components (like Map Windows).

That was my problem, and why I said to use a GKC. Here’s how I defined mine:

The critical part is that when the button is clicked, it sends the “AdvanceToNextSeason” named GKC out to pieces that listen for it. So how do you listen for that GKC? You add a Trigger Trait to you marker. This allows you to listen for a named GKC like I set up in that trait here:

At the bottom of that trait window you can add one or more commands to perform when this trait gets triggered. I call four (for the moment): AdvanceToWinter, AdvanceToSpring, AdvanceTo Summer, and AdvanceToFall. Each of these are their own Trigger Trait. Each performs two commands. One moves the marker, and one changes the Global Property (“GP”) for the season. So for each season that’s two more traits, or eight more in total. I told you this wasn’t easy. But we’re having fun, right?

Let’s get some more detail about these new traits. First, moving the marker. That’s easy. Just use a Send To Location Trait. Here’s the details from one of those windows:

image

Note that I used named commands for everything. The idea of remembering obscure keystrokes to invoke actions is not my thing. To each his own.

Then I need a trait to change the GP storing what season it is. That’s done with a Set Global Property trait. Here’s the main parts of that one:

image

The “fun” part of learning all these traits and stringing together multiple actions is figuring out where you have to put the right command name in each of these different trait windows. The Vassal Designer’s Guide is pretty good, but occasionally you need to check the online manual, and do twenty google searches to find out how things are done.

So are we done? Does anyone see why this doesn’t work? I first added just the “advance to winter” parts. That worked (eventually). I clicked the button and the marker moved! Then, getting cocky, I added the “advance to spring” traits. I started the game over and clicked the button. It went from fall straight to spring with just one button click. It was triggering both sets of traits so first it went to winter, and then on to spring. Sigh.

I’ll post more comments soon showing how I fixed that (hint: a couple more traits for starters), and went on to add the movement of the Year marker too.

OK, I’m back! The problem with the setup above is that, I trigger all the advance season Trigger Actions from the AdvanceToNextSeason one. So it dutifully does one checking if it’s Fall and then advancing to Winter. Then it does one that checs if it’s Winter and advances to Spring. Oops. But then I thought, it runs them in order. I’ll just check in backwards order. But that still does work for some cases. (Run through it in your had for each current season and you’ll see.)

The solution is to keep track of whether during this run of AdvanceToNext Season, I’ve already advanced a season. I do this with yet another Global Property, in this case set up as a Global Property attached to the window, and two new Set Global Property traits on the Season Marker. The property, SeasonAdjusted, is an integer with an initial value of 0, and a range of 0 to 1. One of the traits sets it to 0, the other to 1. Now in the AdvanceTo…[Season] Trigger Actions, I also call the SeasonAdjustedSet. And in the condition check for the AdvanceTo…[Season] Trigger Actions I also check to make sure it’s 0 before I do anything.

Here’s AdvanceToWinter now:

image

So if we haven’t changed seasons yet, and it’s currently Fall, we set the GP to Winter, move the marker to the Winter zone, and mark with the new GP that we’re done. So when AdvanceToSpring gets triggered next, the first part of the property match test will fail and its “Perform these Key Commands” list will not get performed.

We’re done! It works!

Wait … we’re not done. When it goes back to Fall again, it’s another year. More traits! Mostly for the Year Marker. But this is much easier since the Year is a number. We can just increment it when needed with a Set Global Property trait:

The Send To Location trait can use the Year GP to figure out the name of the zone we move the marker to, so we just need one such trait:

image

Finally, you have to have the year advance trait triggered when the season is advanced to Fall. This was the last tricky hour or two of work because a trigger action can only trigger traits in the same piece! So how do we initiate the traits on the year marker? This is done with a Global Key Command trait in the Season marker traits, like this:

image

This “calls” the AdvanceToNextYear trigger action trait in the Year marker. Once again (or maybe I didn’t mention it) but the nice thing about Trigger Actions is they can perform multiple actions, including other Trigger Actions. And each can have its own property match check condition to see if that list of commands should run.

I did add a YearAdjusted 0/1 flag GP and check it and reset and set it, but I don’t think that was necessary since the year is adjusted numerically.

That’s it! Easy, right?

1 Like

Love your season marker. I may borrow it sometime if I want to implement this into Black Swan. Right now I just move the season and year marker manually with a text report saying it was moved. But if I ever want to change that your work here has saved me countless hours thanks. BTW what module is this for? I would like to see this implementation firsthand and perhaps borrow your work if I ever need to add this in.

Thanks! Glad this might save someone some time, or help newbies understand how this all works.

I’m working on a “build a university town” game. Mechanically it has some vague similarities to Stone Age and maybe 7 Wonders. After many, many years of tinkering with the rules on paper and just a tiny bit of solo playtesting, I finally want to test with others. For the time being that will just be with a couple local board game friends. But I could probably make a copy of the module with just this stuff in it and post that when I have time.

1 Like

Also meant to add that I added a lot more to the original posting above.

1 Like