Hiding information from both players

I have been working on a module that requires randomly distributing VP markers that are hidden from both players. Each marker has a different VP count. A VP chit is revealed during the game in certain circumstances, or at the end of the game.

There are a number of different ways to hide the information from both players, the problem appears to be how do you reveal the information when required, without one the players doing so early.

A couple of solutions come to mind.

  1. If the information is hidden by Masking it, then an extension to the Mask trait that requires all players in a specified list to perform the unmask action before it takes place. If the Mask commands in

Mask Ctrl M

Then after the first player performs the Mask command, nothing will happen, but if he right-clicks on the counter, the Mask command will be disabled and appear as

Mask (waiting) Ctrl M

Other players on the list will still see the normal Mask Command. When the final player performs the Mask command, the piece is finally unmasked for all players.

Perhaps this could be linked to the ‘Can be Masked by: Any of the specified sides’ option with an additional checkbox ‘All sides must unmask piece to reveal’?

  1. Idea 2 is similiar to 1, but built into the Trigger Action instead of the Mask trait. This would be more general purpose.

Thoughts?

B.

Brent, by this message i also reply to your email … I see that you are facing the same mecanisms about masked pieces or for an auction system in term of design.

The solution listed below in more efficient with more than 2 players. Because you do not have to manage each case between players…

Classical Way :

I will define both the need to be revealed to all players and the need to be revealed by only one player at a time.

To insure the need to be revealed to all players:

Define the Global Property : Can be revealed by all players. Then in the Mask trait : “any side” and Plain with a “black” back.

All players can therefore reveal the pieces using CTRL M and a report trait trace who has done this operation one piece by one piece : it depends of the context.

You can add a button to send CTRL M to theses pieces. Then all players are allowed to launch the global unmask function to revealed and do not restrict individual report.

To insure the need to be revealed by only one player:

In your Mask trait add a command for PEEK : CTRL P. Then trace the operation using a Report trait like : $playerSide$ glance at $BasicName$
By this way you know that who have seen the VP piece.

Conclusion :

This classical way insure that you do not have to “manage” each side using restrict command and you do not have to “manage” the context : If a player glance at a piece, it’s certainly because he has the right … but if he has wrong … you have traced this too …

Hi Gregory,

I don’t see how either of your options provide a workable solution to the problem. Neither do they provide any sort of security against off-line viewing of the hidden information (a.k.a cheating). Any module that depends on these sort of techniques to suppress cheating is doomed to failure.

I don’t just want to know when people view a piece of information before they are supposed to, I want it to be impossible for them to view it until all players agree it is time. Often, once a piece of information has been revealed to early, it is impossible to undo and the game is ruined.

It is possible to build a custom scheme based on DP’s and Triggers, but I think an easier, secure solution is called for.

Regards,
B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Brent,

You have right, my solution works only for online mode … I will not speak about my own point of view about “cheating” with a 2 player game using Vassal …Maybe changing the “opposite” player will be the solution …

Idea :

To allow players to reveal pieces when all player have decided to do so : Using a “Key” Marker.

Each player has a “key” marker dedicated to their side (in a private window ??) . Then when both “Key” markers are placed on a zone then a restric command is no longer activated to use CTRL M (Mask). Using Global Property = 0 or 1 if “Key” markers are placed…

Regards,

Grégory

Grégory

Very true. But the temptation when playing in PBEM mode is overpowering if the information is easily accessed. I’d like to take that temptation away.

That’s a good idea. You can do all sort of things with Global Properties and values, and these work fine if you have just one or two bits of information to reveal. But I need something simpler that can be attached to individual counters. I will have about 20 different VP counter with varying values and each one may need to be independently revealed as game circumstances change.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Hi Brent,

I had been working on similar issue. Like Gregory, Im relying on the Peek by
first player who then takes ownership and then unmask later when other
player needs to view chit, however it sometimes requires players to look at
the chit not necessarily at the same time, so the classic method works well
with reports etc… the exception being of the possible offline cheat you
mentioned.

I like the first idea, but can we modify it handle the classic method above
(revealed at different times) - perhaps by also changing the mask image as
well as the access command?

So if one player looks at chit at 10.00am the mask image permanently changes
to another “alternate mask image” that lets other players know it has been
viewed earlier by a player (this will also be apparent to the first viewing
player) and once all other players have finally viewed the chit at 11.00am
via mask waiting command, the mask are removed. This would remove the cheat
for the classic situation above

Tim

Post generated using Mail2Forum (mail2forum.com)

