Chess variant tournament: Spartan Chess

[hgm]

Which reminds me - in variants where pawns move diagonally (or generally differently), WinBoard sometimes erroneously thinks there's an en-passant capture. Would it be possible to add a piece type that is displayed as a pawn, but that doesn't do en-passant captures? What would already help of course is if it would check whether the pawn that is en-passant captured has just been advanced two spaces or not...
Note it's been a while since I first spotted this problem, it may be fixed already in a more recent version. In which case I should take the trouble to update.

I first spotted this problem when using WB for Berolina Chess, which I first thought would be playable as 'normal' with legality testing off. The only fix I made at that time was to make Berolina a separate variant, where I explicitly altered the e.p. heuristic. (So it still does no know the Pawns move differently, and thus still needs legality testing off. But I never bothered to fix that, as no one seemed to play it anyway.)

What you suggest (paying attention to rights) would probably be a good fix (i.e. not likely to break anything in normal Chess, e.g. when e.p. rights are unknown because the position was set up in EditPosition mode). In fact for Berolina this was mandatory, as playing a capture-only move to an empty square does not imply by itself which neighboring Pawn to delete.

Note, however, that WinBoard now uses the Hoplite in general as an e.p.-less Pawn. Originally that was only in Spartan, exactly to circumvent the problem you mentioned. But I decided at some point that the special code that this attached to the Hoplite (resetting the 50-move counter, and promoting it when it reaches last rank) might as well be active in all variants where the spear symbol was not explicitly in use as Amazon. (i.e. all variants but SuperChess). Actually I wonder if I should not switch Berolina to using this symbol for Pawns, as they would already have the correct moves. The only thing that would be needed would be to apply the special Berolina e.p. code to Hoplites in stead of Pawns, in Berolina only. (Just like it is applied now to normal Pawns in Berolina only).

Fairy-Max 4.8R was handling Berolina e.p. wrong, btw. It rejected diagonal moves to the e.p. square, assuming these were attempts to capture e.p., while diagonal moves are only allowed as non-captures on Berolina Pawns. I now changed that by applying the extra rule (besides Pawn moves to e.p. square) that the move should have capture rights before considering it an e.p. attempt, and otherwise just keep considering it a normal non-capture.

[hgm]

OK, I patched WinBoard to not remove any piece as a side effect of a Pawn move unless e.p. rights are set for the file that piece is on. (Which can only happen if the piece in question is a Pawn, which moved there on the previous move by moving up two ranks.) This only when legality checking is off; when it is on the old behavior persists. (Which should not matter, but is an extra insurance against such a last-minute patch breaking anything.) This can still go into 4.7.0.

[hgm]

Alice Chess - Two 8x8 boards side-by-side, in Zilllions, I do this as a 17x8 with the middle row not in play (but that doesn't work if one simply alternates square colours, as the second board gets the wrong colouring then).

Actually it would be quite trivial to make a dedicated Alice version of Fairy-Max, using the one-board representation. All it requires is reducing the number of piece types from 15 to 7, so that the '8' bit of the piece encoding can be used to indicate whether the piece is on the upper or lower board. Apart from flipping this bit on every move, the only chage would then be to put an extra line

Code: Select all

 if((victim ^ piece) & 8) victim = 0; else

in front of the code that handles the move. So that when you encounter a square that is occupied on the other layer, you ignore the move, but for continuation purposes treat it like it went to an empty square (victim = 0).

Alice Chess could then be played as variant normal, with legality testing off (as you seem to jump over pieces that actually are on the other layer). But it would be a sort of semi-blind Alice Chess, as WinBoard would not show you what was on which layer. There are several solutions to that, however (all requiring patching of WB):

1) Use the 'shadow pieces' to represent pieces on the upper layer, letting WB flip the piece type (promote / demote Shogi fashion) after every move automatically.

2) Use the variation board not for a PV walk, but to display the individual layers. So that the user can right-click the board, and then move the mouse vertically to switch between seeing all, only the lower or only the uper layer.

3) Use Flip View to not just flip the view, but to cycle through the layers. Like WinBoard Alien Edition uses it in Dark Chess, EditGame mode to cycle through the various point of views.

Troitzky Chess - 10x10, but with 3 squares cut away from each corner, giving a rounded board.

This would actually be very easy to implement in Spartacus, which already does Grand Chess on 10x10. It would just be a matter of putting some 'boundary guards' inside the 10x10 area (rather than just in the rim around it), and adapting the promotion-zone table (which is a board-size table that stores bit-flags for each side, to indicate white zone, black zone, white last rank, black last rank etc).

