Large Shogi variants in XBoard

[hgm]

The problem with the large Shogi variants is that the feature an extraordinary large number of piece types (sometimes over 100). Designing graphics for rendering each of these pieces would be a horrendous job.

A poor-man's solution to this problem would be to render the pieces not as images, but as text in a scalable font. The WinBoard Alien Edition uses this method for all board sizes where it has no bitmaps (i.e. 16 of the 18), based on a built-in table that maps its 'extra' piece types (i.e. those it has in addition to regular WinBoard's 22) on kanji. There is no working XBoard for the Alien Edition fork, however.

I have now been working to provide a similar solution for the regular edition of XBoard, although I did not get yet to adding additional pieces. (XBoard 4.8 supports 44 pieces, all with default images defined for them.) This does not work through a built-in table, however, but through a (new) configurable option -inscriptions. This option can define a string, where each symbol in the string will then be used for writing on top of the piece to which it corresponds (according to XBoard's canonical ordering of pieces). The string is interpreted as utf8 unicode, so it is possible to define kanji inscriptions.

The idea is that all pieces could then use the same image of a blank Shogi tile, while XBoard would then write the identifying inscription on them as text. To facilitate this the fall-back cascade for piece images has been extended: if the user specifies a -pieceImageDirectory (-pid), XBoard will first look for an image of name White/BlackXXX.svg to use for piece type XXX (e.g. XXX=Knight), but if that is not there, it will first try the piece-independent name White/BlackTile.svg before trying White/BlackXXX.png in the pieceImageDirectory, and then the default piece theme in its own installation files.



Above you see an example of how this works out in regular Shogi. The -pid was set to a directory containing only svg images for a general Tile, a somewhat bigger blank tile for the Kings, and complete (i.e. including the kanji inscription) Pawn tiles. XBoard was then invoked through

./xboard -inscriptions " 桂角飛香銀...金.とN馬龍L玉" -ncp

which defined the kanji inscriptions for P,N,B,R,... The inscription for P was defined as a space, because the svg image already carried its own inscription. (The kanji for Pawn in the font I used seems bigger than the others, while even a normal size would have been difficult to fit on the smaller Pawn tile.)

The result seems acceptable. My plan now is to implement a similar mechanism (including the fall-back on a common bitmap image) in the WinBoard front-end of the regular edition. And of course strongly increase the number of piece types, by adding some hundred(s) of 'unnamed' pieces, which have no built-in moves (the engine will have to define those) and no 'native' image (always falling back on the common 'Tile' image).

[JoshPettus]

That sounds amazing Harm! So am I understanding it increases/decreases the size of the blank tile for pawn and king types? Or are these separate blank tiles?

[hgm]

These are separate blank tiles. (Or in the example above for the Pawn not even blank.) Currently every piece that does not want to make use of the common svg for an 'average size' tile will have to be defined by its own svg. Even if they would just be blank tiles. E.g. if you would want Lance and Knight to have a somewhat smaller size, you couldmake an svg file for a tile of that size, and put two copies of it in the -pid, one for Lance, the other for Knight.

That might not be ideal (although making multiple renamed copies is easier than making individual images), but at the moment I don't see a better solution. Individual images could also be used for pieces where the inscription system does not work. (E.g. because the required kanji are not in the font, or because they need two kanji where the other pieces can do with a single one.)

In the larger variants the assignment of sizes to the various piece types is a bit controversial anyway, and I expect that a system where the King is bigger and Pawns (plus perhaps Go Betweens) are smaller, and all other pieces of the same size is reasonably satisfactory.

I hope that using this scheme will provide a rapid route to having XBoard support Dai Shogi, which HaChu can play, but XBoard 4.8 cannot handle for lack of piece types. The 'notation problem', which rears its head when there are more than 26 unpromoted piece types (as there are in Dai), will be solved by allowing quote and exclamation-point suffixeson the piece ID (so that L can stand for Lance, and L! for Lion, D for Dragon King and D' for Flying Dragon, etc.). This works in SAN and FEN without much loss of readability.

[JoshPettus]

Hmm, would it possible to variably scale the svg according to some table value by piece type? So you only have to work off of one image. Or would that not work/ too much effort? Proportions be completely off?

[hgm]

Scaling would work if you are careful about the positioning of the scaled image. (But it could not be generalized to WinBoard, which uses unscalale bitmaps.) The problem is knowing how each piece should be scaled. In the WinBoard Alien Edition there is one board size that draws tiles for the large variants, and it has bitmaps for them of 5 or 6 different sizes. The size of the tile required for a piece is tabulated together with the moves and kanji inscription of that piece.

This leads to a very large amount of very specific knowledge in the GUI, however. The shogi piece table in the Alien Edition is enormous, as most pieces have to appear several times, because they all have fixed promotion partners. So a Gold in Chu (where +G = Rook) has to be a different piece from G/+G in Maka Dai Dai (where +G is a Free Gold). I would like to keep the regular edition of XBoard free of such specific knowledge.

One way to do it is to allow the user to define several Tile images in the pieceImageDirectory, e.g. Tile1.svg, Tile2.svg..., and then cycle through those as fall-back choice. E.g. if you have 3 tiles, the first piece uses Tile1, the second Tile2, the 3rd Tile3, the 4th Tile1, etc. The user or engine can then assign the pieces (through the pieceToCharTable) in such a way that they get the desired tile size. But this will no doubt conflict with the existing piece ordering in regular Shogi or Chu.

Another problem I run into is how to handle pieces that promote to the same piece, notation wise. E.g.in Dai Shogi Pawn, Knight, Wolf, and Iron (and 5 others) all promote to Gold. At first glance the promoted versions should be written as +P, +N, +W, +I. But what should be written on them? If they all carry the kanji for Gold in red, they are not distinguishable on the board. So it seems very inconvenient to use (say) +Wh9 and +Nh9 to indicate which of two Golds should move to h9, if the player cannot distinguish a +W from a +N by appearance. It would be much more helpful to consider +W and +N as the same piece (say G', an unpromotable Gold), and use the normal file/rank disambiguation, like G'gh9 vs. G'ih9.

This has consequences for how to assign pieces to internal piece types. To force disambiguation of SAN moves XBoard must really think that two pieces able to reach the given target square are of the same internal type, as it assumes different internal types will have different ID. So to get the desired behavior the P, N, W, I, ... should not promote to their normal promotion partner, but to the single piece denoted as G'. XBoard could be made to do this by using the convention that defining the normal promotion partner as '*' rather than '+' in the pieceToCharTable it uses the promotion partner of the Pawn instead.

This has the disadvantage that the internal type of the promotion partner still has to exist, although it is not really used. (Only to reserve a place in the pieceToCharTable to put the *.) So it would not be possible to use the promotion partner for something else, like using the piece that normally would be +N for W. A smarter way to indicate this 'common promotion' in the pieceToCharTable would therefore be to write the * as a suffix on the piece itself. I.e. X* would be seen as a single piece description, and indicate that the piece can promote to the first piece of the promoted series (normally +P).

However, in kanji representation +P is somewhat unique, because it has its own 'Tokin' kanji,which is not just the kanji for Gold in red. Perhaps SHogi players would consider it offensive to describe a +N or +W as a Tokin, as in regular Shogi +N would never be called a Tokin. (Of course there it really is a different piece, because of demotion on capture when it goes to the hand.) So perhaps it would be better to make the * suffix indicate the piece promotes to the promotion partner of Knight (the second piece of the promoted series). So that the first piece of the promoted series could be displayed as Tokin, (defined as + in the peiecToCharTable, so referred to as +P in notation), and the second piece in the promoted series defined (and referred to) as G', to which N, W, I, ... then all promote by defining them as N*, W* and I*, for which we could also use otherwise unused piece types in the promoted series.

[kranium]

Very very nice work with winboard/xboard H.G...
it's beautiful what you have done with it.

[hgm]

Thanks for your appreciation. I must admit that by now I am quite happy with the result myself. It does almost everything I want it to do. For XBoard someone is currently working on making it 'accessible' to the visually impaired, as a GSOC project, which as a side effect will also allow moves to be spoken without requiring a screen reader.

[JoshPettus]

That would be fantastic! especially as I don't know If I could get a screen reader (orca?) working on the mac version... Especially for the non-cocoa relayed stuff.

What I was imagining was putting such sizing values in the inscription command line. -inscriptions " 桂,75,角,75,飛,85,....ect" and you would have to get it to be sized off the base... Yah, I forgot about winboard, probably a lot of work for little real benefit. They really do look great for as is, and a great idea for those pesky large shogi variants.

[hgm]

Speaking without screen reader seems to make use of some standard Linux Text-To-Speech interface. I have not really studied the patched code yet (it is still under development, in a gtk3 branch at GNU Savannah), so I am not sure how it works. But last time I tested it did indeed speak the moves, although I never installed Orca.

[JoshPettus]

I wonder how much work it would be to move the mac stuff over to gtk3, my hope is little as the library exists for gtk3 and it's the same library. (but you never know till you try it)