Ratings & Comments
Respect the power of three Wazirs - they can checkmate a lone King in 47 moves. Also, I think the position in the diagram can be reached, leaving the Black Alfil limited to two squares: (e2) and (g4). Surely White can eventually force a trade of one Wazir for the Alfil. Question: would replacing the Alfil with an Alibaba (A+D) save the draw for Black?
What would be an appropriate tag for hexagonal boards?
Back in [2018-03-04] Kevin Pacey mentioned "the pleasing possibilities of smothered ... mates". My 12x12 variant Rose Chess XII has 96 empty squares, with ten Pawns each on the 4th and 9th ranks. But Black can deliver a smothering mate with a circular Nightrider on the second move of the game. A position so amusing that it earned a diagram at the top of the rules page.
Speaking of XBetza (or rather, IBetza), you should really consider adding a link to your page on Extended Betza Notation to this page. Even if it is not strictly identical to the one used in the interactive diagrams it would be a very helpful edition. I did check for a link to that page before writing this, and I couldn't find one.
The new definition for t could be quite interesting. It also helps that kc covers the old function of t (excluding capture of royals).
Similar to Courier-Spiel, the game adds modern Bishops and improves the Elephants (called Couriers here). Switching the Bishops and Couriers in the initial setup will improve this game. While the b-file and h-file Pawns are now undefended, they are also no longer threatened by hostile Bishops. Jumping the Courier c1-c3 will help to shield the Pawn on (b2).
Some time before 1992, Paul V. Byway included the Ferz in Modern Courier Chess, placing RNCBFQKFBCNR on a 12x8 board. Ken Franklin also placed Alibabas in Leap Chess on 44 squares.
The diagrams on this and the Apothecary Chess-Classic page are missing white's brouhaha squares, and so are both corresponding game courier presets.
I'm not quite sure whether I want to rate this Good or Excellent so I'll go with the higher rating. This is a great way to enhance weaker pieces without making them too strong. An interesting variation of this idea might be to have all the pieces except the king and queen start without their non-capturing king moves and gain them by promoting on the last two ranks.
True. But I have always had the feeling that XBetza notation should be the vehicle to specify that, not the promotion. What I am missing in XBetza is the possibility to specify a side effect that is mandatory when possible, but not blocking the move when impossible.
How about this: the modifier t is a leg separator like a, except that the actual piece move terminates at that point, and the remaining legs only describe the path of its 'influence'. If this is not a unique continuation, all possible realizations will be combined with the move. So where yacabQ would describe a Queen that (by virtue of the y) does a single King-like burn of an enemy, ytacQ would burn every enemy adjacent to the square it lands on, and can even land there if there is no adjacent enemy at all. An Ultima Pincher Pawn would be ytacfapR, where the captureMatrix would be used to forbid the piece (and its influence) to hop an enemy. Unlike actual moves, the last leg of the influence can be a 'hop-on' leg.
If you are prepared to use JavaScript there are many ways you could interfere with the standard operation of the Diagram. There is for instance a routine ScoreMove(move, predecessor), to prep the 'raw' moves coming out of the move generator by determining the piece types of the capture victims, storing those in the array describing the move, and calculating the effect these captures (and promotions) would have on the score. ('predecessor' is the move preceding it, only used to enforce anti-trading rules). Interfering there to add a few burn victims is not very difficult; you just replace the function by a wrapper for it, like:
var OriginalScoreMove = ScoreMove; // remember the standard routine var burnX = [ 1, 1, 1, 0, -1, -1, -1, 0 ]; var burnY = [ 1, 0, -1, -1, -1, 0, 1, 1 ]; function ScoreMove(m, last) { // and redefine it var x = m[0], y = m[1]; // origin var piece = board[y][x]; // moving piece if(IsBurner(piece)) { var n = 4; // 0-3 are the coordinates of origin and destination for(var k=0; k<8; k++) { var xb = x + burnX[k], yb = y + burnY[k]; // coordinates of neighbor square if(IsEnemy(xb, yb)) { // this is assumed to return 0 when (x, y) is off board m[n++] = xb; m[n++] = yb; // add a locust victim m[-2]++; // this counts the number of squares in the move } } } return OriginalScoreMove(m, last); // call the standard routine on the modified move }
I now also made promotion to empty square ('kamikaze capture') possible; it can be specified in the captureMatrix by a 0 (zero), and requested from the WeirdPromotion() custom script by returning 251 for the promotion piece. This means that it would now also be possible to implement the passive burning ability of a Tenjiku Shogi Fire Demon, by detecting in WeirdPromotion() whether a move lands next to an enemy Demon, and return 251 in that case.
Now all that is needed to successfully implement a interactive diagram for Tenjiku Shogi is to give WeirdPromotion the ability to affect other squares.
Edit: I tested this in an interactive diagram of Tenjiku Shogi, and the piece does get removed, but the diagram still thinks there is a piece there.
The ShowMoves problem is now fixed: I reverted to including the loop directives in the compiled move descriptors even when newClick=1, and made the code that performs the click swapping for shooters resistant to their presence. As far as I could see this appears to work.
I now also made promotion to empty square ('kamikaze capture') possible; it can be specified in the captureMatrix by a 0 (zero), and requested from the WeirdPromotion() custom script by returning 251 for the promotion piece. This means that it would now also be possible to implement the passive burning ability of a Tenjiku Shogi Fire Demon, by detecting in WeirdPromotion() whether a move lands next to an enemy Demon, and return 251 in that case.
Positions like this suggest that promotion to colorbound pieces is a poor design choice.
One could also argue that promoting to the weak, color-bound Ferz enriches Shatranj with an interesting strategic theme: one has to plan Pawn manoeuvres such that you won't promote all your Pawns on the same shade. And definitely do not leave the opponent a defender on the other shade when you are playing for a win. This is already true in orthodox Chess, where unlike Bishops can draw even against a majority of 2 Pawns, despite the fact that these would promote to Queen.
It is true that Shatranj is quite drawish, but I think this is more a consequence of the Ferz being such a weak piece than of its color-binding. I doubt that promoting to Wazir would be much of an improvement.
Kamikaze pieces are a form of promotion (namely promotion to an empty square). The Interactive Diagram does support mechanisms for indicating unusual promotions (like the captureMatrix), but unfortunately promotion to empty is not amongst those. The problem is that promotion code 0 (the code of an empty square) is used to indicate there is no promotion, and the piece remains itself.
It should be possible to use another code for indicating promotion to empty, though, and recognize that as a special case in the routine that performs the moves.
The ShowMoves problem appears to occur because this still uses the old highlighting routine. And now that I leave out the loop directive from the internal move descriptors this cuts non-final slider legs with m rights (which should continue after a succesful try) to their first step. I should make the highlighting in ShowMoves also be done with NewClick(); I guess I didn't do that because it never has to deal with a double locust capture, as hovering gives you at most a single potential victim.
A reasonably cheap method for tracking pieces (of all types!) would use an array location[] indexed by (colored) type, where the square numbers (calculated as 128*rank + file) where pieces of a given type sit would be stored in location[type] and location[type+512]. This can be updated in MakeMove() like
function TrackMakeMove(m) { var p = m[-6] & 1535; // moving piece (stripped of marker flags and virginity) if(location[p] == 128*m[1] + m[0]) location[p] = -1; // mark first entry as invalid when it was for the moved piece p = m[-1] & 1535; // promoted type (could be same as mover) if(location[p] < 0) location[p] = 128*m[3] + m[2]; // put destination in first entry when the latter was unused else location[p+512] = 128*m[3] + m[2]; // otherwise it must have been for the other piece of this type, so this piece uses second entry OriginalMakeMove(m); }
and similar for UnMake(). It would not take account of capture of the pieces, (which would be cumbersome because of the possibility of locust capture), so when using the locations for a type it should always be tested whether a piece of that type is actually there; it could still indicate the square where a piece of that type was captured, but which now is occupied by something else.
Limitation is that it would only work if there are at most two pieces of the types of interest. Which for Suzumu Shogi would not be the case, as there could be four Tetrarchs. But somehow it doesn't seem wise to adapt a general feature to a very exceptional case; in virtually every variant there are only two pieces of each type. One could always artificially make the Diagram use two different Chariot Soldiers and Tetrarchs, each present as a pair. After all, we already artificially distinguish a Lion Hawk obtained through promotion from a primordial one, just to maintain a homogeneous mapping from piece to promoted form.
With the aid of this you would only have to look for enemy Tetrarchs in 4 locations, rather than 256. You would do that in BadZone() when you find 'nodes' increased, and for every Tetrarch you find this way you would set the square surrounding it to 'nodes' on an auxiliary board. Moves starting from a thus marked square would then be suppressed, as that piece would be frozen.
The point of paralyze is that figuring out whether a piece is frozen is a rather expensive part of BadZone(), as it has to probe 8 board squares, and that doing this once per piece before the move generation relieves you from doing it for every move of the piece. So you would just be moving that expensive part from one call to another, with a little overhead added for figuring out which type of call you are dealing with:
if(piece == 0) { return IsFrozen(x, y); }
And when the piece is frozen you would also safe the time for attempting to generate its moves. Whether this gains anything would depend on the typical ratio of the number of moves versus the number of pieces. In the Tenjiku setup many pieces start in a smothered position, but the pieces you tend to develop first have an extrordinary large number of moves. So my guess is that it would still be beneficial, because for almost the entire game you would have more moves than pieces.
But it is true you could achieve similar, or perhaps even better savings by remembering which piece you are testing for between BadZone() calls:
var latestPiece = -1; BadZone(x2, y2, piece, color, x1, y1) { var s = 16*x1 + y1; // unique square number of origin if(latestPiece != s) { // new piece latestPiece = s; frozen = IsFrozen(x, y); // recalculate frozen for new piece only } if(frozen) return 1; ... // other tests for non-frozen pieces }
This doesn't require extra calls to BadZone(). It would still generate all moves for a frozen piece to discover only afterwards that they should be rejected if the piece was frozen. But since pieces would almost never be frozen (especially in Suzumu Shogi,where you can get Tetrarchs only by promotion), I suppose this only wastes negligible time in practice.
More could be saved by using a more efficient algorithm for IsFrozen(). But that would require knowing where the Tetrarchs are. But even the most stupid way to know that, scanning the entire board in every new position before move generation, might be competitive: there are only 256 board squares to test, while scanning the individual piece neighborhoods examines 8 squares per piece that has moves. So once you have 32 pieces that have moves, the whole-board scan becomes cheaper.
I wonder if I should build in a standard feature to trach the location of pieces of a certain type (enabled through a parameter like track=N). The AI uses a global variable 'nodes' that counts move generations, and could be used in BadZone() to know hen a new move generation has started by comparing it to the value at the previous call. If the Tetrarch locations would be somehow available, it could use these to mark the squares adjacent to each Tetrarch in a frozen[y][x] board-sized array by the current value of 'nodes' when this value changed, and the test for being frozen would just be
if(frozen[x2][y2] == nodes) return 1;
Tracking would cause some overhead, but variants that do not track any pieces could be protected from that by replacing the NewMakeMove() and UnMake() functions by special tracking ones only when tracking is requested.
This diagram shows a boring draw from Shatranj. If the White King moves towards (f3), then the Alfil can simply go back to its home square (c8). Positions like this suggest that promotion to colorbound pieces is a poor design choice. Try substituting three Champions (Silver Generals) and one Dragon (Ferz+Alfil). Now White can play
1. Champion a7-b6 check, King b7-a6
2. King d6-c5, Dragon g4-e6
3. Champion b8-a7, Dragon e6-c8
4. Champion a7-a8, ignoring the Bare King/stalemate victory and intending checkmate after moving to (b7). An FIDE Bishop (replacing the Dragon in the initial position) might be able to trade itself for a Champion and make White settle for a "mere" Bare King or stalemate victory. Some thoughts on piece values:
Rook=15, Bishop=9.5, Knight=9, Silver General=8.5, Ferz=5, Alfil=4, Pawn=3
What if you sorted based on the timestamp of the last action taken for each article? That way you don't have to worry about unset modification dates, and you can see which articles have changes ready for review.
Thanks for fixing that. To be honest, I was a bit worried that the Suzumu Fire Demon might get messed up, but it turns out I was overreacting. And now that the Lion Dog works properly as well, I can include it and the Suzumu Fire Demon in the same game without needing to use any special code (apart from BadZone for the burning restriction, of course).
As for the paralyze parameter, I'm not sure whether it would actually increase efficiency or not. If paralyze doesn't suspend the BadZone call after move generation you would end up calling it twice instead of once, so it could slow things down even more if I am not careful with it. So for now, I am just going to keep Suzumu Shogi's BadZone code as it is.
I did encounter another minor bug. The highlights for the ShowMoves() function seem to be a bit bugged when using the new move generation. For example, when showing the possible moves of a piece after clicking its name, the Suzumu Fire Demon doesn't show the burn for its ranging moves, and hook moving pieces only show the hook moves for the first square in each direction. It appears to only be affecting atom such as R, B, and Q. It doesn't affect the diagram when clicking pieces on the actual board, but it can be a bit misleading. Thankfully, this shouldn't be too difficult to fix.
I cannot love Courier-Spiel, but I (heart) Shako. Revising my [2006-08-12] comment: Unicorn=10, Queen=10, Chancellor=9, Rook=5.5, Lion=5. Bishop=3.5, Knight=3, Elephant=2.75, Pawn=1 are endgame piece values (for Shako and Unicorn Great Chess) which preserve some formulas I firmly believe in, namely Q+P = R+R and Q = R+B+P and R+P = B+N. The Cannon should be worth 4 Pawns at the start of the game, but decline to half the value of a Rook in the early endgame (2.75 Pawns). I consider short range pieces to have more value than Antoine Fourrière gives them in his Comment. Even the lowly Ferz should be worth 1.5 Pawns on a 10x10 board.
How can I make a kamikaze piece and the fire demon with it ?
OK, I uploaded a new betza.js script. This classifies pieces as shooters during compilation of their XBetza moves (i.e. when the Diagram is initialized), and only messes with the click order for those. I think this should be safe.
The Lion Dog now seems to work, although I used a slightly different description to prevent the 2-out-1-in move being generated twice:
KADGHcavKabKmpafcavKcafcmpafK
The difference is the final f, which in your description was a v. As the Lion Dog has tramplings (e.g. cafK) it is not classified as a shooter, so you have to enter a double capture through 2-out-1-in by first clicking the distant victim, and then the adjacent one.
I also have implemented a new parameter paralyze. When set non-zero it will cause BadZone(x, y, piece, color) to be called for every piece before move generation for that piece starts, with the 'piece' argument equal to 0, and (x,y) the piece location. Returning non-zero in that case will cause no moves to be generated for that piece at all.
I uploaded the zillions file (with piece graphics) now. I tested it and think it works correctly. Please tell me if you should find any bugs or issues.
Indeed, there is a problem here. When the last two squares of the 2-out-1-in move are swapped because they constitute a rifle capture, the click order becomes the same as that for a 2-out trampling. I suppose the lesson is that it cannot be determined just on the basis of a move itself whether it should be treated as a shooting; it depends on which other moves are there. Perhaps the whole idea of automating this is a folly, and it should be made subject to a parameter shooters=1 to enable it.
I will make one more attempt: during compilation of the XBetza decriptor each part can already be classified as a trampling or shooting (or a normal move), and a piece is classified as a shooter only when it has shootings and no tramplings. Then moving up the destination click to before the locust captures will only be done for pieces classified as shooters. It will take me some time to implement this.
Another issue: would it be helpful to not only call BadZone() after a move is generated, in order to allow or forbid it, but also before generating any moves for a piece (indicated by an invalid destination, e.g. x2 = -1), to decide whether any moves should be generated at all for that piece? That would make 'freezing' of pieces more efficient.
Greg Strong wrote on 2023-01-25 UTC
Is that right or are there any differences I missed?
In Janus Chess castling with the far Rook makes the King move 4 steps.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
25 comments displayed
Permalink to the exact comments currently displayed.
Since people keep wanting to use tags for information that is already stored in the database, I have modified the footer script to include categories and board dimensions just above the tags section.