SjaakII 1.0 RC1

[hgm]

This is the version without drops, I presume?

And yes, when Sjaak II will see its stable 1.0 version we definitely should advertize it to the Shogi world. I will probably add a Windows binary to the Shogi-Variants package I am distributing, based on WinBoard Alien Edition, which now only contains HaChu and Shokidoki. Neither of those is suitable for doing Wa with drops, however. So Sjaak could be there to provide Wa (and Goro Goro).

It should be possible to make HaChu do Wa without drops, btw.

I currently put links to that Windows package from the Wikipedia pages on Chu and Tori, and on the Japanese Wikipedia Chu page.

Perhaps I should just expand that page with an XBoard section, providing downloads for the various kanji themes you designed.

Perhaps Sjaak II should also go in the XBoard-for-Shogi OSX App.

[Evert]

It would have much more impact if Sjaak could handle the Chu Shogi Lion. If I understood Evert correctly, it already generates moves for lame leapers as two-step moves (e.g. for XQ Horse first Wazir, then Ferz) followed by masking out the valid overall leaps (in this case Knight moves). Only when the first step goes to an empty square the continuation is made.

Lion moves could work the same. A Lion is a special case of a 'locust', (a Checker is another), which in general is a piece that captures 'in passing'. Locusts and lame leapers are in fact very similar: where a lame leaper can only move if a given intermediate square is empty, a locust can only move when such a square contains an opponent. So the procedure for generating moves could be the same, just using a different mask after the first step. The only real difference is that the intermediate square now should be mentioned in the generated moves as a square that should be cleaned out, in addition to from- and to-square. But I understood Sjaak's move encoding already allows that.

Indeed. In case of a double-capture, this would translate to two pickups (the victims) and one swap (the lion), which would take 2x13+14=40 bits, which fits comfortably in the 48 bits I have for move encoding (if I used 8 bit squares instead of 7 it would be 44 bits, which would still fit).

In the particular case of the Lion you would have something like ((Kmask & opponent) x Kmask) & '5x5mask'. In addition it would of course have ordinary leaper moves (KNAD).

Generating non-capture moves is easy (it can do that now), the non-captures won't quite work now (the first leg would be required to be a non-capture) but that shouldn't be too difficult to change (but I may need to tweak the encoding of how pieces move to do it cleanly).

The real difficulty with the Lion are the truckload of special rules it comes with. From Wikipedia's entry on Chu:

A lion can always capture an adjacent lion (on a "!" square).

Fine.

It can always capture a non-adjacent lion (on a "☆" square) if, supposing it had done so without capturing anything else, remains safe for at least one turn.

This requires some sort of special treatment to detect that the other piece is a lion (presumably it would have some sort of "is_lion" property), it then requires some sort of check for being "adjacent" and it needs a test to see if the capture was safe.

If capturing a non-adjacent lion with nothing else leaves it vulnerable next turn, it may only capture the other lion if it first captures another piece so that it is then adjacent (double capture), and then only if the other piece is something other than a pawn or go-between (which can be a reason to defer promotion of a pawn).

This is a bit confusing. It seems to say that if I do a double-capture, I can always capture the other lion, regardless of whether the capture is safe, unless the other piece I captured is of a particular type. Presumably this would be another piece property (say, "capturing_does_not_make_lion_safe").

Finally, if one player captures a lion with a non-lion, the opponent cannot then capture a lion on the next move with anything but another lion (as a player may have such a second lion by promoting a kirin), and this may only be done if the rules listed above are met.

This means that the move options depend on the last move, but this is not too different from what is done during in-check anyway.

So putting all that together, what would be needed is something like the following:

• The ability to generate double-captures from the move generator.
• A piece property "is_lion", that identifies a piece as a lion.
• A piece property "capturing_does_not_make_lion_safe".
• A board state that says "non-lions may not capture lions", which is set after a lion is captured by a non-lion, and cleared after each move.
• A test to see whether capture of a lion by a lion is allowed, which it is if the lions are "adjacent", if the capture is SEE safe, or if I also captured another piece that does not have "capturing_does_not_make_lion_safe".

