Ratings & Comments

This preset of yours for detecting captures is huge. The fact that it reliably detects where the suicide occured means that I can use it to test whether the suicide is a King's move away from the moving Fire Demon and ensure that no suicides are done when a non-Fire Demon moves, which should solve the majority of problems with coding the burning move. If something similar could be used to detect the type of piece affected by the suicide, that should be everything I need to enforce the burning rules using suicides, at least in theory. Best of all, I can just ask players that haven't made a burn after moving a Fire Demon rather than worry about displaying legal moves on the board.

You could adapt it. For the multi-move variants, there are usually the same number of move parts each turn. So, it makes sense for these games to do the multi-part analysis globally for all pieces. But for games that include pieces with multi-part moves, you may want to reserve the multi-part analysis for specific pieces and tailor it to each piece that needs it.

This is what the original Suzumu Shogi preset (and all presets using the same general codebase) does, which is largely thanks to its isdoublemove subroutine. So, I guess I could use integers instead of booleans and sub ismultimove instead of sub isdoublemove to keep track of which part of the move suffices. The only major problem is that I'm not exactly sure how to enforce rules for the third part of a three-part move. Perhaps I am overthinking it though. Perhaps just copy-pasting and tweaking the code for the second part of multi-moves will be enough. This requires testing, but thankfully, the Taishin Shogi preset (which is fully coded, at least for enforcing the old rules) affords just such an opportunity.

Edit: I figured out how to detect the type of piece that committed the suicide. Now we should be all good.

On the other hand, with an initial leap the blocking would only be on a single diagonal, rather than having to check the nearby orthogonal squares as well. A tradeoff really, though in any case due to the ability to avoid nearby blocking pieces the t[HB] is probably too powerful (or, on small enough boards, too awkward) to use in (most?) games anyway.

I've been working on implementing this game in Ai Ai, and have realised that there is an error in the write-up here: the Knight does not promote to Gold General in Tengu Dai Shogi, it promotes to a new piece which moves as a Chess Knight or as a Gold General. The text description and diagram are visible under the 桂馬：けいま heading on the original Japanese page.

I agree that a piece that changes direction after 3 steps could be awkward to visualize. It would be worse, though, if the first step were a jump to the third square, because with a sliding move, you can easily see if a nearby piece blocks the movement.

I believe this page to now be ready for publication

I realized the role that $width and $height play in centering the borders for highlighting spaces, and with that in mind, I simplified the code in draw_grid_png.php and made adjustments to the $width and $height of Shogi pieces and to the values of $offx and $offy in image_dimensions.php. By using proper values for $width and $height, the code will always apply CSS for margins and padding to the space class rather than to each element of the space class.

I didn't immediately recognize the importance of $width and $height, because I created these variables years before I ever added the ability to display legal moves by highlighting spaces. These variables describe the width and height of spaces, and they are used when automatically generating a board to know what dimensions to give to spaces. But sometimes an image of a board is used instead, and when it is used, $width and $height should match the size of the spaces on the image.

This is what I was neglecting to do. The highlighting in Shogi was a bit off, because the value of $height did not match the height of the spaces on the images of Shogi boards.

Since Shogi divides each space by lines, there are two choices on how to specify the dimensions of a space. One is to use the inner space between the lines, and the other is to extend the size to include the lines. I tried both and chose the latter for Shogi.

For automatically-generated boards, the centering of borders for highlighting should now be done automatically. But for boards provided as pre-drawn images, it's important to match them up with the correct values for $width and $height. One way would be to size the board with spaces the same size as the dimensions given for the piece sets to be used with it. Abstract and Alfaerie sets both normally use 50x50 spaces. Another way would be to provide correct values for your board. I could add these to the image_dimensions.php script for specific boards.

Should be fixed now.

Another possibility for detecting a suicide move is to store the board position before the move into a variable, then compare the new position after the move to the stored position and see what differences there are.

This could potentially solve the problems of detecting a suicide move if I knew how to do it.

Here's a preset I made to demonstrate how to do this:

https://www.chessvariants.com/play/pbm/play.php?game%3DChess%26settings%3Dspotcaptures

This records the position of every piece on the board in an array whose keys are coordinates and whose values are piece labels. It does this both before and after a move. It then goes through the current positions of pieces. For each empty space, represented with the @ piece, it compares it with the previous value to see if it was empty before. If it wasn't empty before, it records it as a capture.

Since I am already writing this, would the system used for the multi-move variants be able to handle moves with three or more parts (i.e. that of the Lion Dog in Maka Dai Dai Shogi)?

