Ratings & Comments

To me they look normal!

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.

This page is now ready for review, please.

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.

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.

I have updated the database and relevant scripts to better accommodate 4D games by including a new field for the 4th dimension called BoardRealms. However, I'm not sure what value to give it for this game or what value to change BoardLevels to now that it doesn't have to do all the work for both the 3rd and 4th dimensions.

Since a toroidal board does not count as a 4D board, I removed the 4D category from this page. A 4D board is one where each coordinate is designated by 4 values, each one representing a different dimension. But each coordinate in this game is designated only by its rank and file.

Playing about with this diagram I did seem to have run into some strange bugs:

• Passive burning works correctly, but not when the promotion dialogue turns up. E.g. Rook General g4xg13 from the opening setup survives even though it lands next to the Fire Demon. If I promote it then move it next to the FD again it's burned as expected
• Under certain conditions (it seems to be contingent on whether it's a piece's first move), promotion seems to become corrupted: it gives me the promotion dialogue, but doesn't promote it regardless of which option I select. Subsequent moves allowing promotion (into/within/out of the promo zone) likewise ask but don't react, and the move seems to permute surrounding pieces in an unpredictable way, often with the same highlighting as for burn victims, though sometimes on squares with pieces still (or newly) on them. I think this is contingent on whether it's a piece's first move:
  • 1. RGg4xg13=GG works (besides the above bug allowing it to survive)
  • 1. Pg5–4 Pg12–g11 2. RGg4xg13 similarly works
  • 1. Pg5–4 Pg12–g11 2. RGg4–g5 Pg11–g10 3. RGg4xg13 triggers the bug

The two bugs together also mean that a piece subject to the second bug can never be passively burned within the promotion zone

Extending the number of ranks and files to infinity does not also increase the axes of movement through individual spaces. This is a large 2D game, but it is not 3D or 4D. So, I have removed it from those categories.

It should be the same as for rows/columns in 2d hexagonal games, right? (I'm not sure if we have a consistent policy for that...)

4d games are rare enough that I wouldn't have bothered to add a database column. It will probably cause confusion for new authors. But there's already reason to expound on the categories and index information on special cases, maybe as tooltips plus a link to a page describing non-obvious conventions?

The diagram on the page superficially resembles that of Sphinx Chess, but it has only two axes of movement, the vertical and the horizontal. If you follow the lines of movement of pieces on this board, you will see that multiple boards have been placed together to create a larger playing area on which pieces are still moving in two dimensions.

4d games are rare enough that I wouldn't have bothered to add a database column.

Since I was adding code to the footer to indicate a board's dimensions, it seemed more appropriate than treating them as 3D games.

It will probably cause confusion for new authors.

I have added tooltips to the Edit Item form, and if there are other forms they should be added to, I can do that. I have also used parentheses to make it clearer what the dimensions of a board refer to. For 3D boards, a single pair of parentheses go around the files-by-ranks part, and levels goes on its left. For 4D boards, another pair of parentheses goes around the 3D board dimensions, and the 4th dimension goes on the left. The convention I'm following places increasing dimensions on the left, and it treats the number of ranks as the first dimension. This is because in the typical Chess variant, the board has two sides, and each player starts with all his pieces on one side. So, the distance between two sides would be the number of ranks. The second dimension, the number of files, is about how much space each side has to spread out its forces. Since we normally write files before ranks in algebraic notation, it makes sense to add higher dimensions to the left side. Also, this was the convention followed in some 3D games I looked at last night. And it's also sort of how Arabic numerals work. The leftmost digit in a numeral has a higher value than those to the right.

Indeed, when WeirdPromotion() is used to pieces that would also promote otherwise it involves more than just returning the desired promotion piece. The Diagram makes a special call to it (recognizable by promo = 1021) to inquire whether there might be promotion choice, and in the passive burning case this should be used to suppress the choice that maxPromote and promoZone would suggest. I don't think the current version does this entirely correct for Shogi promotions, though. I will have a look at it tomorrow.

When representing a 4D game in two dimensions, which is what we're limited to on a computer screen, it makes sense to pair together a higher-dimensional label with a lower-dimensional one. This is especially so with something like Game Courier, which gives you only files and ranks to work with. This can lead to a coordinate like Dc23, which I hovered over randomly, which transposes the second and third dimensions. Bearing that in mind, it looks like this game has 5 ranks, 5 files, 5 3D rows or levels, and 5 4D columns or realms.