I have to admit that I don’t actually understand the ‘classic’ method that Gregory outlined. I must be missing something because it doesn’t seem to me to hide anything from anyone, or solve the basic problem of having information hidden from all players, then revealed to all by mutual consent.

The modification you outline below seems to be trying to work around the fact that it doesn’t solve the initial problem. It is also becoming very complicated.

There are no doubt other information revealing ‘scenarios’ that need to be addressed also, and perhaps you two solving one of these??? My feeling is that if we outline some different ‘hidden information’ scenarios, it will boil down to a few basic features that are needed to implement them all. The Mask trait seems the right place to implement these in, as it is the primary ‘information hiding’ mechanism in a VASSAL counter.

Perhaps we need a completely new trait altogether - some sort of ‘security’ or ‘lock’ trait that can be locked in various ways and the programmed to ‘unlock’ and issue hotkeys in different ways?

B.
*********** REPLY SEPARATOR ***********

On 23/07/2009 at 6:40 AM Tim McCarron wrote:


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

I wouldn’t say that Gregory and I are solving one of the problems, rather providing a faux facsimile that heavily relies on players to implement while playing :slight_smile:

Mask at first glance would seem like the right place to do this but ownership (inherit to mask) is the thorny point I think. Right now we have 2 (that we know of) HI Scenarios:

Hidden Info - revealed to all same time
Hidden Info - reveal to different players at different times

How ownership works in these (and other?) cases will be deciding factor. It does not seem to be a problem in first case with Mask waiting proposal, but would seem to be problematic in second based on how mask works correct?

From: Brent Easton b.easton@exemail.com.au
To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org
Sent: Thursday, July 23, 2009 7:01:24 AM
Subject: RE: [Feature Requests]Hiding information from both players

I have to admit that I don’t actually understand the ‘classic’ method that Gregory outlined. I must be missing something because it doesn’t seem to me to hide anything from anyone, or solve the basic problem of having information hidden from all players, then revealed to all by mutual consent.

The modification you outline below seems to be trying to work around the fact that it doesn’t solve the initial problem. It is also becoming very complicated.

There are no doubt other information revealing ‘scenarios’ that need to be addressed also, and perhaps you two solving one of these??? My feeling is that if we outline some different ‘hidden information’ scenarios, it will boil down to a few basic features that are needed to implement them all. The Mask trait seems the right place to implement these in, as it is the primary ‘information hiding’ mechanism in a VASSAL counter.

Perhaps we need a completely new trait altogether - some sort of ‘security’ or ‘lock’ trait that can be locked in various ways and the programmed to ‘unlock’ and issue hotkeys in different ways?

B.
*********** REPLY SEPARATOR ***********

On 23/07/2009 at 6:40 AM Tim McCarron wrote:


Messages mailing list
Messages@forums.vassalengine.org (Messages@forums.vassalengine.org)
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

First off, from someone who has built many of the block game modules, masking is probably not your answer because a masked piece is owned by someone, so only the owner can unmask it. Of course, both could enable “allow opponent to unmask my pieces”, but I don’t think this option should be required. (BTW, this IS a valuable option in the block game world contrary to what you think.)

Second, I tend not to worry about security because it is either too hard or too cumbersome to enforce. For example, if the game has a faceup discard pile (faceup Deck) anywhere handy, it blows all masked security to hell because the discard pile will reveal all masked pieces. With your case, I’d forget about security.

Third, there is a solution that’s a bit different. When a marker on board is revealed, you don’t reveal it. Instead you draw a piece/card from a deck that is in constant-shuffle mode. The onboard marker is simply a marker and does not contain information. The hidden information is in the deck. Sure, the cheater could draw early, but what he sees is probably not what eventually will be the result.

This method would work for your specific case, but it probably is not a general solution, so the question is are you trying to solve your problem or are you trying to solve a general problem?

I would also to suggest a new trait for this use, called Lock or something similar. It would provide an ‘Unlock’ menu item that all players would have to select to unlock the piece. Once it’s unlocked, then the underlying traits become available. Then you could use a normal Mask trait underneath that players un-mask once the piece becomes unlocked. This gives you a little more flexibility, since you can make a piece non-manipulatable without necessarily changing the way it looks.

rk

Post generated using Mail2Forum (mail2forum.com)

However, my proposal changes this so that when mutiple ‘owners’ are specified, the actual ‘owner’ can no longer unmask it by himself. Peek would also have to change so that a piece masked in this way would not be visible to the actual ‘owner’.

Which is why I am trying to enhance Vassal make it easier and less cumbersome to enforce.

This issue will be fixed in Vassal 3.2. You will no longer be able to place counters that are obscured to you into a Deck. Any other issues you can think of?

