Dark Chess

[hgm]

I wanted to start a new thread based on George's post quoted below:

Any fan of Chess variants should start his favorite variants with Dark Chess as the undisputed number 1!

I bet that if this obscure, uncelebrated, not known in the public, game becomes a little more known, it will become the best variant and will quickly become popular. It's amazing!
One great flaw of it is that you can't play it live over the board but only with a computer help, but it's OK, since it's so incredible that it makes one obsessed with it once it plays it 1-2 times, even only through a computer.

And the programming challenge is higher than in every other Chess-type game. Programming even a crappy AI is difficult i guess.

And here ends my annual try to make people get interested in Dark Chess.


---------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------
And the rules for Dark Chess(remember you have to play it 1-2 times in order to feel the intensity and the excitement this game gives you):

Dark Chess follows all normal Chess rules except that:

•The squares the player see must follow at least one of the above conditions:
-A player's piece stands on that square.
-The player can move* a piece to that square. This means that he can see empty squares that he can move to and he can see an opponent's piece that he can capture*.
-The square is directly in front of one of player's pawns OR 2 squares in front if the Pawn is on its starting square OR it is an adjacent forward diagonal from one of player's pawns.
-The square is an adjacent right or left to a Pawn and an opponent Pawn has moved there directly in its previous move coming from its starting square(this rule is simply to letting the player know that he can capture en-passant).

*"Can move" and "can capture" means and since there is no check in this game that a movement or capture that exposes own King to check is a legal move.

•There is no check or checkmate. Each player can move his King to a position where the opponent can capture it.
•There is no 50-move rule, no 3-fold repetition and no stalemate.
•In case 2 bare Kings left in the board, if after 3 moves by both players there is no capture then game ends as a draw.
•The player who captures the opponent's king wins the game.

Here is a small example:

Here is what white sees in the starting position.
Obviously he has full information about the board position even he doesn't see it.



Here is what white sees after playing 1.Nf3
Obviously black doesn't know that white has played 1.Nf3



Here is again what white sees after black's first move too.
Obviously black was careless enough and played 1...g5 so we can now see the Pawn on g5.



Here is what white sees after he played 2.Nxg5
Black does NOT see the white Knight on g5.
But he can understand that one white piece captured his g5-Pawn as he can't see the g5 Pawn any more.

[hgm]

I don't see myself writing an engine for Dark Chess anywhere in the near future, but that would not have to stop me from providing support for it in WinBoard, of course.

Currently WinBoard has an opiton " blindfold", which displays every square as empty. In a similar spirit, a "dark" mode could be provided, where the squares are masked out sleectively, based on the moves the side you are playing has. In "variant dark" this mode would be the only one available. That seems the easy part.

It seems there would be some protocol extension required to inform the engine about what it is seeing. And of course you cannot send it the normal move, because the engine might not see anything of the move.

It seems in Dark Chess you will see one of the following things when your opponent moves:
1) Nothing
2) A piece appears in your field of view
3) A piece disappears from your field of view
4) A piece appears in your field of view, and the sam epiece appears else where
5) A piece appears in your fieldof view, and another piece appears else where
(In all cases, 'piece' stands for 'opponent piece')

Case (5) can happen for castlings or promotions, and you will immediately be able to to deduce the full move from it. So it is equivalent to (4), where you also saw the complete move. In all these cases, you can simply send the fullmove to the engine.

In case (2) you can use the drop-move notation: P@e4 tells the engine it sees a pPawn appear on e4, etc.

For case 3 the notation @@e4 could be used to indicate the disappearance of a piece from e4. (A generalization of the drop-move syntax; you ' drop' an empty square, indicated by '@' for the piece type.

Case (1) also needs new syntax; you see the same as when the opponent would null move, so 'null' suggests itself.

That solves how to send the opponent move to the engine. Now after the engine sends its own move to the GUI, the move alters its field of view. So the engine would have to be informed of what it sees in this new field of view. My proposal for this is to define a new command in WB protocol:

info SQR1 SQR2 SQR3 ...

where the SQRn indicates the contents of a newly visible square, in drop-move syntax: like

info P@f7 P@h7 @@e6

when you see an empty square at e6 and opponent Pawns at f7 and h7 after moving Ng5.

An alternative is to use the existing setboard or edit commands for this. For instance, the convention could be adopted that sending a board with only pieces for one color (the opponent) should not be used to start a new game from this position, but should just be taken as an update of the field of view.

For in FENs (in setboard) a square with unknown content could be sent as a question mark.

That seems to cover it.

[Sven]

It seems in Dark Chess you will see one of the following things when your opponent moves:
1) Nothing
2) A piece appears in your field of view
3) A piece disappears from your field of view
4) A piece appears in your field of view, and the sam epiece appears else where
5) A piece appears in your fieldof view, and another piece appears else where
(In all cases, 'piece' stands for 'opponent piece')

Don't you have also this, when the opponent captures a piece?

6) One or more (empty) squares disappear from your field of view.

