Engine development to play a chess variant

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

User avatar
hgm
Posts: 27791
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Engine development to play a chess variant

Post by hgm »

Indeed, one way is to treat this as a 3-dimensional two-layer board. My proposal for genral 3D boards would just be to concatenate all layers in the board field, just as this field already concatenates the ranks. For ease of parsing by humans the separation between the layers could be written as a double slash, rather than a single one. I.e. the 5x5x5 board of RaumSchach could be written as

...../...../5/5/5//...../5/5/5/5//5/5/5/5/5//5/5/5/5/.....//5/5/5/....../..... w 0 1

This would be easily generalized to higher-dimensional boards, e.g. by separating volumes of a 4D board by triple slashes, etc.

But why I bring it up is this: if a general mechanism for handling 3D boards has to be introduced in FEN definition anyway, I would prefer it to be used for the occasional game with odd-ball gating rules, rather than adding a new unique feature just for that. So I would map Musketeer Chess on a game where instead of holdings there is a second layer, which contains the gatable pieces just above the square where they are to be gated:

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR//1l4c1/8/8/8/8/8/8/5CL1 w KQkq - 0 1

This might look a little cumbersome for the specific case of Musketeer Chess, where only the extreme ranks of the upper layer would ever be used. But I think it is preferable to have a somewhat sub-optimally compact representation for the occasional game with complicated rules, than to have a proliferation of special features in the FEN format definition that would serve only to make the notation for the unique case where they would have to be used a little more compact.

The 'decomposable Pawn' variant I mentioned could have as FEN for the start position:

rnbqkbnr/cccccccc/8/8/8/8/CCCCCCCC/RNBQKBNR//8/pppppppp/8/8/8/8/PPPPPPPP/8 w KQkq - 0 1

The upper layer would still be sparsely populated, but at least it would be entirely useful, as stacks could occur anywhere on the board. E.g. after 1. Rb1 CPd5 2. RNc3 the position would be

rnbqkbnr/ccc1cccc/8/3c4/8/2N5/CCCCCCCC/2BQKBNR//8/ppp1pppp/8/3p4/8/2R5/PPPPPPPP/8 w KQkq - 0 1

The drawback of this notation is that it is rather hard to visualize what is stacked on top of what: you have to correlate the info in the layers, stored far apart. A solution to that would be to scan the board dimensions in the other direction, scanning stacks fastest, rather than slowest (i.e. make the board 2x8x8 instead of 8x8x2). For the initial position this would produce

r1/n1/b1/q1/k1/b1/n1/r1//cp/cp/cp/cp/cp/cp/cp/cp//2/2/2/2/2/2/2/2//2/2/2/2/2/2/2/2//2/2/2/2/2/2/2/2//2/2/2/2/2/2/2/2//CP/CP/CP/CP/CP/CP/CP/CP//R1/N1/B1/Q1/K1/B1/N1/R1 w KQkq - 0 1

This makes it obvious that P is stacked on C. But the price is high, as there now is a distracting '1/' between all the other pieces, and the large empty region does not combine as compactly into a large stretch of empty square that you can simply encode by a large number. This is why this format seems less desirable for a game where stacks are relatively rare (as they would have to be when pieces themselves are relatively rare, and empty squares dominate). In this case you could refrain from scanning the vertical dimension if there is only a single piece in the stack, on the bottom layer. That would save you the trouble of indicating the empty cells in the stack, and the separator between stacks. But then you would have to somehow indicate the stacks that do have multiple pieces in them. If you would surround 'true' stacks (i.e. with more than a single piece in them) with [], that would lead to

rnbqkbnr/[cp][cp][cp][cp][cp][cp][cp][cp]/8/8/8/8/[CP][CP][CP][CP][CP][CP][CP][CP]/RNBQKBNR w KQkq - 0 1

and after the indicated moves

rnbqkbnr/[cp][cp]1[cp][cp][cp][cp][cp]/8/3[cp]4/8/2[RN]5/[CP][CP][CP][CP][CP][CP][CP][CP]/2BQKBNR w KQkq - 0 1

It is true that this really is a redundant feature, and that the same problem could have be solved as the normal 3D raster scan. But I think the forms with explicitly indicate the stacks with [] gain enormously in readability compared to the treatment as a general 3D board, in one scan order or another. So I wonder if it should not be adopted as an alternative. Human readability and compactness has always been an important design goal of FEN.

Using this method for Musketeer would give something like

r[nl]bqkb[nc]r/pppppppp/8/8/8/8/PPPPPPPP/R[NC][BL]QKNR w KQkq - 0 1

which actually is quite compact even in comparison with the specialized solution you proposed: the pieces to be gated would have to be mentioned anyway, plus a pair of brackets to surround the holdings. So it takes only three extra [] pairs to indicate where they could be gated.
Angrim
Posts: 97
Joined: Mon Jun 25, 2012 10:16 pm
Location: Forks, WA
Full name: Ben Nye

Re: Engine development to play a chess variant

Post by Angrim »

I took a glance at it, since I have written top engines for several variants. The game design still needs work though. The largest flaw is that even though you think that you added 10 new piece types, only two of those are actually relevant since either player can veto the use of any other piece type. I see no reason to allow this veto, it simply reduces the complexity and interest of the game. Also, the rules related to when the pieces go onto the board could use a modest rework to make them simpler. If those are done, it might be interesting.
One detail that you left out in the initial post is whether you are wanting to own the resulting program, or if you just want one to exist(ie. open source result). Writing a competent engine from scratch is a fairly large project, but adding a new variant to an existing open-source program is fairly easy. And having a free program available that plays your variant would probably help to make it more popular, although having an online server where people could play it against each other would help even more.
User avatar
musketeerchess
Posts: 161
Joined: Sun Apr 21, 2013 2:02 pm
Location: Paris, France

Re: Engine development to play a chess variant

Post by musketeerchess »

Hi Ben
I'm not against development of an engine on open source engine available for all the chess community.

I'm also looking for top commercial engine development.
inventor of Musketeer Chess. A modern commercial chess variant.

www.musketeerchess.net

Pieces are available on Houseofstaunton.com or Paypal
User avatar
musketeerchess
Posts: 161
Joined: Sun Apr 21, 2013 2:02 pm
Location: Paris, France

Re: Engine development to play a chess variant

Post by musketeerchess »

Hi
You'll find pictures on musketeerchess.com

Pieces fit with Staunton chess standards are triple weighted and are in plastic.

They will look great.

I'll post some pictures of the boxes later.

They'll become commercial late September. The HOUSEOFSTAUNTON will be in charge of commercial issues.
inventor of Musketeer Chess. A modern commercial chess variant.

www.musketeerchess.net

Pieces are available on Houseofstaunton.com or Paypal