Musketeer Chess

[Nordlandia]

As per link, just wanted to make you guys aware of this.

https://groups.google.com/forum/#!topic/fishcooking/ExQyPxKxlHs

[ddugovic]

Thanks for the information. Does this game have rules @Nordlandia ? If not I may have to close this issue.

[musketeerchess]

www.musketeerchess.net for the rules. Game based on chess with special rules adding 2 new fairy pieces. Helps to get rid of the opening theory, spices the game with much more tactics and strategy

[Nordlandia]

This?

http://musketeerchess.net/games/musketeer/rules/rules-short.php

[musketeerchess]

yes

2018-03-10 23:00 GMT+01:00 Jon notifications@github.com:

This?

http://musketeerchess.net/games/musketeer/rules/rules-short.php

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ddugovic/Stockfish/issues/506#issuecomment-372070585, or mute the thread https://github.com/notifications/unsubscribe-auth/AhBOHX7bRuRal-K33OUYlZLCNDgHuCoFks5tdE0IgaJpZM4Slcrw .

[Nordlandia]

One particular variant or multiple?

[musketeerchess]

As a beginning, 2 fairy pieces (default) have to be added, then, it'll become easier to program and add the others

[Nordlandia]

Is the pieces similar to Seirawan Chess. Seirawan was recently implemented into variant framework.

[musketeerchess]

My choice if i must make a choice (my favorite pieces) will go for Unicorn & Hawk. The Seirawan pieces inspired me but my pieces rules are quite different

[ianfab]

@musketeerchess Have you defined yet how the setup phase of the extra pieces should look like in the UCI protocol and how FENs are extended to fully describe the board state? The pieces on the 0th/9th rank could be encoded in a similar way as for crazyhouse and seirawan chess, but the possible promotion options also need to be encoded somehow.

[musketeerchess]

Hi, i haven't fixed these elements.

A possibility could be:

For the Musketeer Chess Fairy piece encoding in FEN we can use letters other than P R N Q K B for example: Cannon = C Leopard = L Archbishop = A Chancellor =O Spider = S Dragon = D Unicorn = U Hawk = H Elephant = E Fortress = F Use of lower case notation for black and Upper case notation for White.

Concerning the initial placement of the pieces in lines 0 and 9,

Piece placement (from white's perspective). Each rank is described, starting with rank 9 and ending with rank 0; within each rank, the contents of each square are described from file "a" through file "h". Following the Standard Algebraic Notation (SAN), each piece is identified by a single letter taken from the standard English names (pawn = "P", knight = "N", bishop = "B", rook = "R", queen = "Q" and king = "K"). White pieces are designated using upper-case letters ("PNBRQK") while black pieces use lowercase ("pnbrqk"). Empty squares are noted using digits 1 through 8 (the number of empty squares), and "/" separates ranks.

[ianfab]

To avoid confusion about the board size and to decrease redundancy, I think it would make sense to use an FEN format like rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[HaAfhcag] w KQkq - 0 1 (white hawk on a0, white archbishop on f0, etc.), or rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[Ha/Af/hc/ag] w KQkq - 0 1 to improve readability, or the more verbose rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[Ha0/Af0/hc9/ag9] w KQkq - 0 1. After the extra pieces have been brought into the game, one could use a dash instead of the file (rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[H-A-h-a-] w KQkq - 0 1) to indicate that they are no longer there but keeping the information about the possible options for pawn promotions. This FEN format should be relatively intuitive for people familiar with crazyhouse or seirawan FENs.

For the piece placement I think a crazyhouse-like notation (A@f0) would make sense. For the piece selection, I am not sure. The piece type itself would in principle be sufficient (e.g., A), but maybe it should be a bit more verbose in this case.

Do you already have a GUI (apart from the web-interface) that supports Musketeer chess? If you want an engine based on Stockfish, it would be natural to use (an extended) UCI protocol, but without a GUI that supports the same interface, that could of course only be used from the command line.

[musketeerchess]

Hi Your suggestion for FEN notation is excellent (the latest suggestion). I don't have a GUI and this should be part of the project (using Winboard for example isn't that easy and that good). A simple GUI to make engine vs engine matches, copying and pasting analysis in the game and showing windows of the analysis of the engine and a window with some parameters we can change (default evaluation of the pieces etc). Probably this GUI can be further developed for Stockfish playing Fisher Random Chess, Seirawan Chess, Crazy Chess and Other Variants. Winboard is developed by HG Muller, a skiller programmer, but it's no longer feeded with fresh ideas and isn't really user friendly.

[HGMuller]

I think it is a bad idea to abuse a FEN to encode game rules. FEN should be kept for encoding positions. Games with different promotion rules are really different variants. So logically the choice of pieces should occur through the UCI_Variant option, (e.g. by having variants like MusketeerHC) not through the FEN of a game position.

Furthermore, the rules of Musketeer Chess do not specify where pieces should be gated; this is a players choice. So the engine should make it, starting from a position where it has the pieces in hand, but without assigned gating square. Its first two moves should consist of assigning gating squares to the pieces in hand; only then it can start making moves on the board.

