I am designing a module for a game that requires differing setups depending on the number of players. One set up parameter is the random allocation of four particular cards into four “sub-decks” and then the combining of these decks into a main deck so that the cards will be drawn at variable times within each quarter of the main deck.
I plan to allow the participants to choose a scenario based on the number of players (2 - 5) each with its own setup contained in a .vsav file. Obviously, the forming of the main deck will take place after each scenario has started to maintain randomness of the deck’s card order from game to game.
However, I can not work out how to achieve this. Can anyone help?
Pax Pamir 2nd edition must do something similar to the setup that you describe.
One approach would include these elements:
-
Define the four cards in their own deck, on a hidden map. In the example below this is called “setupDeck”. Make sure that this deck’s “Reshuffle” option is set to Always - this will make the card distribution random.
-
On each of these four cards, have a Return to Deck trait. Within that trait, it’s possible to compute the target Deck name. I suggest basing it on the number of cards remaining in “setupDeck”. Then you can target each deck in order, by defined a set of Global Properties holding the names of your target decks. e.g. Here those decks are named in GPs gameDeck1 - gameDeck4:
In fact, if your sub-decks are just for setup, you can do away with the Global Properties idea and just call those an internal name in the form subdeck1 - subdeck4. in which case, replace the Deck Name formula with subDeck$numPieces_setupDeck$ (no curly brackets).
-
The final controlling component is a Global Key Command which could be a Startup GKC, as in this example:
Another approach - used by Pax Pamir 2nd ed - would be make the setup part of a process that the user explicitly starts, rather than automatic. This is suitable if there setup options such as player count to take into account.
Hope this helps.
Thanks, Mark. I shall be entering uncharted territory with this approach. I’ve designed a few modules up till now but haven’t encountered the need for Global Properties or Hidden Maps. I’ll take a plunge and see where it all leads. Can I pick your brains further if necessary?
I won’t go the Pax Pamir route right now - in the past, I’ve tried using the work of others and got hopelessly lost in the process 
Mike
I’m happy to answer further questions and others will too, I’m sure.
I’ve just realised that another implication of you wanting to combine four decks into one. I think that you will need to keep those four decks separate, as my understanding is that Vassal performs randomization at the moment of drawing the card, not when the cards are moved into the deck. Decks have a “when empty” hotkey that you could exploit to trigger the next setup deck to move onto the main draw deck.
Not to complicate things unnecessarily, you could design your module such that the players do these set up actions, if you prefer. I expect you considered this already but I don’t want to give the wrong impression.
I have decided to follow your suggestion about the the players doing the set up actions. I don’t think I have the dexterity with Vassal to adopt the other methods but the players have to cope with setting up the board game, so why not the module?
Thanks for your help.
2 Likes
YES YES YES!
As long as you provide visible instructions to guide them along, this is an absolutely OK approach.
1 Like
My basic design philosophy is to provide the board game from within Vassal. The more bells and whistles added on, the more explanation is required and I seldom find the necessary information coming with the games I download. I certainly plan to include a users guide for the setup and an overall “this is what you do in the module to achieve this effect frim the game rules” so, hopefully I’ll end up with something that plays like the board game.
1 Like
