Ratings & Comments

In my opinion riders based on a leap other than a king step are very awkward to play with. That holds for NN, but also DD and AA. It is never intuitively clear whether the path between such a rider and a distant target is blocked, especially when the blocker is far from both. For me that makes them annoying pieces.

I guess the problems with tactically non-quiet opening positions can be avoided by putting all pieces more valuable than a Nightrider two ranks behind the Pawns. Then the Pawns will block any Nightrider attacks on them. And of course make sure all Pawns and pieces directly behind them start protected.

I find nightriders difficult to visualize, even with the three-colored board, but despite that they seem to work well in the grand apothecary games since there are enough pawns and weaker pieces to block them.

Thanks for the comments guys! Hopefully there are more to come.

@HG,

The awkwardness of nightrider I expect it goes away with sufficient play. Anyway computers don't "feel" it. But if the game is badly designed computer play will yield very biased results. At a practical level you need not have all heavier pieces 2 ranks behind a pawn and GAC A,C & M proves that. Just most of them. I guess there is reason for experimenting. Because this way you don't need to go all in with the theoretical approach.

@HG, By the way. The interactive diagram evaluates vultures less than 12 directions leapers such as the champion. Isn't this weird?

This is probably because Vultures can easily be blocked. A Falcon, which also has 16 targets, empirically tested as about equal to a Rook. Th Vulture has 4 paths rather than 3, but each path can be blocked in 3 places rather than 2. The 4 non-capturing leaps add comparatively little.

The value estimate of the Diagram takes this into account by measuring the average number of moves in randomly generated positions where 25% of the squares are occupied.

@Jean-Louis

I have not designed these games for the nightriders but they seem to work ok probably because of the high board density.

I am not sure why you refer to 'fast castling'. Is that the type of castling proposed by Kevin Pacey in his wide-board variants? Neither the Diagram nor the GAME-code produced by it do support such castling.

The Cannon would have to be in the partners set to allow castling with it. How far the King moves on castling is defined in the moves of the King; castlings are defined in the legdefs table as two-leg moves, the first leg being the slide that has to be used to find the partner, and the second leg (only attempted when a partner could be reached) indicates the leap the King should make. Your presets appear to define both 2-step and 3-step castlings for the King.

A problem is that the castling moves you define on the King are not critical w.r.t. the partner they use; any piece in the partner set would do. So it would not be possibe to only allow 2-step castling with a Rook, but not with a Cannon.

Well if I move my king on top of the rook is castles (3 squares king move). What is w.r.t?

With respect to

In the first preset, when I select the King (after clearing away pieces between King and Rook) it highlights all squares between King and Rook. If I then click the second of that, it does a 2-step castling. I have little doubt that on clicking the 3rd it would do a 3-step castling. If I click on the Rook (which is also highlighted) it does a 4-step castling.

Ok, this means I have to do a separate castling subrountine but that is very difficult, so if you have any advice, I'd gladly take it.

I guess you could use the applet-generated code like 2-, 3- or 4-step castling is always possible, with both Rook and Cannon (adding the latter to the 'partners' array). Like it already seems to be. And then supply a function 'BadZone' in GAME code to suppress the two cases you do not want (2-step for Cannon and 4-step for Rook). You would have to set a variable 'zonal' to true in the Pre-Game code to cause this BadZone function to be called.

The function BadZone will get called with 5 parameters: origin, destination, locust square, drop square, and piece to drop on the latter. For castling the castling partner will be on the locust square. I don't think your variants have locust capture other than e.p., so when the locust square is in the 'partners' array you can be sure it is a castling, and there is no need to test whether it was actually a King that was moved.

I would do it as follows:

set rooks (b2 k2 b13 k13);
set badCannon (e2 i2 e13 i13);
def BadZone match #locust #partners and cond match #locust #rooks match #dest rooks match #dest #badCannon =O =dest =locust =D =P;
set zonal true;

This would declare the move invalid when the locust victim is one of the castling partners (match #locust #partners), AND, depending on whether it is one of the Rooks (match #locust #rooks) whether the destination square (of the King) is on the Rook (match #dest #rooks) or whether the destination square is two steps away from the King (match #dest #badCannon).

I see no definition for 'rooks' in the code you posted. It could be that it doesn't like that. Another problem could be the case where 'locust' is 'undefined' (as it might be for most moves). I don'tknow how the match operator handles that. If there still is an error after defining rooks, try to insert an extra

#locust and

Directly after

def BadZone

This might make the code more efficient anyway, because it would never get to the match parts (which might be expensive) for moves other than castling or e.p..

You mean like this:

set partners (b2 k2 b13 k13 a2 l2 a13 l13); // 'rook' locations for castling

set rooks (b2 k2 b13 k13);

set badCannon (e2 i2 e13 i13);

def BadZone #locust and match #locust #partners and cond match #locust #rooks match #dest rooks match #dest #badCannon =O =dest =locust =D =P;

set zonal true;

?

Yes, isn't that what I wrote in the first place?

Oh, this is not what I meant. I have edited my previous comment.

The thing is that I'm getting the same error!