Looking for C developper

[Evert]

I'm going to explore some unexplored chess variants

I hope you're serious

I've found working on "universal" chess engines to be a lot of fun, although focusing on a particular obscure variant would also be interesting but in a very different way...

We're not planning to stray too far from home with this one. Mainly dipping a toe into the ocean of chess variants, but if we do it right, could be a good basis for some swimming later.

We're currently trying to hammer out how to do the board and move representations, where to compromise and on what. And how to smoothly join two slightly different coding styles.

[lucasart]

It's a deep ocean to swim in. For now, we are focusing on Seirawan960, which is a generalization of Seirawan based on adding Chess960 castling. That way we can play Chess, Chess960, Seirawan as they are all subsets of Seirawan960. This Seirawan9960 is actually an invention of Evert, and perhaps not what GM Seirawan intended, but it will allow us to unify the implementation.

The first thing to figure out was move encoding. I was a bit at a loss there and trying to figure out how to pack it efficiently, because the rules introduce more subtilties that are not present in orthodox chess. Evert found a clever way to pack a move for Seirawan960, using 15 bits only! So we went for that.

At the moment the code base is really basic, but we will move forward very fast, because Evert has some ready made and tested movegen code. At this point we're trying to get used to the git workflow. Once we pass this small hurdle, things will move quickly.

[hgm]

I still want to appeal to you to make it flexible enough to also include the off-board pieces in the shuffle, so that you could start with E+Q or Q+H in hand, rather than just E+H (Seirawan2880). Whatever encoding scheme you have in mind, it should always be possible to let the encodings mean "gate first off-board piece" and "gate second off-board piece", where the actual piece type corresponding to "first" or "second" would come from a table filled during the shuffle.

[Evert]

I still want to appeal to you to make it flexible enough to also include the off-board pieces in the shuffle, so that you could start with E+Q or Q+H in hand, rather than just E+H (Seirawan2880). Whatever encoding scheme you have in mind, it should always be possible to let the encodings mean "gate first off-board piece" and "gate second off-board piece", where the actual piece type corresponding to "first" or "second" would come from a table filled during the shuffle.

Great minds think alike.

The proposed encoding at the moment looks like a promotion, and can be distinguished from a promotion by noting where the piece comes from (first rank), or that it is not a pawn. Whatever piece you specify is taken from holdings and dropped on the free space.

I considered whether it would make sense to allow starting with knights, bishops or rooks off-board as well, but I don't think that makes as much sense: you'd want both bishops on the board initially (for the colour symmetry, although you could leave it up to the player to decide that that's a good idea), and you'd want both rooks for the purpose of castling. That leaves the knights, at which point you might as well not bother and stick with the three compound pieces Q, E, H (the Queen is the odd one out in that menagerie).

Or, the king could be one of the pieces that can be gated in (which cannot be done when it would be in check after your move), and you lose the game if you have no gating opportunities left and have failed to put it on the board. That would be a very different game though… you'd probably want to avoid gating it in for as long as possible, and try to force your opponent to gate it in at a sub-optimal position. Of course, you're fighting with one piece down because you need to leave one piece undeveloped until you're ready to bring in your own king…

But for now, Seirawan2880 it is.

[hgm]

Great!

Indeed, in XBoard and the ICS I also treat the gatings like promotions, distinguished from those by whether the moved piece is a Pawn or not.

Unfortunately, this scheme did not work in Spartacus, because there I condensed the promotions into a (pieceType, boardStep) pair in the toSquare field, allowing only the three orthodox Pawn steps (which would be good enough for both FIDE and Berolina Pawns). But back-rank pieces have all kind of other move steps. The problem is that Spartacus doesn't have too many spare bits next to the (fromSqr, toSqr) fields in its 16-bit move encoding, as it supports 12x10 0x88-style board (i.e. 24x10).

Perhaps the gatings could be ecoded by also using off-board fromSqr. On Seitawan's 8x8 board, exactly two 'shadow boards' can be fitted in the unused part of the ranks of the 24x10 board.

[Evert]

Great!

What is interesting is that if you write a program that is able to play "Seirawan2880", it can automatically also play chess, Fischer chess, Seirawan Chess and variants where you start with an archbishop or a chancellor instead of a queen. They're all just special versions of the same game.

How much work would it be to make "Seirawan2880" work in XBoard? Or would it already work, if provided with a startup FEN?

Indeed, in XBoard and the ICS I also treat the gatings like promotions, distinguished from those by whether the moved piece is a Pawn or not.

I think this makes the most sense.
In Leonidas I do this differently, but only because it inherited Sjaak's "pickup and drop" move encoding.

Unfortunately, this scheme did not work in Spartacus, because there I condensed the promotions into a (pieceType, boardStep) pair in the toSquare field, allowing only the three orthodox Pawn steps (which would be good enough for both FIDE and Berolina Pawns). But back-rank pieces have all kind of other move steps. The problem is that Spartacus doesn't have too many spare bits next to the (fromSqr, toSqr) fields in its 16-bit move encoding, as it supports 12x10 0x88-style board (i.e. 24x10).

Perhaps the gatings could be ecoded by also using off-board fromSqr. On Seitawan's 8x8 board, exactly two 'shadow boards' can be fitted in the unused part of the ranks of the 24x10 board.

So does Spartacus play Seirawan? I'm guessing not, based on what you just said, or do you have a work-around in place?

[Sven]

(I don't know what you mean by Sven's ep rule, but it seems there would be some special-casing here too.)

Actually there is no "Sven's ep rule" in the context of Marseillais Chess at all, I did not come up with any rule change proposal, I became aware of Marseillais Chess only 10-15 minutes before I posted a comment yesterday. HGM clearly refers to that posting where I quoted chessvariants.org regarding a possible ambiguity in the e.p. rule. My intention was just to specify that e.p. rule prior to writing engines for it, not to say how the rule should be defined.

Sven

[hgm]

What is interesting is that if you write a program that is able to play "Seirawan2880", it can automatically also play chess, Fischer chess, Seirawan Chess and variants where you start with an archbishop or a chancellor instead of a queen. They're all just special versions of the same game.

Yes, this kind of unified Chess must make Reinhard Scharnagl very happy!

How much work would it be to make "Seirawan2880" work in XBoard? Or would it already work, if provided with a startup FEN?

There is one minor detail that currently prevents it, and I plan to cure that this weekend. The problem is that Fischer castling is only possible in FRC and CRC, while gating is only possible in Seirawan. There is no reason why Fischer castling couldn't be made available in every variant, though, subject to a new option -fischerCastlings true|false, treated similarly to -suffleOpenings. When loading a FEN through a setup command the presence of castling rights without King or Rooks in the orthodox location can safely be used to deduce the game must have Fischer castling.

After this change, provided the engine does the shuffling by itself, it should already work as an engine-defined variant when the engine send the setup command with the shuffled setup, specifying 8x8+7_seirawan as parent variant. To play it as plain Seirawan with -shuffleOpenings and -fichherCastling configured true by the user would require some change in the shuffling code (which currently only shuffles the board back-rank, and leaves the holdings alone).

So does Spartacus play Seirawan? I'm guessing not, based on what you just said, or do you have a work-around in place?

Indeed, it doesn't. It was on my to-do list, however. Waiting for a good idea. Perhaps initializing the move-decoding tables differently for each variant would be the best solution. (But it is so messy...) Seirawan has a lot of special moves for all the gatings, but it does have a small board, so a lot of off-board codes are available. Variants with a larger board often have viewer special moves. (e.g. Courier Chess with 12x8 has no castling, double-push or e.p., Grand Chess with 10x10 has no castling, etc.)

I guess I could even drop the idea of a fixed width x height layout, and also adapt that to the variant. It bothers me that I cannot do Omega Chess now. This uses (part of) a 12x12 board, and with a 24-wide board I can do at most 11 ranks with 8-bit square numbers. But due to the fact that only the corner squares of the outer rim are used, it should be possible to fit the Omega board in a 22x12, or even 21x11 array without losing the 0x88 unambiguity.

[Evert]

After this change, provided the engine does the shuffling by itself, it should already work as an engine-defined variant when the engine send the setup command with the shuffled setup, specifying 8x8+7_seirawan as parent variant. To play it as plain Seirawan with -shuffleOpenings and -fichherCastling configured true by the user would require some change in the shuffling code (which currently only shuffles the board back-rank, and leaves the holdings alone).

Bummer about having to do the shuffling ourselves.
How do "engine-defined variants" work? Is that a new feature? Will it work with regular XBoard? Or just Alien?

Indeed, it doesn't. It was on my to-do list, however. Waiting for a good idea. Perhaps initializing the move-decoding tables differently for each variant would be the best solution. (But it is so messy...) Seirawan has a lot of special moves for all the gatings, but it does have a small board, so a lot of off-board codes are available. Variants with a larger board often have viewer special moves. (e.g. Courier Chess with 12x8 has no castling, double-push or e.p., Grand Chess with 10x10 has no castling, etc.)

Well, you could have a default move-decoding, and only change it as needed (for Seirawan). I guess, I don't know how difficult that woud be, never having tried to do anything similar.

I guess I could even drop the idea of a fixed width x height layout, and also adapt that to the variant. It bothers me that I cannot do Omega Chess now. This uses (part of) a 12x12 board, and with a 24-wide board I can do at most 11 ranks with 8-bit square numbers. But due to the fact that only the corner squares of the outer rim are used, it should be possible to fit the Omega board in a 22x12, or even 21x11 array without losing the 0x88 unambiguity.

Omega is evil.
I once spent an afternoon on it to hack it into Sjaak, but nothing came of it. The problem is Sjaak can only handle 128 squares at maximum, which is "ok" because Omega is really 10x10+4, but then calculating occupancy masks for the diagonals as well as leaper moves becomes ugly (actually, the leapers aren't so bad, you just get weird bit patterns in their move bitboards).
But I decided that trying to force Omega into 128 bit bitboards is an exercise in masochism. Can be done, but not worth the hassle.

[hgm]

How do "engine-defined variants" work? Is that a new feature? Will it work with regular XBoard? Or just Alien?

This is a new feature of the development version. When an engine says

feature variants="....,XXX,..."

where XXX is not one of the supported variant names, XBoard will assume it is an engine-defined variant, and create a button for it in the New Variant dialog. When the user presses this button, it will sent

variant XXX

to the engine, like it would for any variant, but will set the variant to Unknown internally. And it opens itself to reception of a setup command, even when legality testing was on. The setup command can be something like

setup (PN.RQKpn.rqk) 6x6+0_normal rnqknr/pppppp/6/6/PPPPPP/RNQKNR w - - 0 1

telling XBoard that it should switch to 6x6+0_normal, with the -pieceToCharTable as given between the parentheses, using the FEN as initial position. Starting the game before such a setup command is received will result in an error popup.

This basically automates the configuration process that the user had to do before, when he wanted to play a variant with non-standard board or holdings size, using non-standard (for that variant) pieces, or an alternative start position. Such as mini-Shogi, Los-Alamos Chess or Charge of the Light Brigade. It could all be done before, but it was kind of a hassle. Because you had to provide the FEN in a -loadPositionFile, provide lengthy -pieceToCharTable arguments etc. Now the engine can do all that for you, and make the variant appear in the menu as well.

That the engine has to shuffle has both an upside and a downside. The upside is that it can put any restrictions on the shuffling it wants. E.g. XBoard might not know which pieces are color-bound. Or it might not know whether you want to shuffle the holdings as well, or that only QEH should be allowed in the holdings, and not RBN. The engine could both offer a Seirawan960 and a Seirawan2880 as separate engine-defined variants. The downside of course is that it would have to do the work.

The XBoard option -shuffleOpenings is still independent from this mechanism. I guess I could make sure that when it is set, shuffling would even be applied to the initial setup provided by the engine. It would be a pain that the user still would have to set it, though. I guess it would be better if the setup command would also be able to control the shuffleOpenings option. To do this well, it should be possible to be a bit more specific as to how the shuffling should be done than just on/off. It would be sort of hard to communicate to XBoard that two of QEH should be in the holdings, and the remaining one shuffled with the other back-rank pieces.

One idea could be this:

XBoard now does two kind of shufflings. The first is re-ordering the back rank, which comes in 3 flavors, depending on castling rules (normal / Fischer / nocastle). The other is used in Superchess, where it randomly swaps the holdings pieces with back-rank pieces. One possible way to combine these modes would be to allow the new symbols <> and ? in the setup FEN. ? would mean: take a piece out of the holdings, and put it here. A set of pieces enclosed in <> on the board would mean: put them in random order. (Again, 'random' being subject to castling and color-bound restrictions.) The Seirawan2880 FEN would then become

<rnb?kbnr>/pppppppp/8/8/8/8/PPPPPPPP/<RNB?KBNR> [QHEqhe] w KQkq - 0 1

while Seirawan960 would be

<rnbqkbnr>/pppppppp/8/8/8/8/PPPPPPPP/<RNBQKBNR> [HEhe] w KQkq - 0 1

To also describe Superchess substitution, we could allow the <> also in the holdings. As the order is meaningless in the holdings, they can be given the meaning there to randomly swap the enclosed set with back-rank pieces. The standard start position of Superchess would then be

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR [<ESAVesav>] w KQkq - 0 1