Ok, so that almost reads like an implementation suggestion. My gut-reaction would be to split the last three lion properties into three distinct properties that can be mixed and matched to create other interesting pieces, but for a first draft, "is_lion" could already cover it.

The question is, did I miss anything?

[hgm]

The real difficulty with the Lion are the truckload of special rules it comes with. From Wikipedia's entry on Chu:

...

So putting all that together, what would be needed is something like the following:

• The ability to generate double-captures from the move generator.
• A piece property "is_lion", that identifies a piece as a lion.
• A piece property "capturing_does_not_make_lion_safe".
• A board state that says "non-lions may not capture lions", which is set after a lion is captured by a non-lion, and cleared after each move.
• A test to see whether capture of a lion by a lion is allowed, which it is if the lions are "adjacent", if the capture is SEE safe, or if I also captured another piece that does not have "capturing_does_not_make_lion_safe".

Ok, so that almost reads like an implementation suggestion. My gut-reaction would be to split the last three lion properties into three distinct properties that can be mixed and matched to create other interesting pieces, but for a first draft, "is_lion" could already cover it.

The question is, did I miss anything?

Well, the Lion-capture rules IMO should be really seen as independent from the Lion. They are just clever rules preventing a key piece that makes a variant interesting would be traded away. They could basically be applied to any piece. E.g. Amazon Chess, with Amazons replacing Queens in a FIDE setup, is a pretty boring variant, because the Amazons make the only difference, and are so powerful that they meet each other quickly and get traded. After which you converted to a boring end-game of orthodox Chess.

So it would be good if there were rules that forbid the trading. Like an A that captures A is absolutely royal for the next turn (meaning you lose the game if a pseudo-legal move captures it), preventing direct trades. And after non-A x A the opponent A would be iron for one turn preventing indirect trades.

In the case of a Lion it is just a bit more complex, because it can capture in passing. So if you stand next to it, you are basically annihilated rather than traded, even when protected. So the exception is mostly moot. They obviously chose for rules with least impact on the game. The 'capture bridge' of a valuable piece between the Lions was also you would already naturally avoid, because you would lose a piece in the process. So also there, it wasn't a problem, and therefore they did not make a rule against it.

This being said about the anti-trading rule, it is good to note that there are many Shogi variants (Dai and up) that do not have this rule at all, but do have a Lion. It would only make sense to implement exactly this rule when you want to do Chu. Which has too big a board for Sjaak anyway.

In Mighty-Lion Chess I also simplified the Lion-capture rules (I think).

