Sides in Vassal 4

Development
1

Hi All,

Here’s some food for thought and discussion.

Problems with Sides in Vassal 3

  • They are fixed within the module and cannot (easily) be varied between scenarios. They can be ‘hidden’ (by logging in to them), but cannot be created.
  • You can’t (easily) close empty seats to prevent unwanted players jumping in the game.
  • Unless the module designer has specifically designed options for Solitaire play into the module, it is not easy to play both sides.

There are workarounds for these issues, but it is a total PITA.

Proposed Solution
Separate Seats from Sides.

What is a Side
A Side is what we generally think of as the opponents in a game. Sides are named Positions in a game.

Sides often have specific Game Assets allocated to them that they have privileged access to, such as private or public windows for their own use, or Game Pieces that only they can use.

Sides can also be much more generic where there are no specific Game Assets allocated to them. For example, in many card games everyone uses the same cards and counters, there no player specific cards. Sides in this sort game tend to be much more generic. E.g. ‘Black, White, Red, Blue’ or ‘Player 1, Player 2, Player 3…’. Sides in this sort of game often require some Generic Assets that are exactly the same for every Side. For example, every Side in a card game probably needs a Private Window to hold their cards. Apart from access, every Sides Generic Assets are identical.

What is a Seat
A Seat is a position at the Vassal virtual table.

In Vassal 3, a Seat and a Side are the same thing. When you select a Side at the start of a Game, you are given one Seat with ‘ownership’ over that Side.

In Vassal 4, I propose that we split these two concepts completely. At the start of a Vassal 4 game, you will take an available Seat which will give you access to one or more Sides.

A player in Seat attached to multiple Sides would still only be able to play one Side at a time, but they would be able to change to a different Side simply by selecting the alternate side from a drop-down menu (or similar).

What might this look like for the Module Designer?
The Module Designer would still define the Sides in a roster much like they do now. Axis & Allies will still require two sides created, ‘Axis’ & ‘Allies’. If the game supports Moderated play, you might also define a ‘Moderator’ Side that has specific private Game Assets to support moderation. Game Assets will still have access limited to them based on Side.

The module Designer would then create a separate Roster of Seats available for the module, and what Sides those Seats have access to. This might be:

  • An Axis Seat that has access to the Axis Side.
  • An Allies Seat that has access to the Allies Side.
  • A Solitaire Seat that has access to both the Axis and Allies Sides.
  • A Moderator Seat that has access to both the Axis & Allies side and the Moderator Side.

NOTE that not every game will provide every type of Seat, or provide access to every Side.

How would Seats get allocated to Games/Scenarios?
When creating a new game or scenario, one of the setup tasks will be to select how many of each type of Seat are allocated for that scenario. For example, using the A&A Seats defined above:

  • A standard 2 player game would get 1 Axis Seat and 1 Allied Seat allocated.
  • A 4 player game would get 2 Axis Seats and 2 Allied Seats allocated.
  • A Solitaire game would get 1 Solitaire Seat allocated.
  • A moderated 2 player game would get 1 Axis Seat, 1 Allied Seat and 1 Moderator Seat.

What would a player joining a game see?
When joining a game, a Player will be presented with a screen showing the full list of Seats allocated to this game, which Sides those Seats control, which Seats are already take by Players (and who they are) and which Seats are available to be taken.

Full information at this point is important - Don’t join a game which has a Seat taken by someone who has access to both Sides!!!

We should probably display prominent warnings where we detect this sort of setup. This would be valid in a Moderated game for instance, but the players should be warned.

What about Observers?
Observers do not take a Seat and can have no interaction with the game, except to chat.

Seats should be (somewhat) Dynamic
It should be possible open new Seats and close Unused Seats during play in a controlled way.