This is how I initially tried to approach the problem and this will work fine where the information is revealed one piece at a time and, once revealed, it stays revealed. However, the particular module I am working on requires a more complex interaction where a counter can be revealed, then be unrevealed and mixed back into the pot. But once a piece has been revealed, it MUST keep its individual identity, it cannot be mixed back into the off-board Deck without changing the dynamics of the VP draw mechanism.

I am trying to solve my specific problem by providing a mechanism that will be general enough to solve a wider range of information hiding problems.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Ok, Interesting. What should the Lock trait actually do? Hide underlying commands? Disable underlying Commands? All commands or only listed commands? This seems to be a special kind of the ‘Restrict Commands’ trait and might need most of the same options.

I like the idea of a seperate trait.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

It occurred to me after I wrote my note that no existing method will work in a PBEM game because the cheater can simply redo his log again and again (rerolling dice, redrawing cards, etc) until he gets the result he wants. Generally, I hope to not play against those players.

I build a lot of block games with masking, and since you ask, there is another unrelated thing that would be really helpful. I do not believe it is possible to start a game where a player’s pieces are already masked for him. For example, if a player starts the block game Liberty as the British, he must (first thing) mask all the British blocks on the map. I try to make this convenient by putting a mask British and mask Americans buttons on the buttonbar, so once per game he presses his button to do it all at once. (The button is linked to playerSide, so the British player cannot mask American pieces.) I believe in some block games that there is no such convenience button, so a player must right-click and mask every piece.

As a module designer, I cannot build a scenario with masked pieces and have the player grab control of the masked units when he chooses a side (even if I resign the scenario before saving). It would be great for the players if the s/w would work somehow as follows: A player choose a side to play. The s/w loops through all masked pieces looking for those with a specific property (side=British). The s/w loads the player’s password into the piece thereby giving the player ownership. (If things have changed since I first explored the issue, then I don’t know about it.)

On another issue, you seemed to thing “allow opponent to unmask my pieces” was worthless. It is not. In every friendly block game I play, we enable this flag. It is way to easy to forget to unmask pieces to resolve battles in pbem games, and this flag allows us to move the game along when someone forgets.

You’re right. It would be almost identical to the Restricted Access trait. It might be better implemented as an option within that trait. The only difference is that it can be unrestricted dynamically instead of being statically linked to one side.

rk

Post generated using Mail2Forum (mail2forum.com)

The trouble with the Restricted Access trait is that (in my opinion) it is TWO traits in one. It restricts all traits above it to the listed sides, AND it restricts movement to the listed sides also. In my opinion, those two traits should have been decoupled. Restricting movement is a reason why I have never used the trait. I wish the Restricted Access trait had a checkbox that allowed piece movement to be restricted or not. (On by default for backward compatibility).

Sounds like a good idea. If I go down the Restricted Access route, it will be a major rewrite, so will be easy to add this in.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

A long, long time ago, I proposed that the moving aspect of Restricted Access be split off into a new trait called “Movable.” The Movable trait would control how and who could move a piece plus some other ideas I can’t imagine now. Currently, movement traits are scattered among other traits such as Restricted Access and Stacking (effectively making them compound traits). Alas, due to backward compatibility issues, it’s probably no longer practical to put all movement controls under a Movable trait, but it certainly would be advantageous to do so in a framework such as Vassal (more tool flexibility).

Yes, you can do this already with no fancy work required.

In the Masked trait, set the ‘Can be Masked by:’ option to ‘Any Side’ instead of ‘Any Player’. You can then take the british side and set up the British masked pieces, then retire from the British side. Any other player who now takes the british side will then automatically own those masked pieces.

The wording for this option is somewhat Obscure [:)], the reference manual help is much clearer, talking about who can ‘own’ the piece, not who can ‘mask’ it.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Brent,

I’m curious about the new trait … that you are preparing to us :wink:

I just put here a little “thought” … to share with you an idea …

Indeed, when you want to give the “right” to be seen to a dedicate player side … you must first know … which side is activated and secondly if the “right” is permanent or not…

If 4 sides are declared in a module :

Side 1
Side 2
Side 3
Side 4

If during play only Side 2 and 4 are taken … then in term of design how to get flexibility… because impossible to predict this to manage the “actived sides” in a module.

Then , if during play you can declare “can be seen” by Actived side 2 or Side 4 … for a piece, card, token … you can put the “right” to the current sides requiered.

I have taken more then 2 sides, because for example in a card game … during play a player gets the temporary “right” to see another player’s hand …

Very complex problem to resolve … if you also take care about “automation” …

Good luck !!

Regards,

Grégory