Combined variants #28
Comments
|
Many of such variants should work out of the box (i.e., by just defining the variant in variant.cpp without additional implementation work), e.g., I assume for "Caparandom-zh" that should be the case. Combinations of Crazyhouse and S-Chess might also work, since I tried consider that during the S-Chess implementation, but I am pretty sure a few small fixes might be required since dropping and gating have quite some overlapping code. I added a few hybrid variants on branches a while ago, e.g., 3check-crazyhouse and anti-losalamos, mainly for the purpose of trying to weakly solve variants. I currently do not really want to add too exotic variants to master, since there are just too many possible combinations to add. Moving the variant definition to a configuration file loaded at startup (as in Sjaak or fairymax) instead of the compiled |
|
Agreed. The configuration file approach would be awesome. |
|
I tried the workaround and created Capahouse here https://github.com/gbtami/Fairy-Stockfish/commits/capahouse |
|
@gbtami If there are a handful of variants that you would like to support on your server, I have no problem with adding them on my side too, I just do not want to add random hybrid variants that are then not seriously used by anybody. Capahouse seems quite interesting, will you keep it or is it just for testing? In the log I see that the skill level was set to 16, so it is expected that SF makes suboptimal moves. The comparison of the PV and the bestmove confirm that this can only be caused by skill level, since in case of skill level = 20, PV and bestmove are always consistent. By the way, with the current code it could theoretically happen that SF crashes on a variant like Capahouse, since at the moment the move list is limited to 512 and I guess that capahouse might exceed this (e.g., 7 piece types x 80 drop squares = 560) in rare cases. |
|
Yes, I plan to keep Capahouse. Unless it proves to be unplayable because of huge favor for one or other side it seems viable. S-chess house and 960 are the combinations I'm thinking about yet. But these doesn't seem as trivial as Capahouse. Thx for remembering me the skill level. I missed that, sry. Coming from Python I would never think lists can be limited :) |
|
They are just playing it right now! https://www.twitch.tv/okeizh |
|
I have not tried combining zh and seirawan yet, but I think it might be dominated by zh, which could make it too similar. Dynamic containers (e.g., vectors) are too slow in the case of the move lists and since it is currently stored on the stack, increasing the size of the move list also requires a bigger stack size (since up to MAX_DEPTH = 256 instances of the move list are in memory), but increasing it should not really be a problem. I will then add Capahouse soon. |
|
Since it was quite easy to construct positions with more than 512 moves, I doubled the move list to 1024 in the capahouse implementation. |
|
Cool, thx! |
|
Thanks you two for making capahouse a thing! Yasser Seirawan will be thrilled when he hears of it. I messaged him on lichess. I've done a capahouse stream (okeizh on Twitch) with Jarl Carlander & the (standard lol) crazyhouse world champion opperwezen which was lots of fun. Jarl also has been streaming this on JarlCarlanderBughouse on Twitch. This was the VOD: I'll be back home in September and hoping to organise some more team capahouse events. s-chess house would also be incredibly interesting if it were not too complicated to implement. |
|
@okeizh Thanks for the feedback, it's nice to hear that the variant is taken up so quickly. Regarding "s-chess house", to me the combination is less obvious than for capahouse, since capablanca chess and crazyhouse are basically orthogonal changes compared to standard chess, whereas s-chess and crazyhouse are clearly interfering. So we would first need to clarify the rules (or agree that we take what is easiest to implement 😉), e.g.:
|
|
Good question! It would seem to me that gating pieces and drop pieces should be separate pockets to avoid any of these interference issues. Also, any similarity to crazyhouse or capahouse is not necessarily a bad thing. It is still fundamentally a different game because of the new pieces from crazyhouse and the different board size from capahouse. It will still be the same players who are likely to play all three variants but the attraction is that it is something fresh and unstudied so people aren't repeating memorised lines. Also with the new pieces players need to develop new piece pattern recognition of how pieces coordinate with each other. It may be that s-chess house isn't viable because White has too great an advantage from moving first in which case some kind of handicap might be considered such as Black having an extra gate or drop piece. |
|
From the implementation side it would be preferable to have them as one pocket, firstly because that is simply how it is implemented so far, and secondly because it otherwise would complicate the FEN, since de-facto standard to use the same square bracket notation for the pocket in crazyhouse and s-chess, and having two separate pockets would need a new notation (or at least concatenation of the two). I fixed a few issues with the encoding of gating squares in the FEN to get a first experimental implementation of seirawan-crazyhouse (I called the variant shouse for short) in Fairy-Stockfish with the following rules:
|
|
Seirawan-Crazyhouse is a cool hybrid for sure. As you guys may already know, many wants S-Chess for lichess. But the devs seems hesitant. |
|
That seems to work so long as a hawk and elephant not gated can't then be used later as drops anywhere on the board. |
|
With these rules they can (even from move one), because there is no distinction between between pieces for gating and for dropping. |
|
Added to https://pychess-variants.herokuapp.com/ |
|
Fixed some bugs on the site. I think it follows above rules now. |
|
In the meantime I merged the S-house implementation to master. The implementation for parsing of variants from a configuration is already working with branch variants_ini (you only need to set the UCI option "VariantPath" to the path of your INI file, see variants.ini as an example), but there are a few things that are missing before I can merge it:
|
|
The implementation on branch variants_ini should be fully functional now, only the documentation of the options is very limited (I only have some examples in the variants.ini). I have not merged it yet, since I have only done limited testing so far (I only checked that perft for minishogi, 3check-crazyhouse, and anti-losalamos is correct), but if you like to test it, feel free to do so. Feedback would be very welcome. |
|
Will try it. Thx! |
|
I added one more feature which should be very useful especially with respect to combined variants: You can now use an existing variant, either pre-defined or in your INI file, as a template for new variants. This would make adding capahouse (if it was not already there) only a matter of seconds: |
|
Variant configuration file feature merged in 772eb6c. I will open a new issue for the documentation on the configuration options. |
|
@ianfab I find a paragraph in http://www.seirawanchess.com/ about bug that explains the intent of Yasser. I agree that implementing different pockets for gating/dropping seems rather complicated, but maybe introducing something like |
|
@gbtami That is of course a more natural way of merging drops and gating, so I am not surprised to read that. However, to me the two pockets are not only problematic for the implementation in the engine itself, but also for the FEN definition, and GUIs/server (as well as OTB play). Currently I see it as impracticable considering the required effort for such a niche variant. |
What do you think about adding combinations of some base variant + chess960 + zh?
Something like Seirawan-zh, Seirawan960-zh, Caparandom-zh. It would be fun IMO.
The text was updated successfully, but these errors were encountered: