Question to Remi about CrazyZero

[hgm]

In the blitz-tourney thread you wrote this:

Thanks for organizing the tournament. CrazyZero is my generic AlphaZero implementation (I currently have networks for Go, shogi, gomoku, Othello, renju, and chess). I spent only a few days training a network. It is 20 layers of 128 units. It was running with two Volta GPU (V100 + TitanV). It has good positional evaluation, but big tactical blindspots.

I wondered if it would be reasonably easy to have CrazyZeroplay Paco Shako. This is a Chess variant with the unique property that instead of capturing each other, pairs of opposing pieces can coexist ('embracing each other') on the same square, dragging each other along as they move, but unable to 'capture'. They can be liberated from an embrace only by a lone piece of the same color jumping into their square, after which they have to move away in the same turn, possibly releasing another piece from an embrace, so that you get move chains.

The interesting thing is that no one really has any idea how it should be played. The game is won by embracing the opponent's King, but like checkmate in orthodox Chess this goal is usually far beyond the horizon. Because all material stays on the board, embracing or not, there is no obvious intermediate goal, like improving material balance is in most forms of Chess.

So it would be very interesting to see what a NN-based engine makes of this. A possible implementation would use a 'two-level' 8x8 board, one level for the white and another for the black pieces. (I used this in the 'demo' diagram against which one can play at the URL I gave above, which plays mostly randomly unless it foresees a King embrace.) The chain moves are tricky, though; when treated as separate turns (during which the side-to-move doesn't change, or, alternatively, the opponent has a forced null move until the chain terminates) it would make for very deep tactics once the density of embracing pairs gets large (and the move chains start to branch rather than fizzle out quickly). Which is probably not good for the Alpha-Zero approach. But a move generator could be written in such a way that it considers chain moves that embrace the King as a single move. (The board state after that doesn't matter anymore.) This should at least enable the NN to learn what intermediate goal it should adopt to maximize its chances to find a King-embracing move.

[Rémi Coulom]

Hi,

Thanks for the suggestion. That looks like a fun thing to do, but I am busy with many more important projects.

In order to support another game, I would have to program the rules, as well as network input encoding and output decoding. And it would take 2-3 days of calculation to get a reasonable player. That's still a lot of work.

I am considering making it easier to support game variants, by implementing parameterized rules. Then I would only have to indicate board size, piece types, initial position, and a few other parameters to support a new variant. Is there a formal description language for rules of chess variants? That would be nice to have.

I am surprised that so few people make their AlphaZero implementation game-independent. Very little of my code is game-specific. If I understand correctly, Leela Zero and Leela Chess Zero have become a fork. They would probably have made faster progress together if they had kept the same code for both games.

I believe Facebook's open-source ELF framework was designed to support multiple games:
https://github.com/pytorch/ELF/blob/master/README.rst
But I don't know how difficult it would be to make it support another game.

[hgm]

Is there a formal description language for rules of chess variants? That would be nice to have.

Last year Greg Strong and I agreed it would be nice to have such a thing, and that we should take it up with other people for whom this could be relevant (Evert Glebbeek, Daniel Shawul, Fergus Duniho). Unfortunately I have been so busy with other things that I never got to do that.

The various configurable variant software (Fairy-Max, ChessV, Sjaak, Nebiyu, Game Courier, Zillions of Games, Jocly) all use completely different rule-description formats. In addition there also is the format CECP uses to transmit game rules from engine to GUI. This uses a 'setup' command with the board and hand size, a FEN of the initial position, and the IDs of the participating pieces needed to interpret it (associating them with GUI images). In addition the engine can send for each piece a description of its move, in Betza notation. This gives only a partial description of a variant (but enough for the GUI to highlight moves and generate properly disambiguated SAN); other rules, like winning condition, are inherited from one of the standard variants that is designated as 'parent variant'. And in CECP an engine can always claim game end when it occurs.

For 'regular' variants, i.e. those that only differ from orthodox Chess by board size, number of participating pieces, and how they move and capture, and what the result for checkmate or stalemate is, it is easy to parametrize them. Many variants have some unusual rules, though (like in Shatar, where a checkmate is only a win if it was preceded by a sequence of checks from particular pieces, or in Makruk, where the '50-move rule' depends on the material you have after baring the King). There is a sheer infinite number of possibilities there, and parametrizing that seems a hopeless endeavor.

[Gian-Carlo Pascutto]

If I understand correctly, Leela Zero and Leela Chess Zero have become a fork. They would probably have made faster progress together if they had kept the same code for both games.

