CECP: Chess variants with dice

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, Dann Corbit, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
Werner Taelemans
Posts: 104
Joined: Mon Feb 03, 2014 10:57 am
Location: Belgium
Contact:

Re: CECP: Chess variants with dice

Post by Werner Taelemans » Mon May 23, 2016 12:42 pm

Werner Taelemans wrote:
Uri Blass wrote:...find after it cheat a dice number that produce the output that it tried to get.
This is supposed to be impossible, since SHA-256 is a cryptographically secure one-way function: https://en.wikipedia.org/wiki/One-way_function
Uri your right!
The first time that a number is asked, the engines can cheat. That means that at the beginning of the game the engines should send each other the 'throwdice' command to initialize the protocol.

User avatar
hgm
Posts: 25391
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: CECP: Chess variants with dice

Post by hgm » Mon May 23, 2016 2:59 pm

Evert wrote:How do you guarantee this? This mapping of piece-ID to die-roll is not public information, there is no defined standard.
Sure there is. It is part of the game rules. The Alfonso codex already describes it. In fact this was a great help to deduce how the pieces move, as the codex mentioned both the mapping explicitly, as well that the higher number corresponds to the stronger piece. Which ruled out the very weak move Murray had assigned to Lion.

If it was not known how the dice roll corresponds to piece type, how could you ever play the game with a real dice and board?

With cards, like in Raindrop Chess, it would be more tricky. But there 16 cards for each side just correspond to pieces, and it would be logical to number them P=1-8, N=9-10, ... K=16. The only problem is that the Bishop cards also specify the square shade, and it is not obvious whether the light Bishop should be 11 or 12. But I think it is reasonable to require that people writing an engine for Raindrop Chess are aware of this problem, and if really no consensus can be found equip their engines with options to use reverse card numbering (P=16-9, K=1) or reverse Bishop shading.
Implementing the relevant CECP protocol is not enough, you also need to know how other engines label their pieces.
This should indeed be standardized. Just as piece IDs need to be standardized to make the engines understand the initial setup and promotion suffixes, etc.
It's a bit similar to assigning piece-ID letters, except that it's an implementation detail that should normally be hidden from the user. Even then, I would argue that the inability of the protocol to translate piece-ID's between two engines that use different IDs is a short-coming, and something that should be avoided for extensions to the protocol like this...
Good point. Currently XBoard only looks at the setup command from the first engine, and uses the IDs that defines to send the position to the second engine. (This to allow for shuffle games, where the first engine then shuffles.) In principle it would be possible to compare the FENs of the two engines, and deduce how the piece IDs used by the second correspond to those used by the first. And then use that to translate the FEN to the system used by the second engine.

The downside would be that this fails badly in shuffle games, where both engines shuffle independently. But one could argue that the GUI should do the shuffle. Indeed I put in a (largely untested) feature that the back-rank pieces in a FEN can be enclosed by <...>, to make the GUI conclude it should shuffle them (where the presence and form of castling rights, (KQkq, HAha or -) then defines the type of shuffling).

But this basically facilitates non-compliance. Which has many detrimental effects. (E.g. the IDs defined by the first engine would be used in the PGN file as well, so what PGN you get would depend on which engine was the first.

Post Reply