Released: updated version of WinBoard Shogi-Variants package

[hgm]

The WinBoard Shogi-Variants package has been updated. It now includes the engine CrazyWa, to offer Wa Shogi.

It now supports the following variants:

with drops, through Shokidoki, and the somewhat weaker CrazyWa:
* mini-Shogi (5x5)
* Judkin's Shogi (6x6)
* Tori Shogi (7x7)
* Euro-Shogi (8x8, Shokidoki only)
* regular Shogi (9x9)
* Wa Shogi (11x11, CrazyWa only)

without drops, through HaChu:
* Heian Shogi (9x9)
* Sho Shogi (9x9)
* Chu Shogi (12x12)
* Dai Shogi (15x15)

without drops, no engine available, but supported in WinBoard
* Tenjiku Shogi (16x16)
* Dai Dai Shogi (17x17)
* Maka Dai Dai Shogi (19x19)
* Tai Shogi (25x25)

More info: http://hgm.nubati.net/ShogiVars.html
Direct download link http://hgm.nubati.net/WinBoard-Chu.zip

[Drunken-Elephant]

Hi there,

I was wondering if you had gotten HaChu to work with Taikyoku Shogi. It's mentioned on http://hgm.nubati.net/HaChu.html that it's designed for large variants such as Taikyoku but I haven't been able to find a download link for a version that supports it.

I love the work you're doing, keep it up!

[hgm]

I never got to the point of implementing Taikyoku Shogi. Last things I did with HaChu was implement shrunken versions (on 13x13) of Dai Dai and Maka Dai Dai Shogi. I also started implementing on Tenjiku Shogi in HaChu, but I never got that to work.

HaChu is in fact only a partially finished project. The original idea was to develop an engine based on an incrementally updated attack map. The work to update such a map doesn't increase with board size, and geatly accelerates the generation of captures in Queiescence Search. So it is ideal for handling very large games. I never got to actually program the incremental update, though. So currently it generates the attack map from which the other parts of the engine works from scratch in each node, which sort of defeats the purpose. This has the consequence that it would become very slow for a game as large as Taikyoku Shogi.

I haven't worked on HaChu for a long time. The problem is that during that time my ideas for how to best organize and update an attack map have evolved quite a lot. When I failed in making HaChu play Tenjiku Shogi in a stable way (while having it registered for the yearly correspondence championship), I created a new dedicated engine (called Inferno) for that, using these new ideas. And they work like a charm: Inferno is able to reach 500-700 knps (single-threaded), which for a game on 16x16 with 78 pieces per player is spectacular. But even that is a long time ago, now. The engine was never released, though.

Rather than resuming development of the old HaChu code, I would be inclined to make a new engine for the variants it plays, and that I intended it to play, based on the Inferno code. In principle shrinking the board to 12x12 (by making part of the internal 16x16 board inaccessible) should already enable it to play Chu Shogi, as the latter is just a subset of Tenjiku. But it would be better to take out all the weirdness that is unique to Tenjiku (burning and flying pieces, ski-sliders), because it would just cause slowdown in all other variants. I would have to devise new ways to efficiently (incrementally) handle hook movers if I wanted to implement the larger Shogi variants, though.

I might still do that one day. But currently I am very busy with other stuff (bought a new home...), and don''t have any time for Chess programming.

[Drunken-Elephant]

Thanks for the reply. Inferno sounds very fast for tenjiku shogi - I'd love to see the source code if you're willing to post it online (GitHub would be great).

I was considering another approach to incremental move generation, by having pieces generate all squares they could move to (ignoring the squares' occupancies) and putting its own position into a set for each target position. E.g. a pawn at (5, 11) would add (5, 11) into the set for (5, 12). That way when (5, 12) changes in any way, it knows that it has to regenerate the pawn's moves. However I don't know if this would be very efficient.

I've done some testing with an online playable version of taikyoku shogi (https://shogitter.com/rule/64) and there's roughly 2400 pseudo-pseudo-legal moves at the start, but only ~280 are valid (i.e. the target square isn't occupied by a friendly piece). Even so, that's mostly due to the range capturing pieces. Since most valid moves that the range capturing pieces have in the initial state of the game would be capturing its own pieces without capturing many/any of the enemy's, I wonder if these moves should even be generated at all, or if they can be instantly pruned.

Congrats on the new home!

[hgm]

What you are describing is basically what an attack map does. At least for the captures. Most nodes in a search tree are Quiescence Search, and only need to search captures. IIRC Inferno indicates the moves that go to a given square by a byte where each bit corresponds to one of the eight principal directions, plus a 'view distance' for each direction, which indicates how far away the nearest obstacle in that direction can be found. And then some extra bits for attacks by individual irregularly moving pieces, such as Knights. If a square gets evacuated, the directions from which a move to it was coming are checked to see if the attacker had additional range in that direction, and if so, whether there is a target within that range in the opposit direction. If so, the attack on the latter is then recorded there. No other moves of the attacking piece have to be (re)generated.

When I was developing Inferno I posted a kind of blog about it here, under the title 'The Inferno Thread' ( viewtopic.php?p=708305 ). It would probably be easier to understand how Inferno works from that than from the actual source code (which is quite cryptic).

[Drunken-Elephant]

Thank you so much for your help! I'll read closely.