SjaakII 1.0 RC1

[myfish]

Not sure where our hard working developers have gone but, here is a question.

I have mentioned this before but, it's bugging me so I'll try another angle.

Shogi is a pain to give value to pieces, we are agreed on this I think as it's so dynamic.
So, is there a way...

I would assume sjaakii and hgm's engines/xboard knows the difference between black, and white.

So, let me be white (xboard white).

Habu says, amongst others that a tokin is worth 2 golds. (To ME) yet, it's worth a pawn to black if taken. There are effectively, 5 golds in 9x9 shogi.

In order of value, they decrease to the loser of a piece. If I lose a tokin, it's a pawn to black. If I lose a narigin, it's silver to black.

What I'm asking is, can we floating values depending on ...

What a piece is
What a piece becomes
What a piece is likely to become.

Lets say I drop a pawn 1 rank from promotion, or, in the promotion zone, it is LIKELY to promote so, is a greater threat to black and, about to be worth 2 generals for white.

Assuming we have a pawn of 80 and a gold value of 500, and, the best professional players are suggesting, a tokin is worth 2 generals, the tokin should be worth 1000 right ?

Well, I've kind of tried this and it really does alter game play. It's not correct, but it certainly steers the game.

Lets suggest we make it worth 750, so 50% more than the gold, a jump from 80, to 750 isn't a nice progression in value.

Can't pawns increase in value, incrementally as they head toward the promotion zone.

Just all stuff rattling around in my head that to me, shouldn't be impossible. As sjaakii already has zones, couldn't we define value by zone, position, threat etc.

Fixed values aren't working. Yes, you get a game, often a really challenging game but the machine is working in 'reaction to promotion and threat' not the premise of such.

First of all, you have to distinguish static material evaluation (what pieces are worth) from dynamical positional evaluation (how this depends on where they are on the board).

Nominally, SjaakII uses "centi-pawn" units for its evaluation, so a pawn has a base value of 100 points. It already cheats on this by making a pawn worth 100 points in the end game, and less than that in the opening. Added on to this material value are various positional terms: centralisation, proximity to promotion zones, mobility, threat against the enemy king, etc.

The question is: what is the relative weight for these different terms? The answer to this term is different for Chess and Shogi (in general: variants with piece drops), which is where the notion that there's no such thing as piece value in Shogi comes from: the dynamical terms are much more important, relative to the material terms, than they are in chess.

This is why I scaled back the material values in Shogi a while ago: by making the material values smaller, the positional terms become more important. For instance, SjaakII's normal value for an unpromoted pawn in Shogi is only 24 (rather than 80).

So this is something you can play with. If you set the material values lower, positional terms become more important.

SjaakII has a heuristic function to estimate piece values that was calibrated to reproduce approximately its values for Chess and Shogi (which I put in by hand). It takes into account how pieces move and what they promote to to determine the value. To get an idea of what it thinks are reasonable piece values, leave all piece values blank, load the variant and give the command "pieceinfo". The value is part of the output.

Beware that this type of heuristic is notoriously unreliable: there is no mathematical formula that can derive the piece values accurately from just the moves of that particular piece (certainly not for sliders, leapers are a bit easier apparently). You can take it as a first guess and iterate from there; it should not be hard to improve on it.

I can post details of how it estimates piece values later.

Thanks Evert. All being taken on board.

[myfish]

btw:

Are these better ?

Filled in eyes and outlined.

[hgm]

So, I copy the variants.txt, rename the values in one and launch the first sjaakii with the modified variants file. Will it do that ?

Like xboard -fcp sjaakii -scp sjaakii /path/to/modvariants.txt ?

I'll go look at this nickname thing. Thanks.

You should not forget quotes around the -scp argument, or XBoard would not realize modvariants.txt is an option for Sjaak and not for itself. So

xboard -fcp sjaakii -scp "sjaakii /path/to/modvariants.txt"

But I think Shogi is a standard variant for Sjaak, not defined in the variants.txt. So you cannot modify its parameters there. Instead you should define your own Shogi version, and I am not sure if Sjaak would allow you to do that under the name 'shogi', and whether if you did this would take precedence over the built-in Shogi. (Evert could tell us.) To be safe you would have to define your own version of Shogi under another name, in two differently modified variants.txt files.

[hgm]

btw:

Are these better ?

They look great, but I really would have to use them in XBoard to see how well they fit in with the other pieces.

[myfish]

these 2 are at

http://www.myfishcasting.com/shogi/images/dragon.zip

[Evert]

But I think Shogi is a standard variant for Sjaak, not defined in the variants.txt. So you cannot modify its parameters there. Instead you should define your own Shogi version, and I am not sure if Sjaak would allow you to do that under the name 'shogi', and whether if you did this would take precedence over the built-in Shogi. (Evert could tell us.)