Need to discuss limits and controls on this, but I envisage something like the following.

  1. A Scenario is defined to allow up to 8 Generic Seats in a card game. The game works with a minimum of 4 players, so after 4 players have joined, all players agree to start the game and the remaining 4 seats are closed. [mechanism? How would it work in PBM? By Agreement, or give person who created the game control ? Similar to online room control]

  2. 3 Players want to play an A&A game that only has a 2 player and a 4 player (2 a side) startups defined. They start the 4 player game, 2 players take the Axis Seats and 1 the first Allies Seat. The player all agree to close of the 4th Seat and start the game.

  3. A Player would like a friend to help him play his Side in a large war game. He creates a Subsidiary Seat that is a copy of his own Seat and his friend joins the game, takes that Subsidiary Seat and has full access to the Sides allocate the original Seat. I would envisage that:

  • A Subsidiary Seat cannot create further Subsidiary Seats.
  • A Player may only create a Subsidiary Seat of their own Seat.
  • A Player who has created a Subsidiary Seat would retain the right to arbitrarily boot the Subsidiary Player and delete the Subsidiary Seat.
  • He may require agreement from the other players to be allowed to create a Subsidiary Seat.

What did you mean by Generic Assets?
A Generic Asset is a standard Game Asset like a Private or Public window that has been defined by the Module Designer to be Generic Asset. [Possibly just a Tick Box in the Asset definition]

Generic Assets are automatically created and assigned to a Player when that Player takes a Seat.

Generic Assets only need to be defined once. Each Player will get their own copy.

2

Ooh! Ooh! A question I actually have a professional background in! (Multiplayer videogames)

You’re well down the right track, in separating seats from sides. HOWEVER: so far your proposal implies that seats are still mostly under the control of and dealt with by the module designer (and that module design, properly conceived, involves maybe needing to think about seats). And of course we’re already aware of the subtle downsides of that sort of thing – e.g. “help how do I play solitaire” posts from people playing modules where the designer didn’t think/know to provide support.

So here is a suggestion for a slight revision in thinking:

  • SIDES are defined and owned by the Module Designer (Axis, Allies, Romans, French, etc). They relate to things integral to the boardgame design and therefore necessarily part of the module design.
  • SEATS are defined by Vassal itself and are controlled by the player who starts the game (“the host”), whether the game is a PBEM or a Server game. Most of the decisions about SEATS turn out to be better made by the players in the game session, and the interfaces for them are better designed once at a Vassal level, as they are substantially general cases.

