Ideas

[ianfab]

additional rule configuration options

• game termination criteria
  • [x] bare king (shatranj, losers, heian shogi)
  • [x] capture the flag (king of the hill, racing kings, breakthrough)
  • [x] check count (3check, 5check, kar ouk)
  • [x] piece count (horde, extinction, giveaway, kinglet)
  • [x] checkmate/stalemate score (losers, shatranj)
  • [x] connectN
• game dynamics
  • [x] piece drops (crazyhouse, loop, chessgi, pocketknight, shogi variants [minishogi, euroshogi, tori shogi], sittuyin)
  • [x] piece drops, but captured pieces are not transferred to opponent's hand (pocketknight, bughouse, sittuyin)
  • [x] gating (seirawan)
  • [x] mandatory/prohibited captures/checks (giveaway, losers, clobber, racing kings)
  • [x] board sizes below 8x8 (los alamos, minishogi, minixiangqi)
  • [x] piece promotions, unpromotion when capturing (shogi variants)
  • [x] optional promotions (shogi variants, sittuyin)
  • [x] hoppers (xiangqi, grasshopper)
  • [x] setup-phase (or forced piece drops) (sittuyin, placement)
  • [x] restriction of piece drops to certain area, e.g., behind pawns (sittuyin, placement)
  • [x] sittuyin pawn promotion rules
  • [x] complex checkmate legality evaluation (shogi, shatar)
  • [x] do not require presence of kings (giveaway, horde, extinction)
  • [x] castling with non-king (e.g., commoner) pieces (giveaway, extinction, knightmate)
  • [x] pawns on first rank (horde, chessgi, shogi variants)
  • [x] compile-time option to enable board sizes between 8x8 and 12x10 (shogi, xiangqi, capablanca)
  • [x] generalize pawn double step option (grand)
  • [x] one-time moves (ouk chatrang)

major missing games

• [ ] Lines of action
• [ ] Game of the Amazons
• [ ] Surakarta
• [ ] Go
• [ ] Checkers

enhancements, refactoring

• [x] move variant configuration to a text/ini file
• [x] store piece movement options in piece-centric way for readablity and robustness (not performance critical as only used for bitboard initialization at startup)
• [x] reduce memory consumption of history tables (can be up to ~150MB per thread for 64 piece types)
• [x] support USI dialect for shogi variants
• [x] extend TT entry to use 32 bit int for move representation -> removes restriction on number of piece types, allows addition of new move types, e.g., for gating, and makes encoding of promotions more flexible and more performant

playing strength improvements

• [x] generic psqt formula
• [x] generic mobility bonus formula
• [x] passed pawn bonus scaled by value of promotion piece
• [x] king safety calculation considering all piece types
• [x] variant goal specific bonuses (distance from king target squares, check count bonus, etc.)
• [x] endgame eval functions for fairy pieces
• [x] speed-ups for attack bitboard generation
• [x] search adaptions for variants (e.g., pruning margins)

limitations, not doable

• boards with different topology (Hex, etc.)
• complex game dynamics (cylinder, alice, atomic(?), patrol(?))
• incomplete information (kriegspiel, dark chess)
• multimove/multiplayer variants (progressive chess, avalanche chess, four-player chess)

[thaichessswinboard]

Can you make new Variants Makwork Vs Queen or Queen Vs Makwok by make Makwok have Values more than 2 Rooks and Values More than Queen it will Work. and Promotion to Makwok or Queen by each side of Wok or Queen. It will be good fun games of Variants I think winboard can suport by use Variant Makwok. Thanks.

Pcst or

[ianfab]

@thaichessswinboard Sorry, I do not know the piece you call "Makwok". Is it what is also referred to as "Ai-Wok", i.e., the combination of rook+knight+met? And to which pieces can white and black promote exactly?

[thaichessswinboard]

Makwok and Ai-Wok it the same and pawn can promotion to Ai-wok at rank 6 for White And black can promotion to Queen at rank 3. I hope you understand.

On Thu, Jul 26, 2018 at 10:23 AM, Fabian Fichter notifications@github.com wrote:

@thaichessswinboard https://github.com/thaichessswinboard Sorry, I do not know the piece you call "Makwok". Is it what is also referred to as "Ai-Wok", i.e., the combination of rook+knight+met? And to which pieces can white and black promote exactly?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ianfab/Fairy-Stockfish/issues/1#issuecomment-408035191, or mute the thread https://github.com/notifications/unsubscribe-auth/AnxMlOVwZguKP-TiRZEB90puTVXmXgqQks5uKYqEgaJpZM4U00kd .

