Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fairy adaptation - Draft Request #229

Open
wants to merge 18 commits into
base: master
Choose a base branch
from
Open

Fairy adaptation - Draft Request #229

wants to merge 18 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Oct 14, 2021

Purpose

Requesting this code to become a draft for an adaptation to accept all the Fairy-Stockfish variants. Including custom variants from the ini file

Main Ideas from my TODO file:

Adaptation of Liground for Fairy-Stockfish

List

  • Explore the Chessgroundx 8.3.0 to the point I am comfortable with it
  • Adapt Chessgroundx 8.3.0 for all the possible boards (12 to 1 both files and ranks)
    • Option 1: Caveman code, insert all manually
    • Option 2: Besides the existing code on chessgroundx, add a potential calculator for board size and heights
    • Option 3: Generator of boards in the constructor
    • Option 4: Maybe just add a 12x12 board and fill the void squares with "bricks"
  • Merge the changes for the Chessgroundx 8.3.0 adaptation to the current code
  • Figure out a better way of having Fairy-Stockfish only loading the local variants.ini file (Low priority) - and have the engine auto-load the variants
  • Reformulate the promotions to be based on legal moves available instead of the pre-programmed promotion tables (this will work nicely with Gating, and perhaps cause troubles to variants such as Kyoto)
  • Have a piece "detector" everytime they're played, e.g. a variant with hidden pieces, the "detector" will add them to the database using the generic graphics, afterwards that piece will be available for customization (graphics)
  • Piece Mapper and dynamic CSS for each variant - Once a new variant is added they will use the generic models (including xiangqi using chess pieces if that's the case, up to the user to gather the required piece)
  • Consider whether or not the promoted piece svgs should be added to the pockets or not
  • Dynamic pocket handler

Afterwards - variants.ini Workshop

  • Have all the available options from the variants.ini file (Possibly think of a way to dynamically get Fairy's options based on ffish.js or pyffish modifications)
  • Size Validator (Ranks <= 10, Files <=12)
  • Check for mutually exclusive options
  • Graphical Board picker (Shogi, Xiangqi, Janggi, Chess, Makruk)
  • Board Tester (Perform a check variants.ini operation before the test)
  • Piece Tester (Create a temp variants.ini file with just the piece on the board, and abuse ffish.js to generate it)
  • Betza reader to Graphics using arrows (Very hard)
  • Betza editor for each custom piece added, the betza editor's idea is to purely add movement based on arrows and pointers from chessground (Very hard and will be looked at the end)
  • Common options for variants

Ambitious Plans

  • Ability to have a match against the computer (with premoves disabled)

Graphics

  • Get SVGs for the whole alphabet in order to have generic pieces available (Merida only for now as generic)
  • Get SVGs for the promoted pieces (whole alphabet)
  • Dig deeper into VUE's graphical abilities

Technical

  • Possible way to have ffish.js dynamically loaded instead of using the default one (in case of code testing)
  • Look at ffish.js code and try to add PGN Support
  • Definitely work on pyffish' Board support
  • Look into the xboard display (e.g. xboard -> variant shogun displays all the details, pieces) Possibly implement that into ffish.js and pyffish

Annoyances

  • Figure out why variants with '-' do not work properly

Overall comments

This has been discussed on Fairy-Stockfish' discord, and would be great to have a generic GUI (when it comes to what ffish.js can handle or not) that could support all the variants there (including the custom ones written on the variants.ini file).
The ideas above are currently a dream that we all wish to come to life.

Current state with the code

At the time I wasn't aware of the VUE syntax on compilation time so it's only running on dev mode.
There are two additional buttons (simple ones) to link ffish.js to the variants.ini file defined by the user, and a refresh button (that needs to be done on our Fairy-Stockfish everytime it launches in order to refresh the variant list on that engine - important note it only uses the variants.ini file within the same directory of the engine)
The current code uses the merida pieces as default for all variants (a way of simplifying in order to test everything). I've added a lot of pieces (taking SVGs from both pychess and vchess) to the whole alphabet, including simple modifications using Inkscape for the promoted versions.
I've modified the code to accept custom promotions (I'm well aware that I've missed something in it) but overall it's working reasonably. Even accepts gating on seirawan.
The current pockets are not generic and have been unmodified (Xiangqihouse and Janggihouse even worked to a certain extent with some missing pieces)

Ideas already mentioned above:

  • Have the user be able to define the SVGs for all the pieces within the variant (and using the generic pieces by default when not defined) (mentioned by @ianfab on Fairy-Stockfish discord)
  • variants.ini workshop (I absolutely love this idea from @ianfab ) let the user define a custom variant inside the GUI, with all the options available
  • (Possibly modify ffish.js to read all the current options that Fairy-Stockfish has, in case of new code)
  • (Also a possibility to have a test board after defining such a variant, and maybe define piece movement with the arrows, generating Betza code)

Notes

I am terribly sorry for dragging this out for way too long. You are all awesome

@QueensGambit
Copy link
Collaborator

Great thanks for your on progress on this and your detailed TODO list. 👍
I will know in the beginning of November, if there is a new group of students willing to work on LiGround for one semester.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant