Bughouse testing and playing strength

[ianfab]

• [x] Prepare test environment: https://github.com/ianfab/fairyfishtest
• Improve clock handling
  • [x] general faster play
  • [x] automatic fast play when partner is dead
• Implement handling of ptell
  • [x] sit and go
  • [x] identify whether partner is SF (otherwise disable verbose communication like clock times, etc.)
  • [x] communicate clock times
  • [x] fast/slow moving
• Improve evaluation (using two_boards() and piece_drops())
  • [x] piece values
  • [x] king safety

Split out from #60.

• FICS buttons
• Chess.com blog

[koedem]

Are you planning to support Ködem at some point?

[ianfab]

Should be rather easy at this point, of course assuming promotion like in bughouse, no piece grabbing from the partner board ("grapschen"). Feel free to open a separate issue for it.

[koedem]

I know bughouse to be played with piece grabbing too though I suppose you'll get different answers depending on who you ask.

When I was thinking about writing a bughouse engine I thought the best way would be for the engine to play both boards. While that may complicate the search strategy it should lead to much better and more coordinated play if things work as they should. Thoughts on that?

[ianfab]

To my knowledge, online and in OTB tournaments bughouse is basically always played with normal promotion rules, and piece grabbing is only used in casual OTB play. It also has the problem of synchronization of boards, since moves can get illegal while being played.

Having more information of course can only be beneficial for playing strength, but I think there are good reasons to make the engine only play one board:

• It is more flexible, since the engine can play with different partners, e.g., also human players.
• Interfaces (e.g. ICS/FICS) are mostly designed that way and you might not even be able to get the position of the second board. There could of course be a second instance of the engine that just relays the position to the main instance.
• It is more fair compared to human players if the engine can not look at and act on both boards simultaneously.

And the most important point, I think it is not required at all to reach superhuman strength. I am quite confident that once I have a bughouse testing environment in place the improvements in playing strength will be huge and reaching superhuman level will only be a matter of time. Considering that Sjeng plays bughouse on a top level but is >1000 Elo weaker than SF at crazyhouse, SF should be competitive even with just decent communication and clock management. By the way, even with the current search and evaluation not being adapted for bughouse at all, I have difficulties consistently beating it if it does not fall for an early checkmate trap, but I am a bad bughouse player anyway.

[koedem]

I agree on all points. I have witnessed pieces being grabbed from a players hand who was about to move them so that can definitely be an issue. (and while I won't name anyone, I think you can guess who that person was...) Though in practice such an illegal move could simply be voided, e.g. by giving the engine the same position with a new partner board position.

I also agree that a dual board vision will not be necessary to obtain super human strength, even in Ködem where lack thereof is an even bigger handicap. However from a "scientific" point of view this may be not as interesting. Such games would likely be won by super human tactics as well as simply the absence of blunders rather than any strategic novelties.

Although I suppose for a human like play style that can be learned from, a NN will likely provide more realistic results.

[ianfab]

In my opinion a search on the combined board state can be seen as the very last step of a continuous improvement in communication, so I think it does not necessarily need to yield a qualitatively different way of playing. I already added a very simple handshake to determine whether the partner also is SF, so based on that the engine can decide to do much more verbose communication than with a human partner, e.g., communicating clock times, PVs (or planned captures in there), etc., and ultimately it could just send the FEN.