Create account / Log in

Hiding information from both players

Suggestions for additional features for the module editor and Vassal engine.

Moderators: uckelman, Tim M

Hiding information from both players

Postby Brent Easton » July 23rd, 2009, 6:19 am

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'?

2. 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.
User avatar
Brent Easton
 
Posts: 3198
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Postby soft-bug » July 23rd, 2009, 7:32 am

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 …
founder of The http://www.VassalFactory.org
User avatar
soft-bug
 
Posts: 222
Joined: December 20th, 2007, 9:30 am
Location: Paris / France

Hiding information from both players

Postby Brent Easton » July 23rd, 2009, 8:03 am

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.

Brent, by this message i also reply to you 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 …

------------------------
founder of The Vassal Factory





_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 3198
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Postby soft-bug » July 23rd, 2009, 8:38 am

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
founder of The http://www.VassalFactory.org
User avatar
soft-bug
 
Posts: 222
Joined: December 20th, 2007, 9:30 am
Location: Paris / France

Hiding information from both players

Postby Brent Easton » July 23rd, 2009, 8:55 am

Grégory

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
...


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.


Idea :

The allow players to revela 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...

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
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 3198
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Hiding information from both players

Postby Tim M » July 23rd, 2009, 11:40 am

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 (http://www.mail2forum.com)
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1816
Joined: December 8th, 2007, 12:22 pm
Location: Earth

Hiding information from both players

Postby Brent Easton » July 23rd, 2009, 12:02 pm

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:

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



_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 3198
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Hiding information from both players

Postby Tim M » July 23rd, 2009, 1:21 pm

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 :)

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:

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



_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org (Messages@forums.vassalengine.org)
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1816
Joined: December 8th, 2007, 12:22 pm
Location: Earth

Postby shilinski » July 23rd, 2009, 4:39 pm

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?
shilinski
 
Posts: 170
Joined: December 22nd, 2007, 8:46 am
Location: Laurel, Maryland

Hiding information from both players

Postby rk » July 23rd, 2009, 8:50 pm

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 (http://www.mail2forum.com)
rk
Site Admin
 
Posts: 536
Joined: October 21st, 2007, 3:31 am

Hiding information from both players

Postby Brent Easton » July 23rd, 2009, 10:25 pm

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.


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'.


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.


Which is why I am trying to enhance Vassal make it easier and less 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.


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?


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 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.


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 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
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 3198
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Hiding information from both players

Postby Brent Easton » July 23rd, 2009, 10:57 pm

On 23/07/2009 at 1:50 PM Rodney Kinney wrote:
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.

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
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 3198
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: Hiding information from both players

Postby shilinski » July 24th, 2009, 4:21 am

Brent Easton wrote: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?


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.
shilinski
 
Posts: 170
Joined: December 22nd, 2007, 8:46 am
Location: Laurel, Maryland

Hiding information from both players

Postby rk » July 24th, 2009, 9:32 pm

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.
 
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 (http://www.mail2forum.com)
rk
Site Admin
 
Posts: 536
Joined: October 21st, 2007, 3:31 am

Re: Hiding information from both players

Postby shilinski » July 25th, 2009, 6:30 am

rk wrote:
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.
 
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.


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).
shilinski
 
Posts: 170
Joined: December 22nd, 2007, 8:46 am
Location: Laurel, Maryland

Next

Return to Feature Requests

Who is online

Users browsing this forum: No registered users and 4 guests