Ratings & Comments

Thanks But could you check your link, I couldn’t retrieve it

Marking of attacked squares to weed out illegal King moves is just one of the two things the accelerated check test does. The other thing is that it tabulates for each board square which (attempted) sliding moves visit it.

It's not the same thing that you're doing, but I have now made a quicker version of stalemated called stalemated-quick, which does some preprocessing to reduce the work involved in checking for check. It starts by creating an array of the King's location and each space it may move to, and for each location in this array, it makes an array of every location with an enemy piece that has it in its range. The code looks like this:

// Build threat lists
set krange merge fn join const alias space #kingpos "-Range" #kingpos #kingpos;
set threats ();
for to #krange:
  set threats.{#to} ();
next;
for (from piece) fn #enemies:
  set in intersection var krange fn join const alias var piece "-Range" var from;
  for to #in:
    push threats.{#to} #from;
  next;
next;

So it creates multiple elements of an array called threats, each of which is an array of the enemy pieces that include that space in its full range of movement. At the start of Chess, threats.d2 and threats.d1 both have one element set to d8, and the others (elements e1, e2, f1, and f2 of threats) are empty.

To check for check, it first assumes a value of false, and it tries out the move only if there are pieces potentially threatening the space the King is on. That move looks like this:

set checkpos cond == #from #kingpos #to #kingpos;
set checked false;
if count elem var checkpos threats:
  move #from #to;
  set checked fn threatened #checkpos;
  restore;
endif;

Instead of using the checked function, it used the threatened function, which looks like this:

def threatened anytrue lambda (fn const alias space #0 #0 var king) 
elem var king threats 
=movetype CHECK 
=king;

This function expects threats to be populated with appropriate values. So it can't be used everywhere checked can.

In tests with Chess, everything seems to be working. After making sure it worked, I did some speed tests comparing 100 calls to stalemated with 100 calls to stalemated-quick. In each pair, stalemated is first, and stalemated-quick is second. The results show that stalemated-quick is normally quicker.

Elapsed time: 4.7686970233917 seconds

Elapsed time: 2.8460500240326 seconds

Elapsed time: 4.8747198581696 seconds

Elapsed time: 3.0506091117859 seconds

Elapsed time: 4.4713160991669 seconds

Elapsed time: 2.9584100246429 seconds

@François Houdebert,

While I was on the biscandine site, I noticed a few errors in your rule descriptions, as well as an error in the Tori Shogi Jocly implementation.

In the Tori Shogi Jocly implementation, Player A's Left Quail has its movement mirrored from what it should be.

I have attached the corrected images for the movement diagrams below. I also removed the extraneous black lines from the Mini-shogi setup image.

https://www.chessvariants.com//membergraphics/MSa.-m.-dewitts-miscellaneous-files/corrected-images-biscandine-jocly.zip

The author, Bob Greenwade, has updated this page.

contageous=Z!R!P

Kaministiquia by Stuart Spence, AKA Zulban

The author, Florin Lupusoru, has updated this page.

5. It checks whether the King is in check by checking whether any enemy piece can move to the King's space. As an optimization, it returns true as soon as it finds one check.

The efficiency of your algorithm depends on whether there is a fast method to answer the question "does the piece at square A attack square B", which then can be combined to a function "IsSquareAttacked" by looping over all pieces A. But for complex multi-leg moves (pieces that turn corners, or jump over others, or do not end their move at the square they attack) it is hard to find a shortcut even if you are writing dedicated code for it. Often the best way is to just generate all moves of the piece at A, and for each of those test if it happens to hit B. For simple sliders and leapers it would be possible to immediately exclude they are attacking B based on the (x,y) coordinates of the leap from B to A (e.g. x*y!=0 for a Rook), or even tabulate in which direction you would have to move to arrive at B (and then test whether this path is unobstructed).

I could of course classify pieces (or even their individual moves) as simple or complex, and use a fast "does A attack B" function for leaps and straight slides, and only generate the complex moves of all enemy pieces to test whether these hit B. Typically only a small fraction of the pieces will have complex moves, and then this could be competitive.

This optimization might be helpful when not using piece functions, but one thing about it concerns me. While it might be helpful in determining whether a move by the King would be into check, I'm not sure it will work for revealed checks. It is because of the possibility of revealed checks that my code checks for check for the position resulting from every single pseudo-legal move it finds.

Marking of attacked squares to weed out illegal King moves is just one of the two things the accelerated check test does. The other thing is that it tabulates for each board square which (attempted) sliding moves visit it. If such a move did not hit B before, it cannot hit B after a move that would not mutate at least one of the squares that the move visited. E.g. if a Cannon is looking at the King directly it would not check, but during move generation the first leg of the move in the direction of the King would have been attempted, and perhaps even succeeded by capturing something that was behind the King. But whether it succeeded or not, all the squares between Cannon and King would get this Cannon move added to the list of moves that visit them.

If the move to be tested for legality would land on an empty square between Cannon and King, it would see in the constructed table that there was a Cannon that had a move that went over the destination square, and thus will be affected. It will then retry that move of that Cannon, to test whether it hits the King in the new position. Likewise, it would see whether (say) a Bishop had been attacking its origin, and then rerun that Bishop move to test whether it hits the King. This takes care of discovered slides and hopper activation. Moves of other pieces, as well as other moves of these same pieces would not have to be tried; these were not hitting the King before, none of the squares they visited was mutated, so they won't hit the King now.

This is actually the most robust part of the algorithm, which would even work in case of multiple absolute royals: moves that were not checking before cannot check after a move that did not mutate any squares in their path. (But if there are Immobilizers...)

In general the algoritm is very fast: for each move with a royal you test whether the destination is marked as attacked, and for moves with non-royal pieces you only have to rerun the opponent sliding moves that were tabulated as hitting origin or destination (and occasionally other squares that were mutated). And on average there are fewer than 1 enemy sliding moves (i.e. moves that could potentially have continued if the occupancy of the square had been different) to a square, in a typical variant. So in many cases a pseudo-legal move can be accepted as legal by just concluding that the mover was not royal, and the origin and destination of it were not visited by any opponent move. When already in check, it always reruns the move that was delivering that check, as the first test. (Most moves would not resolve the check, and these can then be discarded without further testing.)

Anyway, it is possible to configure the preset to not use the accelerated test, and for a not-too-lage variant (8x8 or 10x10) this will probably work fine.

That would indeed be an alternative: do a full king-capture test after every King move. But it would be more expensive, as a King usually has several moves.

It's more than that. I do a full king-capture test for every pseudo-legal move by every piece that can move. My code works like this.

1. It goes through every piece from the side that can move.
2. For each piece on the side that can move, it calculates the spaces within its range of movement. This is an optimization to keep it from checking for legal moves to every position on the board.
3. For each space within a piece's range of movement, it checks whether the piece has a pseudo-legal move there.
4. For each pseudo-legal move, it tries the position and checks whether it places the King in check.
5. It checks whether the King is in check by checking whether any enemy piece can move to the King's space. As an optimization, it returns true as soon as it finds one check.
6. It checks whether a piece may move to the King's space by calling its function for the move from its location to the King's space.
7. Divergent pieces are handled by writing them to behave differently when the movetype variable is set to CHECK. In the following example, the function for the White_Pawn first checks some conditions any Pawn move must meet, then handles capturing, then continues to handle non-capturing and en passant moves only if movetype is not CHECK.

def White_Pawn
remove var ep
and < rankname #1 var bpr
and < rankname var ep rankname #1
and == filename var ep filename #1
and checkleap #0 #1 1 1
and var ep
or and checkride #0 #1 0 1 == rankname #0 var wpr
or checkleap #0 #1 0 1
and empty #1
and != var movetype CHECK
or and islower space #1 checkleap #0 #1 1 1
and any onboard where #1 0 1 == var movetype CHECK count var wprom
and <= distance #0 #1 var fps
and > rank #1 rank #0;

8. Pieces with non-displacement captures are handled by writing two different functions for them and using the value of movetype to call the correct function.

So you would have to do enemy move generation several times.

Since my code uses piece functions, this is not a big problem. In tests I ran yesterday, my checked function ran 1000 times in under half a second, and the checked subroutine got called 1000 times in close to a second, and this was on a position in which the King was not in check, which meant it never broke out early. Since your code does not use piece functions, it may handle the evaluation of moves more slowly, which will also cause it to evaluate check more slowly.

Testing whether a destination contains the King is not any more expensive than marking the destination. And to do it, you only need to geenrate all enemy moves once.

This optimization might be helpful when not using piece functions, but one thing about it concerns me. While it might be helpful in determining whether a move by the King would be into check, I'm not sure it will work for revealed checks. It is because of the possibility of revealed checks that my code checks for check for the position resulting from every single pseudo-legal move it finds.

I suppose one optimization that could be made if it were needed would be to identify the pieces that might possibly check the King at its current location, then limit the test for whether a move by another piece places the King in check to those pieces. This could be done by making a short list of every enemy piece whose range of movement contains the King's location and having the checked function use it instead of onlyupper or onlylower. If this list were empty, it could even skip the step of trying out a pseudo-legal move and testing whether it places the King in check.

However, this might not work for non-displacement captures in which the capture occurs outside the piece's range of movement, such as the Coordinator capture in Ultima. So, I have to balance efficiency with the work a programmer has to make to use a piece in a game. The brute force method I use helps reduce the work the programmer has to do to make different kinds of pieces work with it.

Oh, a silly trivial mistake on my part. Thanks!

So I would suggest a compromise between your quick method and your reliable method. Flag pieces that can capture a piece without moving to its space, and use your reliable method on these while just checking if other pieces can move to the King's space.

I think I managed to even use some acceleration for the pieces that can perform 'locust capture', by avoiding you have to generate all their moves, and just limit it to moves that could potentially hit the King. This would be the move that already delivers check, and the moves that that mutate a square along the path in a way that would allow a slider leg of the locust capture to pass. Which is what was already done for direct captures too.

The issue was that the test for being already in check was done with the King taken off the board, by comparing the destination of capture-capable moves with the King square. But this was tested only on a final leg, and not for a non-final leg, where the capture would be a locust capture, and the piece would move on after it. I now compare the (temporary evacuated) locust square with the king position too, and if it matches make the move go over to the next leg to see if it can be completed. (For an Advancer that would always be possible, but a Long Leaper it might not be.) If the move can be completed, the locust square would be marked as attacked. This will then make the 'check' message appear.

But more importantly, squares on the second leg would also get marked as squares where a check could be discoved. This was a bug that did not yet express itself. A Checker diagonally adjacent to the enemy King would not deliver check if a friendly piece was immediately behind that King, blocking the landing square. But that blocking piece would then essentially be pinned, and its moves should not be highlighted. The accelerated test would only have noticed that if the second leg of the Checker capture would have added that Checker capture to the moves affected by mutation (= evacuation) of that landing square.

Also (belated) Happy Birthday :‌)

Thanks! :)

I thought it was from Aurelian's Grand Apothecary Chesses?

It could well be. My memory, as I've stated many times, is pretty wretched.

I think the [vulture] is an invention of Lev's

I thought it was from Aurelian's Grand Apothecary Chesses?

The first position in each row is for the non-capture. So if the Cannons are number  12 and 13 in the table, the Cannon x Cannon indications would need to be in the 13th and 14th element of the row. So 12 'nothing special' positions in front of them.

There is no row for empty squares, as empty squares cannot be moved. So you would have to specify this in the 12th and 13th row of the matrix. But it seems you are doing it in the 13th and 14th.

Aand you've rederived these pieces as a back‐formation ;‌) These are the original (long‐ and short‐, respectively) non‐helical switchback rhinos as proposed by Gilman (and independently by KelvinFox).

Actually never mind, these are two of Gilman's four: Long‐switchback Rhino and Short‐switchback Mirror Rhino. The other two move the same but with the non‐alternating step first.

Note incidentally that Gilman's ‘rhino’ is this one (specifically the sliding version), not the (modified) GA one as popularised by Jean‐Louis (hence why both forms are referred to by that name). The fact that both begin W‐then‐F is coïncidence

Also (belated) Happy Birthday :‌)

