Ratings & Comments
satellite=desert
files=8
ranks=8
promoZone=1
promoChoice=QRBN
graphicsDir=/graphics.dir/alfaeriePNG/
squareSize=50
graphicsType=png
lightShade=#ffff80
darkShade=#bf998c
rimColor=#077208
coordColor=#ffff40
borders=0
firstRank=1
useMarkers=1
newClick=1
atomicCapture=0
pawn::::a2-h2
knight:N:::b1,g1
bishop::::c1,f1
rook::::a1,h1
queen::::d1
king::::e1
|
|
The Queen burns like a Fire Demon here.
Strange. I had not tried it for WeirdPromotion, but I did now, and it works for me. The version on the CVP website has exactly the same size as the one I am using locally.
[Edit] Try refresshing the browser cache. Before I did that I had the same behaviour as you describe in the Diagram above.
Sounds awesome. Only problem is that returning 512 for the promomtion it doesn't work like it should. Instead of burning adjacent pieces it simply burns the moving piece as if you returned 251 for the promotion.
Respect the power of three Wazirs - they can checkmate a lone King in 47 moves.
True. But not very relevant. Three Ferzes do it faster when not all on the same color. (Addmitted, this rules out 1/4 of the cases.) But in Shatranj stalemate is a win, and even two Ferzes or Wazirs can force that on a bare King. And the worst case for the Ferzes is two moves faster than for the Wazirs, even when they are on the same color.
Unfortunatey a general t modifier is a bit hard to implement. Which is a pity, as with the unload modifier it would make it possible to describe magnetic pieces and catapult pieces.
So for now I added capture of pieces adjacent to the destination as a standard feature, controllable through the capture matrix and from WeirdPromotion(), as internally it uses the promotion element of the move array to trigger it. An @ in the captureMatrix orders promotion to piece number 512 for that particular combination of attacker and victim (wher the latter can also be an empty square). Now this is an invalid piece number, and used as a kludge to indicate 'burning'. How exactly this burning works depends on a new parameter atomicCapture=N. For N=0 it does Tenjiku-type burning: only enemies get burned, and the capturer survives. For larger N is gives you explosion like in Atomic Chess: all adjacent pieces are destroyed, friend and foe alike, but the first N piece types from the table survive, while the capturer always selfdestructs.
Now this works the same when you return 512 from WeirdPromotion(). But you have additional control there. By returning 512+C (0 < C < 256) you also trigger the burning. But in that case it burns only the squares selected through the bits of C, where 1 = N, 2 = NE, 4 = E, 8 = SE, etc. So WeirdPromotion() could do additional testing on the board to decide whether an adjacent piece should be burned or not. This could for instance be used to implement Ultima Pincher Pawns, by checking whether there is a friendly piece behind the adjacent one.
All this only works with newClick=1, which unfortunately means that the move diagrams (using the old highlight code) would not show the burning. It is not easy to cure that, as the move generator doesn't know about it (as far as that it is just a promotion), and no clicks on the burn victims are required . (During hovering over the move diagram the highlighting is as if the hovered square had received the second click, and it shows where the third can go.)
BTW, I now added a link to the Extended Betza article.
Now I see what you mean. I don't think it is something I have done!
To me they look normal!
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.
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
25 comments displayed
Permalink to the exact comments currently displayed.
It works now.