@ianfab - would you mind contacting me?

[alexobviously]

Hi, sorry for leaving an issue here but I couldn't find an email address for you anywhere. I was wondering if you could send me an email at iamalexbaker@gmail.com - I'm working on this repo for Zied (pychess integration) and I have some questions, if you don't mind talking to me? Would be much appreciated!

[ianfab]

Please note that if the goal is to support Musketeer chess on pychess, then any work on this repository is wasted effort, because this project will not be used on pychess, it just serves as a standalone engine for Musketeer chess. The reason is that on pychess the engine (Fairy-Stockfish) is not only used for game play, but also for all the game logic itself. Therefore, an engine providing variant support for pychess like Fairy-Stockfish needs to provide a lot:

• engine for game play and analysis
• python binding for server side chess logic
• WASM port for future local analysis
• potentially a Javascript binding for frontend usage

Since it is a disproportionate effort to maintain all of this twice (not even mentioning the maintenance overhead for pychess itself), a variant realistically only has a chance to be included if it is supported by Fairy-Stockfish. Therefore, https://github.com/ianfab/Fairy-Stockfish/issues/32 is the relevant starting point.

Also note that Fairy-Stockfish has a completely different design with respect to variant support than this project, so the code can not be re-used (well, maybe 1%) and it needs to be implemented from scratch in Fairy-Stockfish. Therefore, studying this project can at best give some ideas and serve as a reference implementation for testing, but that is basically all. I need to repeatedly mention this because Zied's narrative of "merging" this project into Fairy-Stockfish is highly misleading for people who are not that familiar with these two projects.

[musketeerchess]

Hi Fabian, Alex It'll be nice if we can work together to make the default Fairy-Stockfish accept Musketeer Chess as part of the default Chess Variants.

[alexobviously]

Hi Fabian, thanks for the reply.

Yeah, I figured out (the hard way) that this wouldn't be particularly useful if the objective was to integrate it into the production branch of pychess, after spending a significant amount of time looking through the pychess code before realising everything of value is in fairy-stockfish.

I have discussed this with Zied and explained that's it's virtually impossible to merge the two, so essentially our current conclusion is that the Musketeer server should be considered a completely separate entity to the main line of pychess, since it will be hosted on a separate server anyway, and like you've said elsewhere, Musketeer has some features that are so significantly different to any of the other variants (mainly the prelude, and the gating is also tricky, and there are some other minor things such as the piece symbols being two letters long etc). Currently I have your Musketeer-stockfish hooked up to pychess to generate moves, and I implemented the rest of the basic things (i.e. not the prelude) in python temporarily while I was figuring the rest out. I came to the realisation that a lot of stuff was missing and it wouldn't work like I hoped it would, and so here we are.

Of course, like you also noted, this comes with the (in my opinion) huge disadvantage of not receiving updates for the main branch of pychess. So if there was a way to get Musketeer included in actual pychess I think that'd be better.

So I saw you started on this - https://github.com/ianfab/Fairy-Stockfish/tree/musketeer. Are you still working on this or not? (And if not - why? Not a criticism, I'm just wondering if there are any major hurdles I should be aware of). From what I can tell you got gating working but it looks like it's still a way off, right? I'm just trying to figure out the feasibility of me potentially continuing what you've started there vs continuing a custom implementation of pychess that won't be compatible with the rest of pychess, and would appreciate your thoughts.

(Also - would having Musketeer included in the main branch of pychess complicate maintenance for you (of everything else)?)

On Thu, 23 Jul 2020 at 20:20, Fabian Fichter notifications@github.com wrote:

