a team consists of a lead player and a support crew. the lead player is separated, and communication between the lead player and support crew is regulated as follows.
when it is the team's turn, both the lead player and support crew examine the position. the support crew members discuss the position amongst themselves and designate as many moves as they wish as REJECTED on a computer interface. these are moves the support crew considers to be bad. at some point, the lead player independently chooses a move for approval. if the chosen move is not on the support crew's REJECTED list, the move is immediately committed and the turn ends. (all this is logic is done electronically.) if the move is on the support crew's REJECTED list, then the lead player is notified of this. the lead player can think further, then choose a move to play, ending the turn. note that there is only one round of a move possibly being REJECTED per turn. the lead player can still play a REJECTED move. it can even be the original move REJECTED by the support crew, though that would be a pretty dysfunctional team dynamic.
if the lead player chooses a move too quickly, the support crew might not yet have had a chance to mark it as REJECTED, so a lead player blunder might get committed. however, if the lead player waits longer, it consumes time on the clock, so there's a trade-off.
maybe Bronstein delay to lessen the trade-off and allow the support crew to be more involved. if the lead player moves faster than the Bronstein delay, the support crew has until the end of the delay to decide whether to REJECT it, and the status of the proposed move is returned precisely at the end of the delay.
the support crew is allowed to change its mind about which moves to REJECT as many times as it wants until the lead player proposes a move (or the end of the Bronstein delay). support crew might use a UI in which all moves are initially marked REJECTED, and they remove the REJECTED flag on some moves as they analyze.
this system of the lead player querying just one move is designed to thwart steganographic communication from the support crew to the lead player. the support crew cannot do things like encode additional information like what move to play in the timing of its responses.
support one-way communication from lead player to support crew, perhaps text or voice. (this was motivated by the difficulty of preventing steganographic communication, e.g., through timing, from lead player to support crew. rather than try to prevent it, let's embrace it.) for example, the lead player can notify the support crew of an important line to start examining while the lead player concentrates on something else. this might require the lead player to be separated from the opponent, so the opponent doesn't hear the communication.
for example, the lead player could communicate, "I'm going to play move X, and if REJECTED, play move Y." then, the support crew's job reduces to advising whether X or Y is better (perhaps an uncomfortable job if the crew determines that both moves are bad).
another strategy: steer the game toward positions which have exactly two candidate moves, maximizing the usefulness of the support crew. opponent could steer the game away from such positions.
the support crew could just be a computer; this would be a variation of Advanced Chess. previously similar: (1), (2). which moves should the computer mark REJECTED? (the best move might be too difficult for a human to find.) perhaps similar to above: the lead player communicates that the computer should advise the better of two possible moves selected by the lead player.
one cannot have unlimited rounds of the lead player proposing and discovering moves REJECTED, because then the support crew could mark all but one move REJECTED, and the lead player can discover it through mindless trial and error.
No comments :
Post a Comment