Planning moves in secret and revealing them

Module Design
1

Are the Delayed Notes the only way for the players to plan their moves secretly for the next Turn?

2

Depends very much on the mode of play. There are three modes of play with Vassal

  • Hotseat Players share the same computer and take turns to sit down in front of it to make their moves, etc.
  • Networked Players each have their own machine and they are connected via connections to a shared server.
  • Play-by-E-Mail (PBEM) Each player has their own machine, which are not connected in any way. A player executes a (partial) turn and ships off a log (.vlog) to opponents. They then load the log and executes their (partial) turn, and vice versa.

In Hotseat, the way to make secret moves is simply to have opponents look away from the screen.

In PBEM all moves are secret until they are revealed when opponents load the log.

That leaves Networked. By default, when a player makes a move, it is immediately visible to other players. That means that moves are never secret. Vassal has no provisions for switching to a “draft” or “planning” interface where moves can be tried out, and then later “committed” to actual play.

One way it could be accomplished would be to make all pieces Invisible. One could then define a button in the map toolbar - say “Hide all pieces” which a player would hit before starting to plan moves, and only when the player is happy would the player hit another button - say “Reveal pieces”. I’m not sure how well it would work though, but it could be worth a try.

One could also rely on a sort of gentleman’s agreement that out-of-turn players avert their eyes from the screen until the player in-turn tells them its OK for them to look.

My 2¢

Yours,
Christian

3

Thx! Should have been more specific :smiling_face_with_sunglasses:

The game involves planning all ship movements on a hexgrid at the start of the turn secretly, then simultaneously revealing them and executing them. As firing comes later, this is all done at once (i.e. does not matter who goes first etc.)

Hot seat would resemble PBP in this case - player 1 doing his planning, sending the VSAV and then the other player doing his planning, sending it back and player 1 would reveal his delayed notes etc.

So what I am asking is if people use anything else than Delayed Notes for such cases in their modules.

4

For PBEM use Load Continuation, that is assuming all planning is mutually exclusive.

Both players load the same base file, either a vsav or vlog. In case of a vlog fast forward to the end. It’s important that you both log from the same starting point. Both players log their respective ship movement as per your example. This can be done simultaneously without waiting for the others planning. Each player sends their log file. As with any PBEM game there is a level of trust and an assumption that one won’t peek at the others planning log in advance.

The next player to move (or in your case fire) has to stitch the planning moves together. This can be done in any order as long as each player only moved their own units. If both players move the same unit(s) this breaks down creating a synchronization issue and probably lots of confusion. For this example lets assume player 1 is next. Load the player 1 log. You can use load log and fast forward if you prefer. Load the player 2 log using Load Continuation. Load Continuation loads the player’s actions without changing the game state. This preserves your changes while appending the other player’s moves. Play through the log(s) to the end and begin logging your next actions.

I haven’t played a game like this, but this is how I would approach a secret planning phase. Delayed Notes is more secure as in there’s no opportunity to peek at your move, but then you’re doing things twice.

1 Like
5

This is a good idea, and can possibly also be used in a Networked game.

The point is, that a .vlog file has the approximate format

Starting state 
Logged moves

Normally, when you load a .vlog, everything in the .vlog is executed - including setting the starting state. When loading a .vlog as a continuation only the Logged moves part is executed.

For networked games, each player would have to disconnect, make their moves, then send the .vlogs to a master who then loads them all as continuations, and then all players can rejoin to see the results.

One could perhaps make Vassal support this kind of Diplomacy way of making moves.

In the various Client code, one could have

class Client implements ChatServerConnection, ...
{
   ...
   boolean sendDeferred = false;
   Command deferredCommand = null;

   void sendTo(Command c, Player p) {
       // Need so store the player too somehow 
       if (sendDeferred) { 
            if (deferredCommand != null) deferredCommand.append(c)
            else deferredCommand = c
            return;
       }
       doSendTo(c,p)
    }   
    void doSendTo(Command c, Player c) {
      // Current code of sendTo
    }
    void sendToOthers(Command c) {
        if (sendDeferred) { 
            if (deferredCommand != null) deferredCommand.append(c)
            else deferredCommand = c
            return;
       }
       doSendToOthers(c) 
    }   
    void doSendToOthers(c) {
       // Current code of sendToOthers
    }
    void startDeferred() {
        sendDeferred = true; 
    }
    void endDeferred() {
          sendDeferred. = false;
          if (deferredCommand) doSendToOthers(deferredCommand);
    }

The above is in no way complete, and there needs to be a mechanism in the UI to enable the deferred state. It is just an idea.

Yours,
Christian

6

This is an interesting question. I am going to approach this from a different direction. I can think of a number of euros that have players planning their moves behind screens. When ready, both remove their screens to see what’s what. In your case, I can envision a private map copy of the main board hidden behind a screen. You plan there, and then later reveal and implement those plans on the main board.

This can be done via delayed notes, but it’s all text, which is cumbersome and error prone. Let’s consider that each player has a separate planning window that mirrors the main board. Can we do this?

The first thought is the planning windows would be private and then made public at the unveiling. That won’t work because vassal would let us change windows like that from private to public. No go.

Another idea I had was to put all pieces in the planning window on special map layers that could be disabled. That won’t work either because map levels are enabled/disabled for everyone, not per player.

I think the only solution is the invisibility trait. All pieces in the planning windows would have it. I would put a toggle button on my planning window’s toolbar that would turn my invisibility on or off, and it would work only for me. It would gkc all pieces on my planning map. I’d make my plans while invisibility is on, and I would hit the button at unveil time.

The only headache I would worry about is my planning window getting out of sync with the main window, but I know how to fix that. That’s a different topic for another time.

7

Why not just keep the invisible pieces on the main map? This should work for both Hotseat and Network play. For PBEM, @rlament’s suggest would work, and there’s no reason to make the pieces invisible.

Heck, one could even automatise this. When the game enters a specific phase, say Planning, a command is sent to all pieces on the map, filtered on {PlayerSide!=PieceSide}, to turn on invisibility. And when leaving the Planning phase, all pieces are made visible again. If needed, the condition to make a piece visible could be filtered on a pieces proximity to an enemy ship or some random die roll, or both. For Hotseat play, one would need to trigger those two commands when the active player changes via Startup Global Key Commad with configuration When to apply set to On side change.

Or have I missed something that would necessitate private maps?

Yours,
Christian

8

OK, so I thought of an issue - not that it necessitates private maps - see more below.

If opponents pieces are made invisibile, then the player will only see their own pieces and not the opponents pieces. Thus, that could make it hard to plan moves properly because one would have to remember where the opponents pieces were.

A possible remedy would be, when entering the planning phase, that all affected pieces clone themselves. Then the clones are made invisible to the owning player and the original pieces made invisible to the the not-owning players. In that way, you will have a copy of the opponents’ pieces in the planning phase - which you can freely manipulate in your planning, for example to move them according to your expectations of what the opponents will do. These clones will then be removed at the end of the planning phase.

This requires a bit of hackery using the traits Clone, Set Global Property, and Invisible, and possibly also traits Global Key Command and Restrict Commands. Note that it also means that pieces will most likely have two Invisible traits - one to hide it from non-owning players - activated in the original piece, and one to hide it from the owning player - activated in the clones. Clones can be identifed by the presence of the property CloneID.

It may become a little clunky in terms of traits, but it would mean that one automatises the bookkeeping, and users only have to deal with one map.

It would be interesting if one can make a small proof-of-principle module.

Yours,
Christian