CECP: Chess variants with dice

[Werner Taelemans]

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

[hgm]

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.