So from the point of view of SEATS, here are some important details:

  • Overarching principle is that it’s the “Host” (owner of the game session) who controls everything about SEATS - how many are available, who can join them, who gets booted from them.
  • The “host” (again, for PBEM this is just the player launching the game) controls how many seats are “open” and “closed”. If he only opens one other player seat, then it will stay a 1v1 game even if it’s a game that supports 4 players.
  • Host controls IF any observer seats are open (it can default to some number, or zero, depending on Vassal’s choices).
  • Host controls IF a moderator/referee seat exists for the session (whether or not the module has any “special support” for it - for example a module might offer support for such a thing, but the host can lock it out because they don’t want some rando jumping in as referee in their private 1v1 game.
  • It might initially sound bizarre, but this model of course supports allowing more than 1 player to join the same Side – basically a “co-op” session. It’s not the most common use case, but it can actually be pretty fun (think of all the times you’ve had one extra player for a 4-player boardgame, and one person says “here me and Fred will just play red together” and then they have a great time). Plus it’s also a great “teaching mode”. Again, since it’s the “host” who controls the number of seats, this leaves the right decisions in the hands of the players – I guess this is what you’re calling “Subsidiary Seats” and you could provide a host checkbox whether multiple players on a side is allowed in this game (I’d also recommend calling them “Co-op Seats”, probably more familiar terminology to gamers). I’m not sure you need to give individual players ownership of these seats (e.g. who can boot a player) - it is simpler and works well to just let the host (owner of the game session) have the boot power if anyone is going to.
  • In our games we also often provided a setting, visible to all players at start, where the host could either leave certain of these types of game settings “open” (meaning they were flexible to be changed later during the game), or “locked” (meaning once the game starts even the host isn’t allowed to change them). Because sometimes players are friendly/informal and want flexibility, and other times they’re in a competition want to be guaranteed that they don’t have to keep an eye on whether game settings somehow got changed later on.

So this leads back to some potential thinking about special-case Sides:

  • Vassal should probably offer a “Solitaire” side/mode by default - automatically giving a player who takes a Solitaire ownership of all defined “Sides”, with no need for module designers to think of this and make a special case. Mind you, a player in such a configuration should be detectable by the module designer for the purpose of being able to offer additional support.
  • “Moderator”/“Referee” (is this really two things?) should also probably be supported by default at Vassal level. As with Solitaire, it’s the players (and specifically the game-owner, or host) who knows whether this option is wanted/needed today-for-this-game-session, not so much the module designer. And also like Solitaire the module designer can be given a way to detect the existence of a Moderator/Referee and provide special support.
  • I can’t think of a legitimate use case where it would be important for a module designer to be able to “force off” the ability to join as “Solitaire” or “Moderator”. These issues seem like they should be almost entirely player (host) controlled, apart from the ability of a designer to provide extra support.
  • Vassal 4 could provide some scripting hooks into this section for module designers, if we think of some useful areas for that.

So those are some thoughts from someone who has done this particular thing before - just suggestions, but possibly they will be useful as a different way to organize thinking.

Best,

Brian

3

Oh and by the way, for examples of “game screens from the past” that have done a solid thoughtful job in this sort of area, you could go back and peek at Age of Empires 2, or Rise of Nations, which both included co-op support which is often left out. Both have hi-def versions on Steam that are pretty cheap. Some of the modern competitive shooters deal with team-making too, although inherent to the fast-paced and shooty nature of the games, their lens tends to be a little different.

4

Thank you for this thread and the extended thoughts. Nearly everything about the current framework for players and sides is rubbish, and a frequent pain point for users.

Configuration of sides absolutely must be flexible at run-time, specifically at game creation like Brian said. I need to re-read all of the above to double-check if this was already hinted at, but a frequent problem for long-running PBEM games is when someone up and disappears with no notice, leaving their player side and access to any hidden information locked by their password. I don’t want to be captive to outdated VASSAL 3 thinking, but whatever the way forward is, there needs to be a way to forcibly remove someone from a seat/side–whether that requires unanimous consent of all other players or not, I don’t know…but it can’t keep being a situation that grinds games to a halt because there’s no easy fix.

Related to that problem, perhaps the role of “host” could be either swapped to another participant or have another “break glass in emergency” unanimous consent change if it’s the host that goes AWOL–something to prevent remaining players from being locked out of seat/side management in this instance.

For players of a more competitive vein who are currently relying on janky 3rd party services for security, perhaps there could be a clear audit trail of all setup and decisions regarding player seats/sides and access to things. That way everyone can be on the same page of who was assigned what and when, and if changes were made along the way.

5

Good point. We used to have a “voting feature” when a player’s connection dropped/lagged where the other players could vote to “Wait”, “Continue without them”, “Save game”, that kind of stuff. I can see PBEM might benefit from something like that in the “break glass in emergency” department – for games started w/ more than 2 players. Figuring out the mechanism would be new ground.

6

Brian,

I see ‘Solitaire’ and ‘Moderator’ seats as two quite different things. A Solitaire seat is just a seat that has access to all defined Sides. The Module Designer does not have to do anything special to support a Solitaire seat, it is something that Vassal can create automatically. I agree that a ‘Solitaire’ seat should be defined by Vassal by default.

A ‘Moderator’ seat is something different. A Moderator Seat would have access to a Moderator Side defined by the Module Designer, as well as all of the other Defined Sides. The Moderator Side might have its own Private Window for shuffling and dealing card for example. Or it may have privileged access to certain Game Assets that the Player Sides don’t, for example the Scoreboard. If a Moderator does not need access to anything except the Player Sides, then the Module Designer will just define that basic sides and the Moderator will just use the Solitaire Seat. In fact a ‘Moderator’ Seat is just the Solitaire Seat in a game where an extra Moderator Side has been created.

I like the terminolgy ‘Co-Op’ Seat.

Possibly. I can agree with the ‘host’ defining the available seats, adding new ones and closing unused seats. Not sure about the booting though. We cannot boot someone out of a side in Vassal 3. Not sure if we will even be able to at all in Vassal 4 as it is open to abuse.(Thoughts on ‘Secure-mode’ games later).

Yes, but the Seat owner knows the ‘key’ (more later) to the Seat whereas the the Game Owner does not.

I believe we are going to need different levels of security applied to games that will affect the seat allocation/booting rules and how seats are locked. In ‘Fun’ mode, there is little or no security, hidden information isn’t hidden and the game owner can reset/unlock/boot seats. In ‘Secure mode’ seats are locked by Digital Signatures, game Pieces are cross-signed by all players to prove no extras have been added, hidden information is really hidden in a verifiable way by Public Key Cyptography. There will be no way to release and show the hidden info associated with a Seat. If a Player loses their Digital Certificate they used to join the game, they are stuffed.

JoelCFC25 Said:

[Technobabble On - Assumes basic Knowledge of Public Key Cryptography]

If Vassal allows players to use Digital Certificates to connect to their Seat, then there is a Public Key Cryptographic (PKC) technique called Secret Sharing we can use where the secret Key of each Player is broken into pieces and given to the other Players and a subset of those Players can then ‘join’ their individual pieces to recreate that Players key. That key can then be used to release the Side and reveal its hidden information (i.e. essentially boot them). For example, In a 6 Player game, the players may agree that any 4 players can combine to boot any other Player. All 6 Players break their ‘key’ into 5 Pieces, encrypt the pieces with the other Players Public Keys and hand a piece to each other Player (This would all be handled by Vassal and stored in the Game State). Any 4 Players can agree to combine their pieces of one of the other Players Key to release their seat. This is all Cryptographically ‘safe’, no information is revealed by the Key Parts until at least 4 are combined.

In a real implementation, Players would use a Digital Cerficate such as a PGP key to prove their ‘identity’ to sign in to a Seat. We would then generate a random PKC pair to use for all other purposes in the game. This ‘Game’ key would be encypted by the PGP Public key of its owner and stored in the Game State so we don’t need to keep track of it. This way, if a game key needs to be revealed, it does not affect their personal PGP key.

[Technobabble Off]

We can do a LOT of stuff with PKC*, but again, if someone loses their Primary identity certificate, they will irretrievably lose all ability to connect to Seats Vassal games secured by that certificate. It will also require additional processing power and will increase save and log file size.

Thus, we probably want a lower security mode without overhead or fuss to play between friends and on ‘private’ servers, but allow higher levels of security to be optionally enabled for comp games or on ‘public’ servers.

Potential Uses:

  • Verifiably encrypt hidden information like the state of Concealed counters, or contents of hidden windows in the ‘public domain’ in the GameState.
  • Be confident of the identity of a Player taking a Seat.
  • Reserve a Seat for a specific Player and be confident only they can take it.
  • ‘Signing’ of pieces on the board by both players to prove later that no extra pieces have been added to the game. (PBM Piece switcheroo).
7

Gotcha on Moderator/Solitaire distinction – clearly the Moderator version is something that requires module designer to implement.

More opinions-like-assholes, albeit professionally informed ones:

  • I rate the importance of “Reserve a Seat for a specific Player” as Very High - that’s a very common use case.
  • Be able to continue a many-player game semi-unruined when one player “inevitably” wigs out - High - it’s all-too-common.
  • Be confident of the identity - Moderate - I mean yes, of course, at some “password protected” type of level, but I’m not yet convinced that lose-your-private-key-the-game-is-over levels of security are really called for here, especially in an architecture that sends secret data to client machines in the first place (encrypted or no).
  • Encryption of content of private windows, signing of pieces, etc - Very Low - unless this information is moved completely off the client.

In all my experience with online multiplayer gaming, one of the top 5 principles has always been “Never, Ever, Ever Trust the Client”. And by client I mean the whole computer at the client end, including your own software running on the client. If you want to have meaningful security, for anything but the most casual cheating, you have to hold ALL the secret information at the server end. That would mean a completely different architecture from what Vassal now has for both server and PBEM games. You’d have to have e.g. the Axis player’s hand sent ONLY to the Axis player’s computer (and managed on the server), and the Allied player’s hand sent ONLY to the Allied player’s computer (managed by the server).

Anything less and honestly it’s a huge waste of your time implementing anything beyond the casual deterrent password-and-obscured-file system that’s presently in place. Because homemade 3rd-party solutions to the client/server problem for Vassal games already exist in the form of e.g. ACTS which ensures card-dealing, hand-management, and die-rolling will remain holy while using Vassal for a client. And anybody who really wants competitive security is going to have to keep using those solutions, however awkward, as long as Vassal’s architecture brings secret information into client software, even if it arrives and leaves in strongly encrypted files. (The only conceivable exception would be if the information arrived, strongly encrypted, AND it was impossible to be decrypted while on the client machine even by Vassal … which both raises the question of why send it at all and still leaves the need for vast amount of different architecture to make so I can e.g. play an event card that affects some of my opponent’s hidden pieces (e.g. “Caesar, whichever space he’s in, takes a point of damage”), and have the effect resolve properly & fairly.

So I’m going to suggest three ways forward, in increasing order of technical & architectural challenge, but which all align with what I see going on in the videogame industry:
(1) “Deter Casual Cheating Only” - basically you stick with a password and “obscured” save file architecture that you have now. This deters what I’d call “casual cheating”. Maybe you think of a few little enhancements for that, but if you can’t solve the problem of “I keep reloading the saved game and trying the die roll again until I get what I want” then you could probably be spending your time better on new scripting hooks and UI features. Players wanting competitive security do it with ACTS and similar 3rd party server solutions. PROs: by far the easiest to implement, very similar to current architecture, players already used to using things like ACTS, deters casual cheating, leaves open the possibility of moving to level (2) later on. CONS: only the same old clunky 3rd party solutions available for real security.
(2) “Build a better ACTS” - ACTS is pretty clunky and old school. It’s SECURE, but there’s a lot of copying text / pasting text / writing new text / inaccurately transcribing text / going back and figuring out why our boards aren’t in synch / etc which gets tedious. SO… a Vassal still architected roughly as it is now could be paired with a much better (and PBEM-friendly) server, where for example I could make my moves on Vassal and they would show up legibly in the server logfile (both text summary and vlog format, perhaps), and then my opponent when logging into the server would automatically receive all that at some much more seamless (but no fully seamless) integration level in Vassal. Likewise when the server dealt me my “real cards”, there could be a hook that automatically set my hand of cards in the Vassal module to match that. Would need to provide a “live mode” similar to the current Vassal server experience, and a “PBEM” mode that didn’t require other players to be live. PROs: Legit game security. Still reasonably low-hanging fruit - module design works more or less like it always has; doesn’t involve re-architecting the entire vassal module paradigm. CONS: Significant work to implement. Isn’t “the dream”.
(3) “The Whole Enchilada” - Vassal somehow rearchitected to allow card-management, hand management, and die-rolling to be done seamlessly on an independent server. I can still play a “solo game” or “hotseat” game all on my own laptop, and casual e-mailing of “vlog” type records is still supported, but if I opt for “server mode” security then NO private information that doesn’t belong to me comes to my computer at all – and Vassal somehow seamlessly integrates with a server that tracks the secure parts of the game state. And this is done in such a way that a module designer who isn’t an expert on multiplayer security to make a module that will work right in all these modes – sometimes the cards are all tracked right here on my own computer, sometimes only on the server side and my copy of the module doesn’t even know where all the cards are. Somehow Global Key Commands (etc) that need to access the whole game state know which parts to process on the “server side” and which to process on the client side. PROS: Does all the things! CONS: Hair-rippingly difficult to architect, implement, and probably maintain!

I’m personally a fan of (1) with a stretch goal of (2), because I’d rather see an awesome Vassal 4 running in a couple years instead of another decade, and I’d rather see most of the effort going into “Doing What Vassal Already Does Best” which is easy client side development for boardgames w/ maximum hooks and configurability combined with all-new-fast-performance and even-better-UI-and-module-making features. Having worked on several games with multiplayer support varying from hotseat to LAN to internet Matchmaking to “millions of daily active users massive database scaling”, I have seen over and over the vast all-consuming resource pit that online game security leads to, inevitably draining off most of the dev hours of some of the best engineers on projects and delaying schedules far far beyond plans.

My 2 cents!

Brian

8

Hi Brian,

That’s not going to happen. Our early discussions have been about a model where servers will be distributed. Any player can be the ‘server’, so the ‘server’ may be your opponents computer. Quite apart from the development nightmare you allude to below.

It’s also not required. Advancements in cryptography allow secret information to be safely distributed.

The last plan I heard was to remove even the casual deterrent of obscuring files. Every one wants human readable save and log files. There won’t even be a casual deterrent to cheating. In fact, there will even be accidental cheating when people accidentally open save files in an editor.

If we are going to rebuild Vassal from scratch, then it’s time to start using some 21st century techniques that where not available as an option 20 years ago when Vassal was originally built.

I am hoping there will be enough willing developers to help with the bulk of the coding. My interests are in concentrating on the ‘frilly’ bits where Vassal 3 really falls down because they where tacked on, not built in. Security, Internationalisation, scripting.

These things don’t necessarily need to be built-in from the start in a fully functioning state, but they need to be designed-in and supported. I can’t tell you how hard it was to build the current Internationalisation functionality into Vassal 3. So, for example, as long as the code we build is aware of the xml tag secureState=“” and calls out to a suitable stub if it ever sees it, then I will be happy.

I am happy for a completely insecure Vassal to be built, as long as the structures are in place so that I can extend this and allow players to flip on the ‘more security please’ switch. ‘More Security’ will be completely optional. Players who use it will take on the risks involved (which all boil down to properly protecting your Digital Key)

If you want to do this safely and securely you really only have 2 options

  • Key Escrow. Everyone emails their ‘password’ to a ‘trusted’ third party who holds the keys in case someone disappears (and hopefully does not disappear themselves, and isn’t a mate of one other players nudge, nudge, wink, wink).
  • Use PKC techniques to do this securely and automatically. But this requires Digital Certificates…

That is the whole point of Assymetric or Public Key Cryptography (PKC). It does not matter what hacks a player makes to Vassal, the encrypted material is irretrievable except by the player who encrypted it.

Because when using PKC techniques, when my opponent later reveals the secret, I am able to 100% verify that the revealed secret he is sending me is the same as the encrypted secret he previously sent me.

The point of the techniques I am proposing are not to stop cheating, that’s impossible. The point is to deter and detect cheating by verification.

it’s also not a universal panacea. The handling of Decks, shuffling and dealing is a nightmare.

and

should have been in the same sentence :slight_smile:

The PBM re-roll the dice issue can never be fixed, you will always require interaction with external Dice Rollers.

We looked into building our own Dice Roller server for Vassal to work with, a much simpler job, but that turned into a rabbit hole. You end up with the same issues of central point of failure, plus the costs of maintaining that server, plus a huge development load.

HOWEVER, if we build it, they may come! We should definitely build the hooks into Vassal and build an API to allow talking to 3rd part Die Rollers and Card Managers. When someone builds a better ACTS with a proper API, we will be ready. I think there could be scope for someone to write such a system and make money on a paid subscription basis if it tightly integrated with Vassal.

Back to security, I guess this is my pet interest area. It will be up to players whether they want to turn ‘more security’ on or not.
Vassal has become very popular and Vassal 4 has the potential to become even more so. It will be relatively simple to build support for this in from the start, almost impossible to add it later.

Regards,
Brent.

9

It sounds like we’re on the same page about what constitutes meaningful security, and I’m actually overjoyed to hear that Vassal 4 can/will be built “insecure first” with hooks-for-possible-future-improvement planned for.

In my fondest dreams there would be interest from the ACTS people (who already have a server that “works right” even if the client wrapper is a little bit 20-years-old) in providing hooks and/or using your hooks so that a more tightly bound Vassal 4 / ACTS experience could be obtained. But of course I’ve dealt with enough “two completely different teams trying to cooperate” scenarios to understand it’s a heavy lift, albeit not inconceivable.

I will leave you with the hope/suggestion to think about how some hooks could be built for future integration with a dice/card management server. Examples might be…

  • Some way for Vassal to be given a “here are what the cards are in the Allied hand” package that then manually puts those cards in the hand, and similarly receive the current state of the “discard” and “removed from game” piles.
  • I dream of a world where, in the vassal module, I can click on “roll this die”, and it sends a message to e.g. ACTS to roll the die, rolls it, and puts the answer back in Vassal. Optionally has a place to ask me to type in “what are you rolling for” declaration. Optionally has a way to let me request roll of several dice at once. Lets Vassal module then receive a trigger if supported (so e.g. in Paths of Glory I could accept the result and actually move the Mandatory Offensive markers at the beginning of a turn), etc.
  • Could probably go on and on, but you get the idea.

Brian

10

I feel I should point out that I’ve been quite here because am intentionally ignoring all the V4 discussion while 3.3.0 is in preparation (and I’m also helping VASL get ready for 3.3.0). I have thoughts on all of these issues, but I won’t have time to write them up properly until 3.3.0 is out.

11

Figured as much Joel. Just wanted to get the conversation started.

12

That is the level of integration I want us to design for. We had that working many years ago with a long defunct external die roller. From the Vassal side, the component looked like the standard Vassal Die roller and you could do anything you with the results that you could do with a standard die roll. In the back-end, it called the external die roller to roll the (possible multiple die), which was then emailed to the list of email addresses you had set up in Vassal, then the result was parsed and displayed in Vassal.

Just getting back to:

Vassal has a quite widely varied user base. For example, Vassal is very popular in the War Hammer community and they had significant problems a few years back with dickheads impersonating other players to join games and then trash them.

I think you are thinking too small Brian. If we do our job right, Vassal 4 will become even more popular in wider circles and will start to attract the wrong sort of attention. There WILL be people writing hacked clients that decode other peoples obfuscated passwords, displaying hidden information on their copy of the map etc. etc. If we don’t have at least minimal protections available as an option, Vassal will be considered a joke and not suitable for ‘serious’ use.

My Vassal background is 2 player hex war game play, which has a specific subset of ‘security’ related requirements. My goal is to make Vassal a serious option for tournament play in these sort of games.

Other types of games have other issues related to things like deck shuffling and dealing that I have not solved. Decks in vassal are dodgy as hell.

13

Although I posted this elsewhere, I think it’s relevant to this discussion regarding players & sides…

There may be situations where if a player takes a certain “side” there are reasons to disallow players taking other sides.

Example: 6 playable countries (US, Britain, France, Germany, Italy, Russia)
2 player game:
Player 1 - Germany/Italy
Player 2 - US/Britain/France/Russia (defined as “Allied”)

3 player game:
Player 1 - Germany/Italy
Player 2 - France/Russia
Player 3 - US/Britain

Thus if a player picks the “Allied” side (i.e., 2 player), I would want the France/Russia and US/Britain sides to be unallowable.

Ideally, Vassal would allow for this either at run-time (dynamically) or at module development (statically).

The choice of which may influence module design. For instance, I’m currently thinking of changing a shared map for all Allied Force Pool into 2 (one for France/Russia and one for US/Britain). If an unconsrtained run-time dynamic allocation model is followed, I would probably do something different, as I’m not considering the possibility of a game where (for instance)
Player 1 - Germany
Player 2 - Italy & Russia
Player 3 - Britain
Player 4 - France
Player 5 - US

Thanks for all your hard work on this great framework!

14

I wrote a little while back about how Sides and Seats might work in Vassal 4. In your module, you would just define the 2 sides, Axis and Allies, you would not (necessarily) define what Seats might be available at that stage.

When a player starts a new game, they decide what Seats they want to define, what they want to call them and what access those seats will have to the module defined 'Sides.

I say not necessarily above, because a module designed may want to define some pre-defined Seat setups for the common combinations, but the game owner will not be constrained to using these.