Zombie Pawn: Moves (with capture) one space directly or diagonally forward, or moves without capture one space directly behind. Any piece that captures it and stops on its square immediately becomes a Zombie Pawn (but doesn't change color).

I clarified this, essentially the same way but expanding a bit more.

I'd love to make the Reaper and Mummy also immune, and there's probably some way of doing that, but I'm not sure what. If there is, maybe H.G. can chime in to help.

I guess the Vulture's move description isn't too problematic, except that the ID move does not match up with it. It should be mHnFXnNY.

Well, that's definitely a "kink." I think I miscounted or something. I changed the ID move as indicated.

I think the piece is an invention of Lev's; if it's the description that should've been changed, hopefully he'll speak up.

Rocket, which is square interpretation of Zip on cluster cell in Rocket Chess, which is mentioned earlier, moves as following:

In other words: forward Rook, forward sidemost Zip, backward narrow Electrician.

Otherwise it has a simpler version which is forward Rook, backward Bishop and forward sidemost Nightrider:

can you castle through attacked square if you still have another king

Maybe it is better if I explain what I want to do.

So there are these two pieces (in position 12 and 13):

  lightcannon:X:mRcpR:cannon:a4,n4,,a11,n11
  heavycannon:Y:pRpafcpR:warmachine:a2,n2,,a13,n13

The rule I want to implement is that heavy cannons cannot jump, be jumped, captured or be captured by other cannons. My captureMatrix looks like this:

  captureMatrix=////////////11$$./11$$./

but probably I got it wrong.

Note the heavy cannon is a bit more than a korean cannon is as it can jump two platforms in order capture, but not move.

With the current coloring scheme it is very hard to distinguish occupied squares from empty squares; the pieces blend in too easily with the bright square and arrow colors. I would recomment to decrease the saturation of all the board colors by at least 50%. E.g. by giving the image a 50% (or even 70%) transparency and have a whitish background shine through.

I think you have Missed my previous comment here, HG!

I was out of town for the computer-chess tournament in Zundert.

I don't know how to say that the source piece cannot hop to move, to capture, or capture said type. Meaning both ? and $.

I am not sure what you are asking. If you cannot hop to move or capture, you cannot hop at all, right?

$ indicates you can neither hop over, nor capture said type. If you can capture, but not hop, it would be indicated by ^. It is not possible in general to specify multiple effects for the same piece-combination in the captureMatrix, and in most cases this would not be meaningful anyway. (E.g. it makes no sense to specify what you promote to is the capture is forbidden.) The hop ban is special in this respect, as it does not refer to the occupant of the destination square, so that the move can involve 3 piece types. To cover the case of the Korean Cannon I introduced the $ symbol.

I was thinking of splitting the checked function into separate checked-real and checked-potential functions, but as I was looking into which would be which, it looked like there was never any time when it was passed an empty space after the King just moved. In the Pre-Move sections, kpos or Kpos would be updated before calling the function, and in stalemated, it would check whether the King was the moving piece and pass the King's new position if it was. This meant I could reduce the function to this:

def checked anytrue lambda (fn const alias #0 var key var king) 
cond isupper space var king (onlylower) (onlyupper) 
=movetype CHECK 
=king;

Just in case, I ran this code in Ultima as a test:

sub checked king:
  my from piece;
  local movetype;

  set movetype CHECK;
  if empty var king:
    die "The King space at {#king} is empty.";
  endif;
  if isupper cond empty var king $moved space var king:
    def enemies onlylower;
  else:
    def enemies onlyupper;
  endif;
  for (from piece) fn enemies:
    if fn const alias #piece #from var king:
      return #from;
    endif;
  next;
  return false;
endsub;
def checked sub checked #0;

This code would exit right away with an error message if the subroutine, which was called by the function here, got passed an empty space. I then looked at completed games using the same include file, and they did not exit with the error message. So, I got rid of this code and modified the function, tested Ultima again, and it still worked for both actual checks and for moves that would move the King into check.

With that change made, I ran the speed tests again and got these results:

Elapsed time: 1.0438919067383 seconds

Elapsed time: 0.46452307701111 seconds

Elapsed time: 1.013090133667 seconds

Elapsed time: 0.48957395553589 seconds

Elapsed time: 1.1313791275024 seconds

Elapsed time: 0.49660110473633 seconds

In each pair the subroutine is first, and the function is second, and in each case the function takes less than half the time. In both this case and the previous one, these tests were done on the opening position in Chess, in which the King is not in check, meaning that it checks for check from every enemy piece without exiting early.

I believe it does not. I only set it up; H.G. will know how that functions. Logically, it should apply to anything but rifle captures (and Ghosts and Reapers [I think you meant Vampire here] would be immune), but I'm not sure how to set that up.

Well, if you mean that the contagion applies to anything but rifle/locust captures, then the diagram has you covered already (this is logically equivalent to it applying only to capture that stop on the victim square). In the current ID setup, the pieces that have rifle/locust captures (Vampire, Ghost, and Hangman) only transform when they stop on the Zombie Pawn's square.

This can be made a little clearer in the Zombie Pawn's description, but that is really simple. Just add the underlined text at the spot it appears in.

Zombie Pawn: Moves (with capture) one space directly or diagonally forward, or moves without capture one space directly behind. Any piece that captures it and stops on its square immediately becomes a Zombie Pawn (but doesn't change color).

What further kinks are with the Vulture?

I guess the Vulture's move description isn't too problematic, except that the ID move does not match up with it. It should be mHnFXnNY.

I asked David Howe about the situation where a Chameleon can capture a Cannon Pawn by hopping over an enemy Long Leaper, and he says "The Long Leaper is not captured. The Long Leaper capturing move requires moving to a vacant square."

The changes to Game Courier I described here were for the purpose of writing a checked function that would do the same job as the checked subroutine but even faster. This is for the sake of illustrating the gains in speed of using functions rather than subroutines when a function will do the job. Here's the code for the subroutine and the function:

sub checked king:
    my from piece;
    local movetype;

    set movetype CHECK;
    if isupper cond empty var king $moved space var king:
        def enemies onlylower;
    else:
        def enemies onlyupper;
    endif;
    for (from piece) fn enemies:
        if fn const alias #piece #from var king:
            return #from;
        endif;
    next;
    return false;
endsub;

def checked anytrue lambda (fn const alias #0 var key var king) 
cond isupper cond empty var king $moved space var king (onlylower) (onlyupper) 
=movetype CHECK 
=king;

I have tested the function out in Ultima, because its stalemated subroutine is not widely used in other presets, and its piece functions make use of the movetype value to determine whether it is a regular move or a checking move. Things appear to be working in Ultima. In speed tests comparing 1000 repetitions of each, the function is around twice as fast. In these results, the first, third, and fifth are the subroutine, and the second, fourth, and sixth are the function.

Elapsed time: 0.92847084999084 seconds

Elapsed time: 0.45569705963135 seconds

Elapsed time: 0.87418103218079 seconds

Elapsed time: 0.46827101707458 seconds

Elapsed time: 1.1367251873016 seconds

Elapsed time: 0.65254402160645 seconds

I made a change to the following functions that can run lambda functions on array values: aggregate, allfalse, nonetrue, alltrue, anyfalse, anytrue, any. These will now have access to the variable key, which will contain the key of the array value currently passed to the lambda function. This should be accessed with the var keyword to make sure that a previously defined variable is not being used.

To prevent expressions using these from changing the value of a previous variable called key, I had to raise the scope of every expression. But to get this to work, I had to rewrite each built-in function that exited the PHP function for evaluating expressions with a return. Instead of using return, I had each one set $output to a single element array with the return value, and I set $input to an empty array so that the condition on the while loop would be false. Doing this makes sure that it decrements the scope before exiting the function.

Raising the scope of an expression also makes sure that the mechanism for adding named variables to a function cannot be used in an expression to set a variable that lasts beyond the expression. The following code prints 6468, then it prints 63. This is because it raises the scope for the assignments in the expression, and when it completes the expression, it closes that scope.

set o 9;
set y 7;
set pp * var o var y =o 98 =y 66;
echo #pp;
print * #o #y;

I don't think it's bugged. "P a6-a8;L-a8" seems to allow the Cannon Pawn to promote.

It appears from the Game Courier Preset that the answer is that the Long Leaper is not Captured in this situation and that only the Cannon Pawn is Captured. I suppose that I will accept this as the correct rule for now even though I don't know if this is intentional or a bug.

Well, then, maybe an army with my sillier pieces can be the Greenwade Goofballs. :)

The author, Florin Lupusoru, has updated this page.

I think you have Missed my previous comment here, HG!

Hope you don't mind me doing this again, but your American Football pieces gave me an idea for another CwDA.

@ Bn Em:

I edited the intro sections slightly, to the (3) Rules pages (two already published, recently), as I think you requested.

The author, Kevin Pacey, has updated this page.

The author, Kevin Pacey, has updated this page.

With my supply of pieces dwindling, I'll need these. Thanks! :)

And I’m again with suggestions:

Again about space

Bullet, long forgotten

Three tricky birds

Stunt-based chessmen

The largest list

I noticed today in the comments section that Smess was being given the description for Take the Brain. So, I made some corrections to make sure that the correct description was given for the name it was paired up with in IndexEntry. In the comments section, the primary name and description should now be used. In queries of the database on the names of games, each description will now show up for the name it goes with. On the What's New page, the name should be the primary name, and the description should be the Whatsnew text if it is available. Otherwise, it will fall back to using the primary description. All of this now works correctly for Smess, All the King's Men, and Take the Brain, though I have not tested other games with multiple names.

298. Chained Bishop, 299. Chained Rook, and 300. Chained Queen. These are related to (and, unconsciously, indirectly inspired by) the Helical Switchback Rhino and Griffin that were suggested to me by fellow CVP contributor Bn Em for Unnecessarily Complicated Chess. Given that today's my birthday and this set leads into #300, I thought it seemed like a fitting moment.

These pieces start by taking one step in the direction 45° from what the name would suggest: orthogonally for the Bishop, and diagonally for the Rook. They then turn 45° toward the intended general direction, step one space, then make another 45° turn the same direction (left or right) as the previous one, and continue making alternating turns of two left and two right (in either order) until reaching their destination.

For example, here's the Chained Bishop (Wafs(afqafz)Wafsafq(afzafq)W):

And the Chained Rook (Fafs(afqafz)Fafsafq(afzafq)F):

The Chained Queen, naturally, combines the two (Kafs(afqafz)Kafsafq(afzafq)K).

The marking for "Chained" was tossed together as a casual experiment, and I was surprised at how well it worked, at least to my eye.

I can imagine how "Chaining" could be applied to other pieces as well -- not just compounds like Chancellor and Archbishop, but also bent sliders like Rhino/Manticore and Eagle/Griffin, or even leaping sliders like Ostrich and Osprey or Tiger and Striped Dragon. (I'm not so sure how well a Chained Nightrider would work, though.)

Because the Ivorytower pieces looked a little small on the board, I reduced the size of the board from 83x83 squares to 73x73 squares. The original board had 83x73 squares to give it a more square shape with a 7x8 layout, but the 73 pixel width works better for the Ivorytower pieces, because they can now fully cover up the oval on some spaces that names the piece starting from that position. I also tried 60x60 spaces, as that is the size used in Storm the Ivory Tower, but the Blue Brain was covering up too much of the forward arrow on its space. So I reverted to 73x73.

While the Ivorytower pieces do look better, they are still rough around the edges. and I think they would look better as SVG pieces.

Ah, that link works quite nicely.

So the basic Fairy in this case is basically WS, with that special property of making enemy pieces that target it switch sides for one turn. The swapping property of the more advanced versions are a bit more interesting, though if I'm doing a Fairy in Fairy Chess I'd want it to be more like what I proposed. (Not that the Discord version is a bad idea, of course; I may come up with something for the Fairy++ on the chart.)

Apologies, I'd meant to publish the Accelerated games alongside the regular(?) ones but apparently neglected to actually hit the update button.

That said, the links in particular are a welcome addition which arguably the other pages would benefit from too if you're not too averse to adding them

Random Capablanca Chess (In the page "variants playable against the diagram ai" the applet doesn't work)