In Maka Dai Dai Shogi the two strongest pieces are protected from disappearing by an entirely different rule (and the Lion isn't protected at all): the piece that captures A becomes an A. Also a nice rule. When you capture A x protected-A now, he recaptures, gets his A back, while you lost yours. And when he attacks my A, and I counter attack his A, we both capture, we still each have our A!

I think such rules could be generally useful for designing new variants, and thus might be an asset to Sjaak.

[myfish]

This is the version without drops, I presume?

And yes, when Sjaak II will see its stable 1.0 version we definitely should advertize it to the Shogi world.

Perhaps I should just expand that page with an XBoard section, providing downloads for the various kanji themes you designed.

Perhaps Sjaak II should also go in the XBoard-for-Shogi OSX App.

For now, yes. No drops. However... I won't be happy until I get at least some workaround regards the holdings in xboard to allow drops. That will be next for Wa.

Sjaakii and xboard combined are proving to be fruitful for shogi and related variants.

I have no problem providing pieces for whatever variants we define, nor any problem sharing them to a wider, yet small audience.

I've almost finished all the promo pieces and will then re-size a few to match the variant proper and as usual, provide a zip of the wa theme folder.

[hgm]

• The ability to generate double-captures from the move generator.
• A piece property "is_lion", that identifies a piece as a lion.
• A piece property "capturing_does_not_make_lion_safe".
• A board state that says "non-lions may not capture lions", which is set after a lion is captured by a non-lion, and cleared after each move.
• A test to see whether capture of a lion by a lion is allowed, which it is if the lions are "adjacent", if the capture is SEE safe, or if I also captured another piece that does not have "capturing_does_not_make_lion_safe".

I have been thinking what would be the logical generalization of these rules, for which it is important how they originated in the first place. In particular the 'capture bridge' seems puzzling. Putting a piece between two Lions is not a logical thing to do, as in general everything standing next to an enemy Lion is toast. You give away the piece through igui, so who cares if Lion trading would be possible in the process?

But I could think of a realistic scenario where this rule plays a role. Say the black Lion is on a plunder raid, and steps next to (on d4, say) a white Rook (e3) and Bishop (d3). Normally white would now lose one of those to igui, because he can withdraw only one, and protecting is useless against rifle captures. But the black Lion is unprotected (which is usual during plunder raids).

[d]8/8/8/8/3n4/3BR3/6N1/3PPPK1 w
Knights represent Lion, Pawns generals

Now without the capture-bridge rule, white could have protected both R and B by putting your Lion next to both of them, on d2 or e2 (protected by some General on the backrank). Black now cannot igui either of them, because after the capture it could never withdraw out of reach of the white Lion, and having penetrated in your camp it probably cannot find a protected square next to R or B. So he has to withdraw without capture. But in absence of the ban on Ln x Ln he could have played Ln x R x Ln, G x Ln, and gained the Rook anyway. So it seems the Ln x Ln ban has given the defender an unintended advantage. This has led to amendment of the rule, now explicitly allowing the double-capture. That Pawns and Go Betweens have been exempted again from that is a refinement; these pieces are so insignificant in Chu that the right to gain them or protect them hardly carries any weight. And they are pretty abundant, so that the right to gain them as a capture bridge would lead to an undesirably large amount of Lion trading.

So it seems that in general an anti-trading rule for a piece with multiple moves per turn, it should only apply to the non-final leg. And if these non-final legs capture substantial additional material, it should not prevent trading on the final leg. The property 'does not make endangered species safe' is basically implied by the value and copy number of the pieces: Pawns should not be able to act as capture bridge, because they are so abundant (which already sort of implies their insignificance), and pieces of equal value (say upto 40% more valuable) should be treated the same. If you don't want to leave this to a heuristic, you could make an explcitly definable piece property 'insignificant'.

The property 'endangered species' outlawing A x protected-A (i.e. A x A before any x A) could be an independent property from 'retaliation immunity', outlawing any x A after any x A. (A good question is how to handle the case when several piece types, say A and B, are declared 'endangered': should the restricions only apply to AxA and BxB, or also to AxB and BxA? This could heuristically depend on value difference.) And there could be a related piece property 'contagious', meaning that whoever captures the piece, will become that type.

[Evert]

The real difficulty with the Lion are the truckload of special rules it comes with. From Wikipedia's entry on Chu:

...

So putting all that together, what would be needed is something like the following:

• The ability to generate double-captures from the move generator.
• A piece property "is_lion", that identifies a piece as a lion.
• A piece property "capturing_does_not_make_lion_safe".
• A board state that says "non-lions may not capture lions", which is set after a lion is captured by a non-lion, and cleared after each move.
• A test to see whether capture of a lion by a lion is allowed, which it is if the lions are "adjacent", if the capture is SEE safe, or if I also captured another piece that does not have "capturing_does_not_make_lion_safe".

Ok, so that almost reads like an implementation suggestion. My gut-reaction would be to split the last three lion properties into three distinct properties that can be mixed and matched to create other interesting pieces, but for a first draft, "is_lion" could already cover it.

The question is, did I miss anything?

Well, the Lion-capture rules IMO should be really seen as independent from the Lion.

Of course. I just called the property "is_lion" because I couldn't think of something else.

Perhaps a better list of properties would be:

• "no_retaliate": if your opponent captured a piece with this property, you may not capture an opponent piece with this property this turn, except if a piece has an "avenger" property (capturing a piece with this property sets the "non-lions may not capture lions" board state I mentioned above).
• "avenger": this piece is allowed to retaliate against a capture of a "no_retaliate" piece.
• "assassin": a piece with this property may only capture another piece with this property if a) they are "adjacent", or b) the capture is SEE-safe, or (optionally/later) c) if another piece was captured as well.

A "lion" then has the "no_retaliate", "avenger" and "assassin". I guess I would call a piece property that allows an assassin to capture another assassin a "backstab" (so this works in reverse to the property I gave earlier: instead of denying the lion x lion capture, pieces enable it).