[ianfab]

@thaichessswinboard Ok, thanks, it is clear now. This variant also depends on the fix for issue #4 to have asymmetrical pawn promotion options for white and black.

[mineralsman]

Is it possible for this engine to handle weird-shaped boards such as:

https://en.wikipedia.org/wiki/Hexagonal_chess

or:

https://i.imgur.com/RL9mlh0.png

ps- Thanks so much for making this engine :D A friend and I are making our own chess GUI as a little project just to learn how to code and stuff. Looking forward to using your engine!

[ianfab]

@mineralsman The board configuration (both, size and connectivity) currently is the most significant limitation regarding the flexibility of rule definitions. The implementation is based on an 8x8 board, and for smaller (rectangular) board sizes some squares are excluded to simulate them. Anything else than a rectangular board of size <=8x8 is currently not supported. Smaller boards with strange shape (similar to the image in your link) might also be feasible, but large boards and boards with strange connectivity are a different story.

I would love to support board sizes >8x8, especially in order to support shogi and xiangqi, but it would require to rewrite the bitboard implementation including all the operators (and I am not necessarily an expert on that). I do not think that this is anything I can do in the near future, but I think that a reimplementation based on a 128 bit datatype would in principle be feasible and would allow for board sizes up to 12x10.

Regarding hexagonal boards, I do not see any way to support this without a complete rewrite of the board representation, so unfortunately this is out of scope for this project.

I hope this answers your questions, and if you have more questions let me know (I will also try to extend the wiki to cover more aspects of functionality and usage). Thanks for your feedback, and good luck with your GUI project.

[mineralsman]

Thanks for the info, ianfab. My friend and I look forward to putting your engine variant to good use :D Thanks again for all your hard work with it. You really seem to know your stuff re: engines, while we're focusing more on the GUI side of things. If we have some questions about engines, would it be ok if we contacted you and asked?

[ianfab]

@mineralsman Sure. For general and technical chess programming topics, the chess programming wiki (edit: updated link) or a google search should usually provide good answers (especially if it is about standard chess), but if you have more specific questions about chess variant engines, feel free to ask.

[mineralsman]

Hi, ianfab. I have a question/request. In this game of chess, in some levels they block off certain squares and make them unusable. For instance notice the pillars here:

https://i.imgur.com/NdSjjOe.png

Would it be possible to feed the engine info that it can not use squares we select? Maybe it can be done with the fencode like:

rnbqkbnr/pppppppp/8/4X3/4X3/8/PPPP1PPP/RNBQKBNR

Where "X" tells the engine it can not use those squares. This would also allow devs to set up custom boards like the one I linked in the other post (except on 8x8):

https://i.imgur.com/RL9mlh0.png

Overall it would give a lot of fun options.

[ianfab]

@mineralsman Currently excluding individual squares is not supported, but in principle it should be feasible. One question I have regarding this feature is whether sliding pieces can go over such squares or whether they are blocked just as if a piece would be on that square. Since the blocked squares should not change during a game, I would probably rather make it a property of the variant than of the position/FEN. I will add this feature to the list, but I do not have time to implement it any time soon.

[mineralsman]

hmmm I would suggest the piece not be able to slide past the square, since that would make the most sense intuitively, but either way would be good. Thanks for adding it to the list :D

[Apostolique]

I wrote the rules for my variant here: https://github.com/Apostolique/AposChess

Would it be easy to support it? Perhaps by editing some settings? I'd really like to see if it favors a certain side.

[ianfab]

@Apostolique From a brief look at the rules it has two core features that need to be supported to make it work:

• Berolina pawns
• Hopping pieces

Unfortunately, both are not supported so far. I worked on berolina pawns at some point, but especially en passant proved to be a bit difficult. I am also working on hopping pieces (mainly for the cannon in xiangqi), but it is not ready yet. So without these two features, implementing your variant is currently not feasible.

[Apostolique]

Thanks! I will be keeping an eye out on this project.

[GregNeto]

the berolina pawn would be a great addition, now that you can configure variations

[ianfab]

This thread was useful in the beginning when there were dozens of ideas for (mostly smaller) feature additions where creating a separate issue for each of them would just have been unnecessary work. But now that a large portion of the features is implemented and that most remaining features require bigger changes, I prefer to split out the requests into separate threads.

Feel free to create a new dedicated issue if you want to request or discuss one of the features mentioned in this thread.

[ianfab]

I split the remaining points out into separate issues, so I am closing this one.