Please note that if the goal is to support Musketeer chess on pychess, then any work on this repository is wasted effort, because this project will not be used on pychess, it just serves as a standalone engine for Musketeer chess. The reason is that on pychess the engine (Fairy-Stockfish https://github.com/ianfab/Fairy-Stockfish) is not only used for game play, but also for all the game logic itself. Therefore, an engine providing variant support for pychess like Fairy-Stockfish needs to provide a lot:

• engine for game play and analysis
• python binding for server side chess logic
• WASM port for future local analysis
• potentially a Javascript binding for frontend usage

Since it is a disproportionate effort to maintain all of this twice (not even mentioning the maintenance overhead for pychess itself), a variant realistically only has a chance to be included if it is supported by Fairy-Stockfish. Therefore, ianfab/Fairy-Stockfish#32 https://github.com/ianfab/Fairy-Stockfish/issues/32 is the relevant starting point.

Also note that Fairy-Stockfish has a completely different design with respect to variant support than this project, so the code can not be re-used (well, maybe 1%) and it needs to be implemented from scratch in Fairy-Stockfish. Therefore, studying this project can at best give some ideas and serve as a reference implementation for testing, but that is basically all. I need to repeatedly mention this because Zied's narrative of "merging" this project into Fairy-Stockfish is highly misleading for people who are not that familiar with these two projects.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/9#issuecomment-663002774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATCQWEXSN7F34XCO22DS2TR5A2KLANCNFSM4PEREORQ .

[alexobviously]

Hi Fabian, Alex It'll be nice if we can work together to make the default Fairy-Stockfish accept Musketeer Chess as part of the default Chess Variants.

Ah, hi Zied, I didn't see that you'd replied before me. I agree, that would be nice. I'll try to figure it out with Fabian and see if there's a feasible way to do that.

[musketeerchess]

Hi Alex, Fabian,

Can Fabian explain the main differences in the source code between Musketeer Stockfish (compared to Seirawan Stockfish and Fairy Stockfish) and why only 1% of the code is the same !

Apart from the fact that Fairy Stockfish has in it many variants programmed, the differences with Musketeer Stockfish once the Gating and Piece Selection phase is finished, i don't understand the difference between Seirawan / Musketeer and Fairy Stockfish. It could be helpful to have the source code for Seirawan Stockfish !!

Naturally, Musketeer Chess is more complicated than Seirawan Chess (more pieces, the Piece Selection and Gating Selection). But once the new pieces have joined the game the games are "almost" identical, apart from the bigger choice of pieces (which implies a specific rule for Pawn promotion).

Here are my first thoughts and steps i'm sure will be helpful:

First, adding the pieces. Take into account that the number of pieces can be much higher than the current 10 pieces, so figuring out from the beginning a way to add more pieces is probably the way to deal with this particular feature.

Second: Consider Musketeer Chess as Seirawan Chess with 10 possible different pieces. So at first forget about the Gating Selection. Focus on the following: Allow both sides to choose among the possible 10 pieces for white who begins, then it's Black turn to choose among the remaining available pieces (=n-1). Allow also the possibility for Black to choose among the same basket of pieces (no restriction = black can also choose from 10 different pieces). So set this as default, and add the possibility for a different game (Default Musketeer = Black choses from n-1 pieces) and Evolution Musketeer (black choses from n pieces).

Once you Made the Seirawan-Musketeer Variant working, it'll be easier to work on the Gating Selection Part.

Best regards and thanks to both of you for making my dreams possible.

Zied

Le ven. 24 juil. 2020 à 11:31, Alex Baker notifications@github.com a écrit :

Hi Fabian, Alex It'll be nice if we can work together to make the default Fairy-Stockfish accept Musketeer Chess as part of the default Chess Variants.

Ah, hi Zied, I didn't see that you'd replied before me. I agree, that would be nice. I'll try to figure it out with Fabian and see if there's a feasible way to do that.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/9#issuecomment-663567652, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HOS27RVAZRHXI42RS3R5GLLPANCNFSM4PEREORQ .

[alexobviously]

Can Fabian explain the main differences in the source code between Musketeer Stockfish (compared to Seirawan Stockfish and Fairy Stockfish) and why only 1% of the code is the same !

Although I do think 1% is a slight exaggeration, he is definitely correct in saying that they are not particularly similar systems.

Think of it like this - Musketeer-Stockfish is a system that has the primary function of generating the best move for a given position, only for the Musketeer variant. So all of the intricacies of the game are woven together. It doesn't take into account that some of the features of the game might not be present, and it doesn't take into account how some might behave differently if others are present.

Fairy-Stockfish, in contrast, is a generalised system. You can think of it like it assembles the game logic for a variant based on a set of definitions. So we have a data structure defining the rules for your variant, does it have gating, does it have en passant, what pieces are there, etc. This defines which parts of the code are turned 'off' and 'on'.

So now you're thinking: "well if it's just a matter of discrete features then why can't we just copy the Musketeer-specific features from Musketeer-Stockfish?", which is a good question, but it's not that simple for two reasons. Firstly, they are not set out as 'features' as such in M-S, it's not possible to just isolate the bit of code that deals with the fixed gating, for example, paste it into F-S and add some variables that control it. Secondly, all of the features affect each other.

A simple example: in Musketeer there is a special kind of gating where the square the piece falls on is fixed from the beginning of the game. This doesn't exist in any other variant, so it also doesn't exist in the FEN representation. Now there are many parts of the F-S code that handle FEN in some way, and they currently do not take into account the possibility of the extra gating rows; therefore all of these parts need to be changed. So not even implementing the gating itself, but making the rest of the code take into account that it exists (and not even that, but just the FEN part), is not even trivial.

It could be helpful to have the source code for Seirawan Stockfish

It's in Fairy-Stockfish, but I think this demonstrates the problem quite well - there is no isolated Seirawan-Stockfish code. Rather, there is Fairy-Stockfish, configured to run the Seirawan rules. For the same reason that you can't 'extract' the Seirawan logic from F-S, we also cannot 'insert' the Musketeer logic like that.

Implement Seirawan-Musketeer

I think this could be a good idea, depending on where Fabian got to with his implementation of Musketeer in F-S.

I'm not trying to say this is impossible or to discourage you at all by the way. It's definitely possible, I'm just trying to explain why it's more complicated than you think. And I do understand why you thought that way, because I also made the same assumptions when I first looked at pychess!

[ianfab]

@alexobviously Thanks, I think that is well explained.

The 1% was referring to the changes compared to official SF. The code from official SF itself of course is shared, but the changes on top of it are almost entirely different. Actually, Musketeer-SF was split out from Fairy-SF at a very early stage of its development, but so early that basically everything is different now.

For the sake of nitpicking, there is a Seirawan-Stockfish code base (there also are Makruk-SF and Shatranj-SF, see my profile), but it was before Fairy-SF and these multiple SF variant forks were the motivation for starting Fairy-SF to have them all in one code base for less maintenance effort and more flexibility.

Regarding the development branch https://github.com/ianfab/Fairy-Stockfish/tree/musketeer, I did not stop working on it, but there are many other topics I am working on at the same time, so I rarely get to actually working on it. The branch is highly experimental, it is nowhere near a working implementation and mainly outlining how to implement the gating on top of S-Chess gating.

[alexobviously]

@ianfab Did you have any preliminary ideas of how the prelude phase should be implemented? This is the thing that is most problematic to me, since it doesn't really resemble anything in any other variant (afaik).

So if I were to continue what you've started with the view of implementing Musketeer fully and it being integrated into fairy-stockfish, would you be okay with that? After all, it is your project. And would you have some time occasionally to support me? - maybe I'll need some explanations here and there about how certain things work, since it is a fairly complicated system, and to review what I add?

[ianfab]

I do not plan to implement the setup phase in Fairy-Stockfish, since this would most likely massively complicate maintenance. For a possible implementation in pychess, game play would probably work similar as for Janggi, where the prelude is handled without the engine, and the engine just gets the resulting starting position after the prelude for starting the game and takes over from there.

Contributions of any kind are of course always welcome. I however can not guarantee that a specific PR will be merged, because in the end the tradeoff between the value of a feature and its maintenance overhead needs to be evaluated individually for every feature/PR, which for some features is even more relevant than the implementation effort itself. And a possible integration into pychess of course also depends on gbtami, as he needs to take a similar decision for the pychess code, but the implementation in Fairy-SF is of course a prerequisite.

[raphaeleliekakou]

Hi The Piece Selection and Gating Selection are right now special features of Musketeer Chess.

The difference between Seirawan Chess and Musketeer Chess are more possible pieces, thus the piece selection phase and the way the added pieces are gated: they are not in hand, the gating squares are defined before the classic pieces begin the game.

Tests before Musketeer Stockfish using Deuterium engine specially tuned for Musketeer Chess and after that Musketeer Stockfish have confirmed my first assumptions when building the rules: these two features not only provide a wide variety of possible opening positions but also having the Gating Squares known for both sides levels the game between White and Black with Almost equal winning chances (almost 35% for both sides) and makes draws as low as 10%.

For the moment these parameters are not included in any other variant. I think this can change in the future.

What could be done and this probably will seem logical probably for the programmers Is as follows: the Piece Selection and Gating Selection can be programmed among the main core of the engine. Then for each variant two code lines are added: allow_ps and allow_gs which refers that the variant involves a piece selection phase among a basket of possible pieces, then these pieces can be dropped or Gated according to Preselected squares.

This part can be:

allow_drop etc.

Just ideas.

What do you think about these ideas?

This will probably not only easy programming for Musketeer Chess but also any new feature, regulation etc could be added as mentioned above with access to part or not of the code depending on the rules of the variants.

Thanks for your attention

Zied

Le 4 août 2020 à 16:44, Fabian Fichter notifications@github.com a écrit :

 I do not plan to implement the setup phase in Fairy-Stockfish, since this would most likely massively complicate maintenance. For a possible implementation in pychess, game play would probably work similar as for Janggi, where the prelude is handled without the engine, and the engine just gets the resulting starting position after the prelude for starting the game and takes over from there.

Contributions of any kind are of course always welcome. I however can not guarantee that a specific PR will be merged, because in the end the tradeoff between the value of a feature and its maintenance overhead needs to be evaluated individually for every feature/PR, which for some features is even more relevant than the implementation effort itself. And a possible integration into pychess of course also depends on gbtami, as he needs to take a similar decision for the pychess code, but the implementation in Fairy-SF is of course a prerequisite.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ianfab]