Because Musketeer gating (unlike Seirawan gating) is equivalent to stacking of pieces, I would prefer to use a notation that treats stacking in a general way. E.g. a stack of pieces on a certain square could be indicated by putting the IDs of the involved pieces in parentheses. So

r(nh)bqkb(nc)r/pppppppp/8/8/8/8/PPPPPPPP/RN(BC)QK(BH)NR [-] w KQkq - 0 3

would be a position where white has assigned its Hawk an Cannon to f1 and c1, respectively, while black has assigned these to g8 and and b8. Moving the white Bishops or black Knights would 'uncover' the underlying H or C. At that point, there is nothing in hand; the hand only is for unassigned pieces.

Finally, if you think WinBoard is not user friendly, this is mostly your own fault, by not revealing what you consider user-friendly. For me, WinBoard currently does everything I need, in the most efficient way conceivable. Your preferences might differ from mine, however. But I cannot smell what they are...

[ianfab]

@HGMuller The promotion rules are determined by the choice of gating pieces in the setup phase, i.e., during the first moves of the game, if I understood correctly. In my opinion, this makes them part of the board state and not of a subvariant, because otherwise you would have to change the variant during the game (and the variant would be kind of undefined at the beginning).

I like your suggestion regarding the generalization of the representation for gating pieces. The FEN format might need an extension to specify the promotion options though (for aforementioned reasons).

[HGMuller]

Hmm, it seems you are right. I thought the players would just have to agree on the pieces, before they started. It is really very annoying that promotion rules can become part of the game state. Imagine the way some pieces move would become part of the game state... (In fact one could argue that this is exactly what is the case here: a variant with two additional pieces X and Y, to which Pawns can also promote, and for which during the game is decided how they move.) One could use the 'hand' field for this, but this really feels like abuse. This whole problem is so specific to Musketeer Chess that it is questionable if a general promotion-choice field would be of any value. Otherwise I would have suggested an entirely new field 'P=NBRQHC'. But in most Musketeer positions this would be very redundant. So I am inclined to go for a kludge, which would only work for Musketeer, by the virtue of the fact that you cannot gate under a King: you 'stack' the fairy pieces that get captured under the King, like '(KHC)'. But only if that side still has Pawns.

[ddugovic]

Musketeer Chess sounds fun to play.

I know Fabian has taken interest in many chess variants in his Multi-Variant SF fork although I don't recall seeing Musketeer among them.

I just heard this itch.io job board creation announcement which seems of some interest, although I think itch.io developers tend to focus on offline desktop applications.

[ianfab]

There is a fork for Musketeer chess that was split off from Fairy-Stockfish during its initial development. However, to my knowledge there is no GUI supporting the musketeer chess specific mechanism for gating moves (apart from using S-chess gating as a workaround) and the UCI protocol extensions that I made for the setup phase.

[HGMuller]

Since the introduction of engine-defined variants I try to minimize the number of standard variants that CECP recognizes. So if a variant can be played as a modification of an existing standard variant that lies within the configurability of XBoard threough the setup and piece commands, (i.e. with the existing standard variantr as 'parent'), I don't see a reason to make a new standard variant for it.

Musketeer Chess seems playable as modified S-Chess. That the pieces in hand cannot be gated everywhere is something the engines can enforce by themselves.

In general I also dislike variants that have a special 'prelude' that doesn't exist of ordinary chess moves. Often such a prelude just seems a work-around to implement a shuffle game in an unbiased way without a neutral referee, and when a computer is involved we might as well implement it as a shuffle game; in human-engine games the user can always press New Game until he gets a start position he likes.

Nevertheless I was wondering recently if it would be useful to extend CECP with 'pseudomoves', which would be arbitrary text strings that could be passed between engines or presented in an answerable popup to the user, and would switch the clocks in the process.

[HGMuller]

Now that the Musketeer Chess project seems to wake up from hibernation, I gave it a thought how the prelude could be handled in WinBoard. CECP already has commands to enable a non-standard dialog between engine and user: with "askuser TAG QUESTION" it can make the GUI pop up a dialog asking the QUESTION, and after the user types in the ANSWER, the command "TAG ANSWER" will be sent to the engine. The command "telluser MESSAGE" can be sued to present the user a MESSAGE that does not require a response. To negotiate the Musketeer piece the engine could for instance say: "askuser piece2 My piece choice is H. What is yours?", and the user could then type "A" for Archbishop in the response field, to cause "piece2 A" being send to the engine. Or if the engine plays black it could simply start with "askuser piece1 What piece do you pick?". A black engine can announce its choice for the gating file of the second piece through a "telluser" command, as no further response from the user is expected after that, and it can just await the first move of the user after announcing it. One snag is that Musketeer Chess would be an engine-defined variant (using Seirawan as parent, to enable gating and holdings to gate from), and that I would like the participating pieces to be known before the engine sends its "setup" command to define the piece symbols & IDs of the participating pieces, and the initial position. So that the GUI can put the selected pieces in the holdings, and won't offer the not-selected pieces as promotion choice. This is awkward, because WinBoard sends 'ping' immediately after the 'variant' command, so that it can know when the latter will not be replied to with a 'setup' (rather than the reply just being tardy). In that case it aborts the game with an error when the 'pong' reply arrives. So 'pong' would have to be delayed until after the 'setup' command, and thus until after completion of the negociation prelude. This would actually work in the current WinBoard implementation, but is a rather bad violation of the spirit of the ping/pong mechanism. But perhaps we should be pragmatic here, and redefine the commands for user communication as 'asynchronous'.