I haven't checked if these properties have pre-defined meanings already, which I should do before implementing any of them. That'll be for post 1.0 though.

They are just clever rules preventing a key piece that makes a variant interesting would be traded away. They could basically be applied to any piece. E.g. Amazon Chess, with Amazons replacing Queens in a FIDE setup, is a pretty boring variant, because the Amazons make the only difference, and are so powerful that they meet each other quickly and get traded. After which you converted to a boring end-game of orthodox Chess.

Yes, Amazon Chess games seem to end up in one of two ways: either your king gets stormed early and checkmated, or the Amazons get traded quickly. The Amazon is just too powerful on an 8x8 board.
Chancellor Chess is better in this sense, as is Shatar (the Bers is basically a Crowned Rook).

So it would be good if there were rules that forbid the trading. Like an A that captures A is absolutely royal for the next turn (meaning you lose the game if a pseudo-legal move captures it), preventing direct trades. And after non-A x A the opponent A would be iron for one turn preventing indirect trades.

That could be implemented with the above piece rules, I think. And I agree, it would probably make the game more interesting.

In the case of a Lion it is just a bit more complex, because it can capture in passing. So if you stand next to it, you are basically annihilated rather than traded, even when protected. So the exception is mostly moot. They obviously chose for rules with least impact on the game. The 'capture bridge' of a valuable piece between the Lions was also you would already naturally avoid, because you would lose a piece in the process. So also there, it wasn't a problem, and therefore they did not make a rule against it.

Well, it's a good idea to separate the Lion's move from its other properties anyway (which would be a prerequisite anyway, give how Sjaak's move generator works).

This being said about the anti-trading rule, it is good to note that there are many Shogi variants (Dai and up) that do not have this rule at all, but do have a Lion. It would only make sense to implement exactly this rule when you want to do Chu. Which has too big a board for Sjaak anyway.

Well, Dai has an even larger board dan Chu, from what I can tell, so I don't think that helps.
Counting bits, it looks like I would actually be able to fit 8 bits per square into the move encoding, which would open up the possibility of 16x16 boards. The limitation is really that I need to be able to encode a Seirawan castle+gate move in 48 bits. Castling is two swaps (2x2 squares), a gate is a drop (a square, a piece, and a colour bit) so that would come to 5x8+5+1 = 46 bits < 48 bits, which would be ok.

I currently store pickups the same way as drops, which is inefficient. The reason I did this originally was to have symmetry between make/unmake, but I've been meaning to get rid of it eventually. Most of the code only uses the pickup square already, I think MVV/LVA ordering is the only piece of code that still uses the victim from the move format.
A lion double capture is a swap (2 squares) and two pickups (2x(square+piece+colour)), which would come down to 2x8+2x(8+5+1)=44 bits < 48.
However, there is one situation where Sjaak wouldn't be able to handle a lion move: if the lion would promote as well as capture two pieces, then the move encoding would require three pickups and one drop, which takes up 4x(8+5+1)=56 bits>46 bits (even with 7 bits for a square it doesn't fit). As I said though, I want to make pickup encoding more efficient, and then this would reduce to 38 bits, which would fit easily.

So it seems it actually wouldn't be impossible (or that hard) to extend Sjaak to play Chu in the future, but the change is larger than what I should be considering between 1.0RCx and 1.0 proper. I'm sitting on a patch to allow a cylindrical board topology for the same reason.

I'll set it as a worthy goal for version 2.0.

In Mighty-Lion Chess I also simplified the Lion-capture rules (I think).

I'll take a look.