Well, the point is that

the Piece Selection and Gating Selection can be programmed among the main core of the engine

is the critical part. Adding options to enable/disable features is rather easy, but it does not help in any way to implement the feature itself in the first place.

PS: Why is Zied commenting from this account?

[musketeerchess]

Hi, I was no longer subscribed and Raphael my elder cousin transferred this email to me.

I was following the conversation and probably when Rapha joined it was when he was visiting before the Covid period. I think he has inadvertently interrupted my Watch of the Fairy Stockfish repository when he subscribed himself to watch it.

I will do what’s necessary again to be subscribed.

I’m working to help fight covid-19 in french carribean islands for a month and as a retired military he is my neighbour in the next house. We discuss together each day and i must assume that he used to be one of my patients during this pandemics. He almost passed away, fortunately, he is a strongman. this awful disease weakened him so much but he is still standing for himself and his family

Zied

Le 5 août 2020 à 02:42, Fabian Fichter notifications@github.com a écrit :

Well, the point is that

the Piece Selection and Gating Selection can be programmed among the main core of the engine

is the critical part. Adding options to enable/disable features is rather easy, but it does not help in any way to implement the feature itself in the first place.

PS: Why is Zied commenting from this account?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[alexobviously]

Hey, sorry - I really thought I'd replied to you immediately actually. Anyway, I've been playing with your code since your last message and although I feel this is still a monumental task, it feels more doable now I roughly understand the point of everything.

