Large Shogi vaiants

[hgm]

Recently the large Shogi variants were brought to my attention. I had neverrealized that these are not played with dropping back the captured pieces (Crazyhouse fashion), and so basically are normal Chess with different pieces. There are:

Chu Shogi (12 x 12)
Dai Shogi (15 x 15)
Tenjiku Shogi (16 x 16)
Dai Dai Shogi (17 x 17)
Maka Dai Dai Shogi (19 x 19)
Tai Shogi (25 x 25)
Taiyouku Shogi (36 x 36)

While the biggest of these more seem like works of art produced by bored monks than playable games, Chu Shogi and Tenjiku Shogi actually are very interesting and exciting games. Although there are many more pieces than in FIDE Chess (three or more board ranks are filled behind the pawns, rather than just one) the pieces are on the average much more powerful, so the games proceed at high pace. They have a piece called 'Lion', which is worth way more than a Queen (which they also have), and can make two captures in one move (or snatch a piece, and then withdraw!). And in Tenjiku Shogi there are Fire Demons, which capture everything bordering their to-square in a way reminiscent of Atomic Chess (except they don't explode themselves, so they can continue doing it).

I intend to build an engine for playing these games (starting with Chu). To handle them in WinBoard, I needed to gratly expand the number of piece types, as in Taikyoku you already start with 209 different pieces (and then almost each of these can promotes to something else...). To avoid having to make such a huge nuber of bitmaps, I equiped WinBoard with a routine for rendering pieces based on the way they move. This makes Chu Shogi look like this:



(Can you spot the Rooks? They are in front of the Bishops! )

[Daniel Shawul]

Crazy monks come up with weird stuff. Are there people who actually play these games? Some of the bitmaps seem difficult to auto generate like the ones with circles and round corners. Good luck with building an engine because I am not touching these ones except maybe chu shogi..

[hgm]

Chu Shogi actually seems to have a playing community, even in the west. (E.g. there is a German Chu Shogi Association.) I am pretty sure the 36x36 game has hardly ever seen a completed game in its existence. (And these are old games! I think Chu dates from the 12th century!)

An interesting aspect of those games is that evaluation from scratch scales with the number of pieces, which scales as the square of the board edge. Mobility for the sliders even has the potential to scale as number of pieces times the board edge, so it is an O(3) process. Incremental evaluation of mobility only scales as O(1) in the board edge, however: you just have to scan all rays through the from- and to-square, to find the sliders that pass through there, and extend or block their moves.

So you would need a completely different design of the engine, using techniques that wouldn't pay off yet on 8x8. That is what intrigues me.

[Kirill Kryukov]

Hi G.H., Great work on the piece images. Can you make them available separately separately as graphics files, or, better yet, as a true-type font?

I guess with dropping a game in those variants would last forever. No dropping is interesting, because this means now the endgame is possible, so endgame tables can be constructed.

Is position and move notation already established for those games?

Good luck supporting these games in Winboard and making an engine - it's a thrilling development for me.

[hgm]

Hi G.H., Great work on the piece images. Can you make them available separately separately as graphics files, or, better yet, as a true-type font?

Not really, because they don't exist in that form. The way it works is that WinBoard paints the pieces on the display by compoing them from a small number of 'components' (for which I did give it images). E.g. the black Lance image without the central line is such a component, and it is drawn in every direction where the piece can move 2 or more. For a Queen this producs the 'flower' hape. For all directions where the range is infinite, a radial line is then drawn on top of the flower (from another image). For directions with only a single step a square is drawn, and for dirctions into which the piece does not move at all, I made images for several types of indentations, from which one is chosen depending on the range of the neighbor directions on either side. White pieces are made by first drawing the black piece, and then repeating the process with a set of bitmaps for slightly smaller components, painted in white on top of the black piece, so that a black outline remains. (And only then the radial 'slider' lines are drawn.)

Only for pieces with irregular moves, (Knight, Lion, King) I made individual bitmaps according to the old system used by WB, and I changed the latter to only use the new drawing system if it has no explicit image available.

Of course it would always be possible to save a screenshot of a position with all these pieces (WB even has a Save as Diagram menu item for that), and then cut it up with an image editor like IrfanView into files for the individual pieces, and change the square color to transparent. Butthe wholeidea of the auto-generation was that I would not have to do that...

I guess with dropping a game in those variants would last forever. No dropping is interesting, because this means now the endgame is possible, so endgame tables can be constructed.

Agreed! I only got interested in these games when I learned they had no drops. (Notwithtaking that on the smaller games drops are a great asset.)

I already learned that Gold has no mating potential on 12 x 12 (a Tokin, that is; A primordial Gold you would of course promote to Rook for an easy win). A Drunk Elephant has mating potential upto 14 x 14 (At which point even a Crown Prince (= second King) would loose it too.

Is position and move notation already established for those games?

It seems The Shogi Association defines a PSN-like format, where all promoted pieces are indicated with a + in front of the unpromoted name. (A very bad idea for non-drop-games, it seems to me...). FENs I have seen use commas between all pieces, to allow multi-character piece names. I don't know if there are standard piece abbreviations. Anyway, for the bigger variants multi-character names are unavoidable, and require some adaptations in WinBoard.

Good luck supporting these games in Winboard and making an engine - it's a thrilling development for me.

Thanks. It is quite a challenge, and raises some very interesting problems. (Like how to sort Lion moves in Quiescence Search, and prevent search explosion.)

With some extra dedicated bitmaps for the Fire Demon and the jumping Generals I am now also ready for Tenjiku:



Preventing search explosion by plunder raids of Fire Demons will be even more difficult there!

[Kirill Kryukov]

Hi G.H., Great work on the piece images. Can you make them available separately separately as graphics files, or, better yet, as a true-type font?

Not really, because they don't exist in that form. The way it works is that WinBoard paints the pieces on the display by compoing them from a small number of 'components' (for which I did give it images). E.g. the black Lance image without the central line is such a component, and it is drawn in every direction where the piece can move 2 or more. For a Queen this producs the 'flower' hape. For all directions where the range is infinite, a radial line is then drawn on top of the flower (from another image). For directions with only a single step a square is drawn, and for dirctions into which the piece does not move at all, I made images for several types of indentations, from which one is chosen depending on the range of the neighbor directions on either side. White pieces are made by first drawing the black piece, and then repeating the process with a set of bitmaps for slightly smaller components, painted in white on top of the black piece, so that a black outline remains. (And only then the radial 'slider' lines are drawn.)

Only for pieces with irregular moves, (Knight, Lion, King) I made individual bitmaps according to the old system used by WB, and I changed the latter to only use the new drawing system if it has no explicit image available.

Of course it would always be possible to save a screenshot of a position with all these pieces (WB even has a Save as Diagram menu item for that), and then cut it up with an image editor like IrfanView into files for the individual pieces, and change the square color to transparent. Butthe wholeidea of the auto-generation was that I would not have to do that...

OK this makes sense. Still those piece images are nice. It's insane how those games are supposed to be played with nothing but kanji characters on top of the pieces. I saw some diagrammatic sets for standard shogi, but not for the larger variants.

I guess with dropping a game in those variants would last forever. No dropping is interesting, because this means now the endgame is possible, so endgame tables can be constructed.

Agreed! I only got interested in these games when I learned they had no drops. (Notwithtaking that on the smaller games drops are a great asset.)

I already learned that Gold has no mating potential on 12 x 12 (a Tokin, that is; A primordial Gold you would of course promote to Rook for an easy win). A Drunk Elephant has mating potential upto 14 x 14 (At which point even a Crown Prince (= second King) would loose it too.

Interesting!

Is position and move notation already established for those games?

It seems The Shogi Association defines a PSN-like format, where all promoted pieces are indicated with a + in front of the unpromoted name. (A very bad idea for non-drop-games, it seems to me...). FENs I have seen use commas between all pieces, to allow multi-character piece names. I don't know if there are standard piece abbreviations. Anyway, for the bigger variants multi-character names are unavoidable, and require some adaptations in WinBoard.

Is Winboard a Unicode app? With Unicode you can encode any piece with single character, although ASCII is probably preferable as a standard for comatibility with legacy tools.

[hgm]

Unfortunately WinBoard is not unicode, but uses code pages to encode non-ascii characters. The Chinese translation gave me quite a headache...

Btw, it occurred to me that it would be quite possible to temporarily change the 'Save as Diagram' function of WinBoard such that it does not save the whole board as a single bitmap, but every square as a separate file. That just requires putting a loop around the existing routine, and reducing the area it dumps. I am not sure .bmp format can support transparance, though. But it would certainly be possible to get the set with some neutral backround color, like pale yellow. (I just would have to set the WB square colors to that before making the dump.) The files would be likely to get non-descriptive names like piece027.bmp, however. Or perhaps I could derive the filename from the way they move too, like p11111111.bmp for a King, p99990000 for a Rook, p11119999 for a Dragon Horse, etc.

Perhaps a good thing to do once I have programmed in all the move patterns for Tai and Taikyoku too.

[hgm]

Tai Shogi (25x25 board):

[Kirill Kryukov]

Great improvement over the authentic set (the wall of up-side-down kanji).

[hgm]

Indeed. Although the 'purists' of course will always demand the kanji (and probably lose 300 Elo useing them to play! ). So WinBoard can do these too:

(Image cut in two to not upset the layout of the forum thread)





Atually these are kind of auto-generated too: I just have WinBoard directy ender the kanji text on the display, from a Japanese font in shift_jis encoding. So no bitmaps of each piece are needed, just a list of names of the pieces as text in the proper encoding (made by someone who assists me in this). The user can select the font and point size. WinBoard just has to supply a few different sizes of 'koma' as bitmaps, and then renders the text on top of it.

It is quite remarkable the Japanese do not seem able to make a distinction between the abstract game and the material with which it is played. In Chess we play pretty much with anything (I have seen piece sets made out of Star Wars personalities), and our diagrams look nothing like Staunton pieces. But to a Japanese something that doesn't use kanji pieces just is not Shogi!