It won't, because it matches against build-in variants first. It might be a good idea to change that to explicitly allow for an experiment like this.
At one point I wanted to define all variants in the variants.txt file, but it turned out to be slightly easier to define a bunch of them quickly within he source. The benchmark and movegenerator tests also depend on a number of variants being defined (Shogi is one of these, along with regular chess, Xiangqi, Makruk and Spartan Chess).

However, what will work is to define the variant as "myshogi" and then set "shogi=myshogi" as an alias in the engine options for one of them (this'll be saved to the options file, so be careful when you restart).

To be safe you would have to define your own version of Shogi under another name, in two differently modified variants.txt files.

This is probably the most straightforward way to do this.

[Evert]

Nominally, SjaakII uses "centi-pawn" units for its evaluation, so a pawn has a base value of 100 points. It already cheats on this by making a pawn worth 100 points in the end game, and less than that in the opening. Added on to this material value are various positional terms: centralisation, proximity to promotion zones, mobility, threat against the enemy king, etc.

It just occurred to me that a side-effect of not considering game phase in Shogi is that SjaakII will not push its pawns very aggressively. There may be something to improve there.

[hgm]

I am not sure pushing Pawns very aggressively is good strategy in Shogi. Pushing them should have a positive score, however, otherwise it starts po play very indecisively.

Something completely different:

Can Sjaak be configured to have a piece capture as a Checker? I am designing this new variant 'Werewolf Chess', and the Werewolf would be something like a range-3 Queen that can also jump directly to the second square in any direction. But I am wondering if I also should add the possibility to use the jump to capture the piece it jumps over when the target square is empty. Just to make it a bit more exotic.

[Evert]

I can post details of how it estimates piece values later.

Ok, so here goes. I just want to emphasise again that this is basically a form of numerology that is likely to go wildly wrong for pieces that are very different from "normal" chess pieces and for games that are very different from "normal" chess. The goal is not to derive accurate piece values, but to derive reasonable estimates if the user doesn't supply any.

The basis for the piece value estimate are the movement patterns of a piece at the centre of a 3x3 and 5x5 board. I originally came up with this to quantify how dangerous a piece is in a king-attack: the idea is that a piece that attacks many squares at close range is a bigger threat to the king than a piece that doesn't. The attack rating of a piece is simply the sum of the number of squares it attacks on a 3x3 plus the number of squares it attacks on a 5x5 board, with some more-or-less ad-hoc modifications.

Pieces that are colour-bound get penalised by their 3x3 attack pattern, short range pieces that do not attack more squares on a 5x5 than a 3x3 board also get penalised, as do pieces that have no sideward moves at all.

Capture moves are weighted for 2/3 of the attack rating, normal moves count for 1/3. For pieces that do not have a symmetric move pattern forward moves likewise count for 2/3 versus 1/3 for other moves. I think I took these from various posts by Harm Geert.

To obtain a piece value, the attack rating is scaled so that a rook comes out at 500 points.

For pieces that promote, the piece value is increased by 6% of the piece value of the most valuable piece it can promote to. For a chess pawn, this accounts for about 60% of its value.

For pieces that demote on capture (in Shogi/Bughouse) a further correction is applied. If the piece has the same move as an unpromoted piece (think Tokin versus Gold), then it gets a bonus to its piece value that is larger if the piece it demotes to is less valuable. This makes a Tokin worth more than a Gold. I'm not entirely happy with how this term comes out, quantitatively.

Finally all piece values are scaled back by a factor 3 if the game has drops (which is roughly the factor I found for Shogi).

[Evert]

I am not sure pushing Pawns very aggressively is good strategy in Shogi. Pushing them should have a positive score, however, otherwise it starts po play very indecisively.

I'll have to do the experiment to make sure. As it is, I think the term that makes it push pawns is very small; it relies on advancing the game-phase to really start pushing pawns.

Can Sjaak be configured to have a piece capture as a Checker? I am designing this new variant 'Werewolf Chess', and the Werewolf would be something like a range-3 Queen that can also jump directly to the second square in any direction. But I am wondering if I also should add the possibility to use the jump to capture the piece it jumps over when the target square is empty. Just to make it a bit more exotic.

Sadly, no. I've had locusts on my TODO list for ages, but I haven't been able to come up with a good general way to implement them (at least not one that I liked). Most of the move generator relies on applying bitmasks (leapers) or extracting occupancy bits (sliders, hoppers) for two ray directions, but for locusts I would really need to scan each ray direction explicitly.

Something like a Checker would be relatively simple to do though, since it's just a modified lame leaper that captures enemy pieces instead of being blocked by them. I can probably work that in along with Lion double moves (it'll be post 1.0 though).