Most definitely. There's several things implemented in one engine that aren't implement in the other, both ways. Forking certainly wouldn't have been my choice!

In defense of the people that wrote the lc0 client, the original Leela Zero code had no provision for batching as batching didn't really help much for 19x19 Go (certainly not if you don't need to depend on cuDNN!), but the smaller size of the chessboard made that performance penalty much bigger. So when someone comes along with a rewrite with a TensorFlow backend that supports batching and is able to commit a lot more time to work on chess specific things for the client side, it's an understandable decision. It is always easier to do major work on your own code than someone elses.

It has more to do with what some volunteer contributors are realistically able to do rather than with sane engineering decisions.

[Daniel Shawul]

I was tinkering with making nebiyu work with neural nets past couple of days and i think i've succeeded now -- though i still have to train nets for the games it supports. I had to move all the chess specific logic out of the neural network trainer and prober code. Egbbdll has effectively become a general tool for probing any neural network by specifying input nodes and shapes, and output node names. However, the value and policy heads are still baked into it at the moment but I would like to remove them later. The input and output nodes are fed to it via strings like:

input_layer: "main_input aux_input"
output_layer: "value_head policy_head"
input_layer_shape: "24 8 8 5 1 1"
ouput_layer_shape: "1 1 1 4672 1 1"

The moves are encoded on the client side (not egbbdll) and sent to egbbdll during probing. Egbbdll then fetches the policy probabilities of those moves and returns it to the client. Maybe it will be better to just return the buffers to the outputs directly ?

The trainer now does not use FENs to construct input planes (since I would need to code game logic on the python side as well). It just accepts a run-length-encoded input planes directly.

How to handle holdings and other weird stuff f.i. ultima I have not thought about well enough.

[Evert]

Last year Greg Strong and I agreed it would be nice to have such a thing, and that we should take it up with other people for whom this could be relevant (Evert Glebbeek, Daniel Shawul, Fergus Duniho). Unfortunately I have been so busy with other things that I never got to do that.

The various configurable variant software (Fairy-Max, ChessV, Sjaak, Nebiyu, Game Courier, Zillions of Games, Jocly) all use completely different rule-description formats. In addition there also is the format CECP uses to transmit game rules from engine to GUI. This uses a 'setup' command with the board and hand size, a FEN of the initial position, and the IDs of the participating pieces needed to interpret it (associating them with GUI images). In addition the engine can send for each piece a description of its move, in Betza notation. This gives only a partial description of a variant (but enough for the GUI to highlight moves and generate properly disambiguated SAN); other rules, like winning condition, are inherited from one of the standard variants that is designated as 'parent variant'. And in CECP an engine can always claim game end when it occurs.

For 'regular' variants, i.e. those that only differ from orthodox Chess by board size, number of participating pieces, and how they move and capture, and what the result for checkmate or stalemate is, it is easy to parametrize them. Many variants have some unusual rules, though (like in Shatar, where a checkmate is only a win if it was preceded by a sequence of checks from particular pieces, or in Makruk, where the '50-move rule' depends on the material you have after baring the King). There is a sheer infinite number of possibilities there, and parametrizing that seems a hopeless endeavor.

It may be worthwhile to have another go at finding a suitable format. All variant software you mention works differently internally (F-Max is mailbox, so, I think, is Nebiyu; Sjaak/SjaakII is bitboard; ChessV can (could?) be either; Zillions is a fully scriptable environment that is probably also some flavour of mailbox internally) and there is no format that is a natural default fit for all of them. Which is good in a way.

What I would want from a variant-description format is the following:

• The ability to add comments in the file. I prefer # as the comment indicator.
• The name of the variant (full name and short name for CECP)
• The size (and topology) of the board and holdings.
• Start position in FEN format.
• For each piece: the abbreviation used in the FEN string, the move description in Betza notation, promotion zone and choices (optional, default: none), demotion options and conditions.
• A way to toggle common rule options: Can you drop pieces with check? With mate? Are you allowed to chase? Is there a baring rule? As you say though, there is an infinity of rules like these and it's unworkable to define all of them up front, or demand that different engines implement all of them. A reasonably common subset could be thought of though.
• Some way to send "meta" or engine-specific information to different engines. Yeah, it somewhat undermines the engine independent aspect of it, but it allows for specific engines to take advantage of options that they do have.

What I also like to have is what character to use for a piece in SAN; that's almost the same as the abbreviation in the FEN string, but not quite (for pawns it's different). That's mainly because I use my programs from the command-line a lot and I prefer looking at SAN there.