You could adapt it. For the multi-move variants, there are usually the same number of move parts each turn. So, it makes sense for these games to do the multi-part analysis globally for all pieces. But for games that include pieces with multi-part moves, you may want to reserve the multi-part analysis for specific pieces and tailor it to each piece that needs it.

I've been working on this more today. Thanks to having a development server, I've been able to make extensive changes without regularly introducing bugs into the scripts people were using to play games. I realized that I could use margins to position the highlighting, and I moved as much of the CSS as I could from each IMG's STYLE element to some STYLE tags. This reduced the HTML code and the filesize of the page. I also added some code that is more adaptive to grids with unusual geometries, though I didn't test it on anything more unusual than Shogi. I made the highlighting of the last move made always the same color as the other highlighting, and I increased the border size for the piece that last moved to 5px, which fits the space better. As mentioned before, I'm now using circular borders to highlight hexagonal spaces. I slightly reduced the size of borders highlighting empty spaces from the size I made them yesterday, because it looks better that way, though I kept them larger than they used to be.

Since it sounds like your Fire Demon piece is making a multi-part move, you may want to break down the whole move and analyze it step-by-step. You will find examples of this in multi-move variants like Marseillais Chess and Extra Move Chess.

Hmm. Perhaps the step-by-step approach would be better. After all, the Suzumu Shogi preset is essentially on a more restrictive form of the other multi-move presets with more pieces.

So the tentative process would then be the folowing

Do a regular move

• Normal move
• Normal capture
• King step (capture)
• King step (non-capture), pass (double move)
• Single King step (non-capture), return to origin square (double move)

Then I would need to assess whether or not there are pieces available to burn (which should be easy thanks to the burn subroutine in my Tenjiku Shogi preset). If so, after the move, do an igui capture or pass.

Or it may be simpler to simply always give the player to optionally shoot any enemy piece a King step away after moving.

Another possibility for detecting a suicide move is to store the board position before the move into a variable, then compare the new position after the move to the stored position and see what differences there are.

This could potentially solve the problems of detecting a suicide move if I knew how to do it.

Since I am already writing this, would the system used for the multi-move variants be able to handle moves with three or more parts (i.e. that of the Lion Dog in Maka Dai Dai Shogi)? This will be important for my larger games with Lion Dogs, Furious Fiends, Kirin Masters, and Phoenix Masters, as well as if I use the move breakdown method for the Fire Demon's burns.

This game was a bit neglected on my part for a while, partly because of my interest in large Shogi variants and the long process of experimentation with the Suzumu Fire Demon's move. Now that those are out of the way, I have decided to give this page a facelift. I have added an interactive diagram to this page and updated its images to keep its style in line with the rules pages for Yangsi and Ryugi, and I did some double-checking to make sure the rules were in line with those of Yangsi and Ryugi. I also fixed a few typos in the ruleset references for the Hectochess and Ryugi presets.

Now all that is left is the difficult tasks of implementing the Suzumu Fire Demon's burning move in Game Courier, implementing the Lion Dog in Game Courier (for the larger games in the Suzumu family), and figuring out how to implement Cannon Shosu Shogi in Game Courier (The hopping moves make it impossible to use the code I used for Shosu Shogi and Futashikana Shogi).

Unfortuneatly, I could not reproduce the bug, but I'll tell you if I find it again!

I've added the implementation in the Interactive Diagram. Still need to add it in Game Courier though.

Edit: Apparently by happy accident, the Game Courier preset had this implemented already without me realizing it.

Well, this is kinda weird lol. I notice I am listed as creating the zrf for this game. I'm pretty sure I did not lol. At the 'zillions of games' site is says this ...

Game: Abagoren Chess

Invented 1844 Implemented by Malcolm Webb, 2013-01-19.

No idea why this game is listed in my info!!

Thanks Ben, great work, and the zip would work, all is good.

I guess I worded that wrong. What I meant to say was the the highlights for empty squares are slightly off center.

Is there a way to detect suicide moves in Game Courier (form XY- or @-XY)? I'm trying to figure out how to implement the new burning ability for the Fire Demons, and I think suicide move are the best option to keep things simple. But I'll need to know how to do the following in order to use suicide moves to execute burns:

• Detect a suicide move on the board
• Detect whether the value of thismove is a suicide move

Once I successfully implement the new burning moves I can carry that over to the other games in the Suzumu family.

The file name did not match the URL; I've fixed that, and can download the zip (but don't have ZoG to test it).