In Maka Dai Dai Shogi the two strongest pieces are protected from disappearing by an entirely different rule (and the Lion isn't protected at all): the piece that captures A becomes an A. Also a nice rule. When you capture A x protected-A now, he recaptures, gets his A back, while you lost yours. And when he attacks my A, and I counter attack his A, we both capture, we still each have our A!

This is actually a really neat property, and it would be fairly easy to implement too. I would be tempted to call it "transference" or "infectious".

I think such rules could be generally useful for designing new variants, and thus might be an asset to Sjaak.

For sure.
The more the merrier, in general, but it's a juggling act between finding a sufficiently general and a reasonably efficient implementation (basically, rules that don't apply in a variant shouldn't hurt it). C++ templates help a bit here, but I'm not using them as much as I possibly could.

[Evert]

So it seems that in general an anti-trading rule for a piece with multiple moves per turn, it should only apply to the non-final leg. And if these non-final legs capture substantial additional material, it should not prevent trading on the final leg.

Ah, yes, that's another technical issue: Sjaak wouldn't see the Lion move as a multi-leg move, but as a leaper move with a side-effect (an extra piece is captured).
This mainly affects the interaction with the GUI though: such side-effect moves need to be caught and encoded as "{from}{victim},{victim}{to}" and sent to the GUI as "move {from}{victim},\nmove{victim}{to}". There are some technicalities with respect to the highlight command as well.

The property 'does not make endangered species safe' is basically implied by the value and copy number of the pieces: Pawns should not be able to act as capture bridge, because they are so abundant (which already sort of implies their insignificance), and pieces of equal value (say upto 40% more valuable) should be treated the same. If you don't want to leave this to a heuristic, you could make an explcitly definable piece property 'insignificant'.

I would definitely not want to rely on the piece value (I dislike having it as an input at all, but there is really no viable alternative; Sjaak has a fall-back heuristic if you don't specify piece values at all which is better than not having piece values, but it doesn't do particularly well with pieces that are not orthochess pieces).

The property 'endangered species' outlawing A x protected-A (i.e. A x A before any x A) could be an independent property from 'retaliation immunity', outlawing any x A after any x A.

Yes, I think so.

(A good question is how to handle the case when several piece types, say A and B, are declared 'endangered': should the restricions only apply to AxA and BxB, or also to AxB and BxA? This could heuristically depend on value difference.)

The way I would implement it, it would definitely end up as a single property, so it would treat A and B as the same. Perhaps two properties are needed here: one that treats A and B as different (because they are different piece types) and one that treats A and B the same (simply because they have the same property).

The latter is similar to how the "royal" property works: all royal pieces are treated the same.

And there could be a related piece property 'contagious', meaning that whoever captures the piece, will become that type.

Yes, that would be a useful one as well.

[Evert]

A minor update to SjaakII 1.0 RC7 is up at http://www.eglebbk.dds.nl/program/chess-download.html.
Benchmark signature 4834799.

This fixes the following issues:

• Changes in castle rights were not reflected in the hash key. This is now fixed.
• Cosmetic changes to the FEN strings produced by SjaakII (include or not castle and en-passant fields depending on whether these apply to the game in question, correct move counter).
• Fix another issue with promotions in Sittuyin. They are still treated as optional at all times though.
• Descriptive error messages if a config file defines too many pieces of a particular type.
• Much better re-use of previously defined moves, if different piece types share the same move (which is common in Shogi-like variants).
• Fix promotions in Makruk and Ai-Wok: Sjaak treated these as optional because the pawn can still advance after reaching the sixth rank. This is incorrect.

[hgm]

There could be separate properties 'endangered' and 'no_cannibalism', which are basically the same, except that 'endangered' would treat all piece types with that property as the same, while 'no_cannibalism' would only activate the rule if the the piece types were identical. The corresponding indirect bans could be 'no_retaliation' and 'no_genocide', respecyively.

I guess for simplicity the rules could be taken to always allow side-effect capture of endangered or non-cannibalistic pieces, and always allow normal capture if a non-insignificant piece was captured as a side effect. That would allow full implementation of the Chu Lion-capture rules.

Btw, the variant where I simplified the Lion capture rules was not Mighty Lion Chess, but Elven Chess / Elven Shogi. There I did away with the bridge capture. This is potentially a variant (10x10) Sjaak II could play with its current board limitation.

To give some extra freedom you could make the bridge-capture exception on the 'endagered' rule, but not on the 'no-canibalism' rule. (Or the other way around.)

[Evert]

Unrelated question:

I thought it would be fun to implement Okisaki Shogi (http://en.wikipedia.org/wiki/Okisaki_shogi), but I run into the issue that it has both the Lance and the Queen, which share the same position in the pieceToChar table. Is there a work-around for that?