I do not plan to implement the setup phase in Fairy-Stockfish, since this would most likely massively complicate maintenance. For a possible implementation in pychess, game play would probably work similar as for Janggi, where the prelude is handled without the engine, and the engine just gets the resulting starting position after the prelude for starting the game and takes over from there.

Yeah, I totally agree and in my initial tests I did that too. I just wasn't sure that you and Tamas would approve of what is ostensibly game logic outside of fairy-stockfish (I didn't notice Janggi had a prelude stage until recently), so it makes my life easier that you do!

Contributions of any kind are of course always welcome. I however can not guarantee that a specific PR will be merged, because in the end the tradeoff between the value of a feature and its maintenance overhead needs to be evaluated individually for every feature/PR, which for some features is even more relevant than the implementation effort itself. And a possible integration into pychess of course also depends on gbtami, as he needs to take a similar decision for the pychess code, but the implementation in Fairy-SF is of course a prerequisite.

Right, well I'll talk to Tamas, and I'll carry on with what I'm doing and when I've got a basic working implementation I'll let you know so you can see what you think needs to be done for it to be merge-worthy.

[ianfab]

Sounds good. For further discussion directly related to Faiy-Stockfish let's use https://github.com/ianfab/Fairy-Stockfish/issues/32. For now I am closing this.