Dragon Chess (Lex Parker's) - 16x10, but with 3x3 cut away from each corner (or, as I believe the official description is, 10x10 with a 3x4 flank added on to each side).

This would be too large also for Spartacus' 24x10 mailbox board (as only a 12x10 area of that is usable). But my incipient engine HaChu is especially designed for handling boards upto 36x36, and the pieces that participate in Dragon Chess are just the sort of pieces you would find in the large Shogi variants (limited range sliders alongthe principal 8 rays, no funny leapers other than Knight, which is just a sub-set of the Lion moves). Not sure what the castling rules for this variant are, though; Shogi of course has no castling.

[Evert]

Troitzky Chess - 10x10, but with 3 squares cut away from each corner, giving a rounded board.

This would actually be very easy to implement in Spartacus, which already does Grand Chess on 10x10. It would just be a matter of putting some 'boundary guards' inside the 10x10 area (rather than just in the rim around it), and adapting the promotion-zone table (which is a board-size table that stores bit-flags for each side, to indicate white zone, black zone, white last rank, black last rank etc).

How easy is it to add variants to Spartacus?
For Sjaak I can add variants through an input file in the same spirit as Fairy-Max and Nebiyu (but with a completely different syntax), but if I want them to show up as anything other than "variant fairy" I actually implement the setup for them directly in the code. I think the only variant it supports that I currently can't define through the config file is XiangQi, for which I manually have to hack some of the movement tables.

Dragon Chess (Lex Parker's) - 16x10, but with 3x3 cut away from each corner (or, as I believe the official description is, 10x10 with a 3x4 flank added on to each side).

This would be too large also for Spartacus' 24x10 mailbox board (as only a 12x10 area of that is usable). But my incipient engine HaChu is especially designed for handling boards upto 36x36, and the pieces that participate in Dragon Chess are just the sort of pieces you would find in the large Shogi variants (limited range sliders alongthe principal 8 rays, no funny leapers other than Knight, which is just a sub-set of the Lion moves). Not sure what the castling rules for this variant are, though; Shogi of course has no castling.

I suppose Sjaak could play this if I really hack around with the movement tables, since the board is really only 124<128 squares. It'll be a huge mess though, and it looks like this is a commercial variant anyway...

I did a test yesterday however to see how easy it would be to write a C++ template bitboard class where I can derive the bitboards from any arbitrary integer type (or in principle an array of integers if I overload all the necessary operators) and this proved quite easy. It's nowhere near to replacing Sjaak's explicit C code, but at least it looks like a feasible project (although my last attempt at doing that failed miserably).

[hgm]

Spartacus is not configurable, and needs to be modified and recompiled for adding variants. (This because it was intended to be a high-knowledge engine.) It does have a reasonably general infra-structure for doing this, however. But as it uses 0x88-type attack testing, adding new types of leaper moves could overflow the available number of bits in the 'capture codes' that indicate which capture-groups each piece can make, and which capture-group a certain step vector corresponds to. For things like Spartan, with so many different piece type, it was quite a puzzle to map all available capture moves on 8 bits...

I cannot really see what the appeal of Dragon Chess could be. The Dragon pieces don't look very exciting, (no moves that didn't already exist), it suffers from a large distance between the enemy camps, which also wrecked Capablanca's initial 10x10 design for 'his' Chess variant (why 10 deep, and not 8?), and the extra empty area left and right seems to serve no purpose. So my first reaction is: why bother?

[Evert]

Spartacus is not configurable, and needs to be modified and recompiled for adding variants. (This because it was intended to be a high-knowledge engine.)

Similar to Leonidas, then.
Although that wasn't really intended as a variant engine, but as a Spartan engine. I just figured that it'd get more notice if it could also play regular chess (which was annoying because it meant I had to add en-passant captures). Since it already had half the extra pieces it needed to play Seirawan (and I can easily extend the total number of pieces it knows about to 16) I decided to add that too. The only reason it doesn't handle Berolina is because it can't generate double-steps properly for the Berolina pawn (there's no issue with Hoplites because they can jump).

I cannot really see what the appeal of Dragon Chess could be. The Dragon pieces don't look very exciting, (no moves that didn't already exist), it suffers from a large distance between the enemy camps, which also wrecked Capablanca's initial 10x10 design for 'his' Chess variant (why 10 deep, and not 8?), and the extra empty area left and right seems to serve no purpose. So my first reaction is: why bother?

Well, it looks like the appeal is meant to be "look, flashy computer game that is like chess, but with dragons" and then the addition of a physical set as extra merchandise (which admittedly does look nice, but in my experience that's not necessarily a good thing when it comes to playability). I have the impression the board has a weird shape just for the sake of it, and the rules are surprisingly sparse. What happens when a pawn reaches the back rank of one of the wings? Presumably it promotes?

Good point on the 10x10 being too big; if I make it 10x8 the entire board fits in 16x8, which Sjaak could play easily.

[hgm]

You could call it mini Dragon Chess!

I guess an early version of Spartacus could have played it. But then I changed the board from 32x8 to 24x10, in order to handle Grand Chess... (And only half of it is usable, of course, because of the capture tests.)

I made Fairy-Max do Alice, and it works for a while, (looks crazy in WinBoard, pieces jumping over almost everything...), but then it hangs! I suspect Alice Chess has mutual perpetual Check, like Nightrider Chess. Without repetition detection and with full-ply check extension that is fatal.

[hgm]

It was another problem, after all. I had forgotten to remove setting of e.p. rights from the Pawn double-push in the fmax.ini file. And it turned out that the Fairy-Max e.p. code is not resistant to the e.p. square being occupied, which in Alice Chess happens regularly. So during search pieces would disappear from the board, and not be put back on UnMake. This led to impossible hash moves, which in the Alice version could lead to infinite looping. After removing the e.p. capture from the configure file, the problem disappeared.

I uploaded a Fairy-Max version dedicated to Alice Chess to http://hgm.nubati.net//Alice.zip . It can play under WinBoard as variant normal with legality checking off. (Pretty confucing, as you see both layers collapsed into one. But that is a WB problem.) It could of course be configured to play with different pieces, to play Alice versions of other variants. (E.g. Alice Knightmate.) As long as the variant does nothave more piece types than normal Chess. (So alas, no Alice Spartan...)

Pretty hard to checkmate someone in Alice Chess, btw. (But this is symptomatic for 3D variants.) It needed 3 Queens to get a bare King!

[enhorning]

Pretty hard to checkmate someone in Alice Chess, btw. (But this is symptomatic for 3D variants.) It needed 3 Queens to get a bare King!

That sounds like another bug to me! King + Queen vs lone King should be a simple mate in Alice chess. Zillions can easily mate, and quoting http://www.jsbeasley.co.uk/besn/s18.pdf :

The endings with K+Q, K+R, K+2B, and K+B+N against K are all won, much as in ordinary chess; white has to ensure that the mating man ends up on the same board as the king it is trying to mate, but there is no real difficulty. K+P v K is more interesting, and some positions which are hopelessly drawn in ordinary chess can be won in Alice.

As for the appeal of Dragon Chess, for me it is the addition of simple mid-power pieces. Too many variants either add too many complicated pieces (e.g. I rather dislike the Spartan Lieutenant, finding it somewhat complicated), or too many pieces at the high end of the power spectrum (e.g. the three missing Bishop / Rook / Knight compounds), or too many leapers (e.g. one variant which had all 15 compounds of Bishop / Rook / Knight / 3-1-leaper + King as its 16 pieces... 12 leapers out of 15 non-king pieces!). I tend to prefer variants where the new pieces are similar in power to 2-6 pawns. Another simple piece that I find enjoyable to play with is Mats Winther's Mastodon. Too many variants at Chessvariants.com go way overboard, in my opinion, by throwing too many irregular pieces at me, making them hard to learn, and hard to play with other people IRL. (Of course, I also play Chu Shogi, so I can definitely be convinced to learn variants with lots of pieces... but I think Chu Shogi would be a better game if it had fewer types of 1-square steppers.)

As for 10 ranks vs. 8, it's a matter of personal preference, I think. 10 ranks gives more time for development, 8 gives more immediate conflict. The flank wings are gimmicky, but they do noticeably increase the maneuverability of the Bishops (and, unlike Troitzky chess (where pawns can get earlier promotion at the edges of the board), pawns stuck in them cannot promote, so one can trap the edge pawns that way).

For what it's worth, I find the variant enjoyable to play, and it's simple and similar enough to regular chess that I've successfully introduced it to other players over-the-board. (Side-note: The physical board game was being produced some year (or years) before the computer version, which only came later).

[hgm]

OK, I see. The move must be legal on the board where it is made also with respect to not being in check there, before you transfer. I thought it only would have to be pseudo-legal, as the King moves to the other board where it could not be captured.

So basically captures to a square where there is a piece on the other board should be allowed if that other piece is a King that just moved there. It is a bit like castling, where you also cannot move through check.