Not that I'm too much interested in Dark Chess, but it just came into my mind. If a piece is captured then it can't move to certain squares any longer, so some of these might disappear from your view. Initially you can deduce that these squares are empty but after the next opponent move this is no longer safe so it makes a difference.

There may of course be a lot of information that can be deduced without being in the "field of view" but here you are talking about the formal part.

Sven

[hgm]

Although you are right that this can happen, it is not new new information to the engine. That is, it should be made aware that its piece disappears. Then it can conclude for itself which squares it no longer can observe.

But this would indeed need a move notation I did not describe, if the captured piece was not viewed by another one (i.e was unprotected). Then you know the opponent moved to that piece, but you do not know what he moved (if you also did not see a square turn empty). I guess a logical notation for this would be '?@e4'.

Indeed this is the formal part; I think on an earlier occasion George stated that it would be undesirable to have the GUI show any deductions.

[adamh]

Also:
5b: A piece moves (and regardles of it appearing elsewhere or not) it uncovers & opens new lines and reveals one or more new pieces.

The most extreme case would be an opponent knight that was attacked along two diagonals (by Q+B), one vertical and one horizontal (by R+ R ).


Also you need "visual feedback" on your own moves, or was that in your list?

[adamh]

Actually all this is getting a bit messy.

Under all circumstances we need an interimediate machine (IM) that holds the entire board.

Moves going into the IM may well be in standard Winboard format
Moves goin out should not be changes, that would require the protocool to be state aware, and bug prone (The IM would have to remember what each player already knows).

No keep it simple: Moves going out should be all visible squares.

[Uri Blass]

I think that you are wrong to assume that there is no stalemate

The following game that is legal in normal chess is also legal in dark chess
and the final position is clearly a stalemate in the strong meaning(no pseudolegal moves for black that allow capturing the black king).

[Event "5'/40+5'/40+5'/40"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "Uri Blass"]
[Black "Uri Blass"]
[Result "1/2-1/2"]
[PlyCount "63"]
[TimeControl "40/300:40/300:40/300"]

{256MB, Om Master Book 2.0.ctg, URI-AMD} 1. b3 e5 2. b4 Bxb4 3. Nf3 Bf8 4. Nxe5
b5 5. Nxf7 b4 6. Nxh8 b3 7. a4 a6 8. a5 h5 9. Ba3 b2 10. Ra2 h4 11. Nc3 b1=B
12. Ra1 Ba2 13. g3 hxg3 14. e4 gxf2+ 15. Kxf2 g6 16. Nxg6 Ne7 17. Nxe7 Bxe7 18.
Bxe7 Qxe7 19. e5 Qxe5 20. d3 Qxc3 21. Bg2 Ke7 22. Qe1+ Kd6 23. Qxc3 Bd5 24. Qd2
Kc6 25. d4 Kb7 26. Bh3 Ra7 27. c4 Ka8 28. Rad1 Bdb7 29. d5 Bc6 30. d6 B6b7 31.
c5 c6 32. Qc2 1/2-1/2

[d]knb5/rb1p4/p1pP4/P1P5/8/7B/2Q2K1P/3R3R b - - 0 32

[hgm]

Actually all this is getting a bit messy.

Under all circumstances we need an interimediate machine (IM) that holds the entire board.

Moves going into the IM may well be in standard Winboard format
Moves goin out should not be changes, that would require the protocool to be state aware, and bug prone (The IM would have to remember what each player already knows).

No keep it simple: Moves going out should be all visible squares.

Well, WinBoard is intended to be the IM, of course.

I don't see much problems with state-awareness, but I guess sending a complete FEN after each move is a practical solution in any case. Commands to send a board are already defined in the protocol, so the only thing we have to do is extend their use to another context.

Let's do it this way: In stead of a move WB will send the string dark to the engine. (So this could be the command usermove dark if the engine has defined feature usermove=1.) This tells the engine the opponent has moved, but does not reveal anything about what he moved. (Which, after all, could remain completey hidden.)

After each move, WinBoard will send a setboard command to both engines, each with a complete FEN, for a position from which all invisible opponent pieces, and all own pieces have been removed. From the fact that one of the sides has no pieces a Dark-Chess engine should conclude this is just an info board, and not a command to set up a new board. This setboard command will be sent by WB immediately after the move, and the engine should wait for it before it starts thinking. And when the engine makes a move (sent in normal WB protocol) it should wait to it receives the info board before it starts pondering.

[hgm]

I guess I was wrong about this. When you don't give the move, you must show the engine his own pieces, to let him know if any is captured.

But it is still possible to indicate the info board by leaving out the engine's own King, as after capture of the King the game is finished, and you would not send info boards anymore.

[adamh]

#1

but I guess sending a complete FEN after each move is a practical solution in any case.

#2

I guess I was wrong about this. When you don't give the move, you must show the engine his own pieces,

I do not understand what you mean by #2. What you already said in #1 makes 100% sense: If you are consistent with #1 what is the addition of #2 ?

Another hair splitting problem to address is en passant captures. Either you inform the player beforehand that "x e.p." is available, which requires protocol extensions , or you simply handle it like 0-0&0-0-0
where there is no preexisting information but, the player will have to try it to see if it is legal...