Another problem is that this would have to be done in a completely different way in a game between two engines. Unless the meaning of the 'askuser' command would be redefined in engine-engine mode, to not cause a popup, but send the squastion to the other engine.

[musketeerchess]

Hi my friends

Let’s make things easier.

The regular rules for humans is what was defined already = white choses among 10 pieces.

If black doesn’t agree, a default combination is chosen.

If black agrees he choses the same piece and then it’s his turn to chose the remaining combination without white having the possibility to refuse blacks choice.

For engines the choice should be done like this:

white makes a choice and then the black engine makes the second piece choice among the remaining 9 possibilities.

This will for sure ease the task for programming.

This will ultimately apply to humans when updating the game to make the rules easier.

When making tournaments, the tournament director can force a default combination for all the tables. He gives the combination before the start of the round or before the tournament begins.

PS:

My goal is the following:

Tournament using winboard or another UCI compatible user interface.

The tournament should involve a minimum of 6 different engines.

Source code must be provided to avoid clones, the only participant with stockfish musketeer is @ianfab or @ddugovich

Winner 1500$ 2nd 1000$ 3d 500$

Each participant with working engine without easily identifiable bugs 200$

The methodology to gate chose the additional pieces etc should be agreed between programmers when we decide beginning of the tournament. Naturally i will be involved in this.

PRICES Payment method Paypal.

Additional 750$ for the programmer that can provide a GUI newly developed and that can use classic stockfish and musketeer stockfish.

Welcome to Musketeer Chess, the next Chess Evolution

Le 14 déc. 2019 à 20:00, HGMuller notifications@github.com a écrit :

Now that the Musketeer Chess project seems to wake up from hibernation, I gave it a thought how the prelude could be handled in WinBoard. CECP already has commands to enable a non-standard dialog between engine and user: with "askuser TAG QUESTION" it can make the GUI pop up a dialog asking the QUESTION, and after the user types in the ANSWER, the command "TAG ANSWER" will be sent to the engine. The command "telluser MESSAGE" can be sued to present the user a MESSAGE that does not require a response. To negotiate the Musketeer piece the engine could for instance say: "askuser piece2 My piece choice is H. What is yours?", and the user could then type "A" for Archbishop in the response field, to cause "piece2 A" being send to the engine. Or if the engine plays black it could simply start with "askuser piece1 What piece do you pick?". A black engine can announce its choice for the gating file of the second piece through a "telluser" command, as no further response from the user is expected after that, and it can just await the first move of the user after announcing it. One snag is that Musketeer Chess would be an engine-defined variant (using Seirawan as parent, to enable gating and holdings to gate from), and that I would like the participating pieces to be known before the engine sends its "setup" command to define the piece symbols & IDs of the participating pieces, and the initial position. So that the GUI can put the selected pieces in the holdings, and won't offer the not-selected pieces as promotion choice. This is awkward, because WinBoard sends 'ping' immediately after the 'variant' command, so that it can know when the latter will not be replied to with a 'setup' (rather than the reply just being tardy). In that case it aborts the game with an error when the 'pong' reply arrives. So 'pong' would have to be delayed until after the 'setup' command, and thus until after completion of the negociation prelude. This would actually work in the current WinBoard implementation, but is a rather bad violation of the spirit of the ping/pong mechanism. But perhaps we should be pragmatic here, and redefine the commands for user communication as 'asynchronous'.

Another problem is that this would have to be done in a completely different way in a game between two engines. Unless the meaning of the 'askuser' command would be redefined in engine-engine mode, to not cause a popup, but send the squastion to the other engine.

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

[HGMuller]

You should post that on talkchess.com. Although everyone knows that the $1500 will go to Stockfish, the 2nd price you offer will be high enough to attract interest of a few other programmers.

[musketeerchess]

Will do so.

I intend in making this an annual tournament with increasing prices as i’d bring some novelties to Musketeer Chess that engines will help testing.

I also intend to organise a championship for chess variants.

Welcome to Musketeer Chess, the next Chess Evolution

Le 14 déc. 2019 à 22:43, HGMuller notifications@github.com a écrit :

You should post that on talkchess.com. Although everyone knows that the $1500 will go to Stockfish, the 2nd price you offer will be high enough to attract interest of a few other programmers.

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