Sides and Seats.
Problems with Sides in Vassal 3
They are fixed within the module and cannot easily be varied between scenarios.
Can’t close empty seats to prevent unwanted players jumping in the game.
Can only play 1 side at a time and finicky methodology to change sides.
Sides
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.
Think Black and White, Axis and Allies
Sides can also be much more generic where there no specific Game Assets allocated to them.
For example, 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.
The available Sides in a module will still be defined by the module Designer.
The number of Sides is fixed by the module Designer.
Seats
A Seat is a position at the Vassal virtual table.
A Seat is associated with one or more Sides that gives access to Side specific Game Assets.
An Observer (in the Vassal 3 sense) does not take a Seat and has no access to any Game Assets. They may look but not touch.
Seat Definition
A Module Designer will define a set of Seats that can be allocated to Scenarios
A Seat can be created with access to more than one Side.
A Player in a multi-Side Seat will only play one Side at a time, but they will be able to change between their available Sides by a simple drop-down menu selection. They will not need to retire, change password and re-join and take a new Side.
Seat Definition Examples
A typical Axis & Allies game would define two Seats. One with access to the Axis Side and one with access to the Allies Side.
A game with 3 Sides (e.g. Axis, Western Allies, Russia) would define 3 Seats in a scenario, one for each Side. The might also have a 2 Player scenario defined where one Seat is allocated to the Axis Side and the other Seat allocated to both Western Allies and Russia.
A Solitaire scenario would have a single Seat defined that is attached to all Sides in the module.
A Moderated scenario might have an additional Moderator Seat defined that is attached to all Sides, plus a ‘Moderator’ Side.
Seats are Dynamic
New Seats can be opened and unused seats closed during play in a controlled way.
Need to discuss limits and controls on this, however I envisage the following possibilities.
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]
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 and takes that 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 delete the Subsidiary Seat.
(1) “Seats” shouldn’t be controlled by module designer but rather by the players creating the game – because they may want to cram 5 players a side into a game of Squad Leader and everybody gets one tank or whatever. Module designer won’t have thought of that and doesn’t need to. Regular seats can be completely & adequately controlled by assigning the regular sides a password at game start – you have to know the password to join as “Germans”, but if as a player you want to give out the password to 5 people you can have 5 people play that side.
(2) We don’t need to define a specific number of seats for the game (ever), because we don’t have any particular technical limitation to overcome here (we needed specific numbers of seats in some RTS games I worked on because we were trying to maintain 30 FPS+ on them etc and there were technical/latency limitations)
(3) “Observer” quasi-side can also be assigned a password by whoever starts the game, if they want to keep people from being able to join as observers unauthorized.
(4) Special case is the “Solitaire” / “Referee” quasi-side – we ideally need a way that at game-start this side can be permanently disabled for that game. Problem with “just give it a password” is that one player will inevitably therefore know the password – too easy to cheat even by Vassal standards. In theory we could give all “Sides” the potential to be perma-locked-out (by players at game-launch). That could be helpful in games that potentially take e.g. 6 players but can also be played with 4.
Note - the passwords I’m describing here are NOT the users’ “account passwords” tied to their online handles/identities. They are separate “join-the-room” passwords, which is why this works. Players shouldn’t have to share their “identity passwords” to do these things. Join-the-room passwords are pretty common in game lobbies, chat servers, etc – most players will understand them intuitively.
(1) Agreed, these are old thoughts from a few years back. I think Seats should probably only be able to be created at the time the ‘Game Session’ is initiated by the player who creates the ‘Game Session’. (Note a ‘Game Session’ sis NOT the same as a ‘Scenario’. No more seats should then be able to be created except in the case of the ‘Subsidiary Seats’ I mention where any player can essentially clone their own seat.
(2) Agreed, the seats are allocated by the Player creating the ‘Game Session’.
(3) Observer is just a Seat with access to neither side. In V4, I would like to see Observers default to essentially view-only plus chat by default. All Seats should have ‘Join’ passwords allocated when the ‘Game Session’ is created.
(4) There would be no such thing as a Solitaire side, there would be a Solitaire Seat with access to both sides. In a multi-player games, the initiating player would not create a Solitaire seat.
One thing I did a long time ago in my BBTM module was to have players own a side - “Player 1 , Player 2…” etc but nothing was ever assigned to the side. Then with the genius of the Auto GKC that was implemented at this time all the decks were neutral but once a player selected his side through the AutoGKC the appropriate deck was assigned to the player board and it became “owned” by the player - 1.2.3 etc…
It works really well.
I think this is very similar to what you are trying to capture. The capability is already there albeit not intuitive for a designer to setup - it took me awhile to rig it
Actually worked a little different when I went and looked to see what I did.
I created unassigned sides players could join and provided a random pull chit deck that assigned their side and the module chat would instruct them to now retire and join the side they pulled from the deck. Cheap workaround. But it works
IMHO - the default for Observers should be allowed, no password required. It might be useful to allow players to toggle whether observers are allowed or not (i.e., consider use case of overly chatty observers joining) during the game, including ability to “kick” and/or “silence” (no chat) observers.
IMHO the “Observer” role, is should be standardized across all modules.
Observer - a mandatory role (i.e., cannot be deleted by module designer) that works exactly the same across all modules and supports multiple observers. Observers cannot affect game except for ability to chat. V4 should support observers joining as the default, but players who desire to ban (or kick) observers should have an in-game ability to do so.
Similarly, it might be good to have a standard definition for “Referee” (which again can be disabled by players in game and/or on module startup).
Referee (active) - allows full manipulation of all pieces
Referee (passive) - cannot manipulate pieces, but has access to all hidden information (e.g., masked units, hidden text, hidden maps, etc.).