Interesting (Chinese) Chess variant

[hgm]

I have question about the weights. Why does the mover's unrevealed count go to the weight formula? If I understand correctly , that would mean that we prefer to capture with a our revealed pieces that have counts of 255. If we take a simple example where the opponent have a hidden Rook and Pawn, and then we made a capture of one of them the probabilities are 0.5 for each, and scores +5 and +1, for an average of 3. With 2 hidden rooks and 1 pawn, the probabilties will be 2/3 and 1/3, which again does not depend on the mover's type.

I thought unreveiled[] was a type for unrevealed[] but I see it is not.

This is just a kludge to not need separate recursion code for the revealed and unrevealed case. In the revealed case (be it for the mover or the victim) the do-while loops are started at the piece itself, wan will never do more than that. This makes the weight immaterial, as weights are only relative: the score is multiplied by w, but nr will also end at w, so after the loops the w will be divided out again.

So it really doesn't matter what the weigth of an outcome is when there is only a single outcome. This would also happen when all remaining unrevealed pieces are of the same type (e.g. 3 Pawns). As long as the weight is not 0, then w*score/w will just be score. The reason I wanted to set it to 255 was that it would be decremented before recursing, and you want it to stay safely away from 0.

This might be a stupid idea: for efficiency the division score/nr would probably have to be done through a lookup table for 1/nr, so it would be important to keep the range that nr can attain small. With all pieces unrevealed, nr could potentially sum to 15x15=225 (unrevealed pseudo-Cannon captures unrevealed pseudo-Horse as first move). A table of 226 inverses is afordable. But when revealed x revealed would lead to w=255^2, that would be nasty. So it would probably better to in the initial if(pieceType & UNREVEALED) test put an else-clause that would set unrevealed[pieceType] = 2;

[Daniel Shawul]

You write such a criptic code it is hard to understand If we capture with our unrevealed piece (out of 3) opponent's unreveied piece (out of 4), indeed we need to multiply both counts because now we have 12 options. Considering 3 options for revealing our pieces can be an over kill, because the terminal scores probably don't differ by much. The 4 options for capturing opponent's piece are deserving because it affects the terminal evaluations by the type of captured piece. It is a bit of a shock for the opponent to loose a high valued piece via an unrevealed capture, but not so much for the mover to unreveal a high valued piece. I would just add 1/3rd of the positional score from our alternatives to reveal our pieces and be done with it, instead of investing alternative search calls (saves 8 for my example).

This might be a stupid idea: for efficiency the division score/nr would probably have to be done through a lookup table for 1/nr, so it would be important to keep the range that nr can attain small. With all pieces unrevealed, nr could potentially sum to 15x15=225 (unrevealed pseudo-Cannon captures unrevealed pseudo-Horse as first move). A table of 226 inverses is afordable. But when revealed x revealed would lead to w=255^2, that would be nasty. So it would probably better to in the initial if(pieceType & UNREVEALED) test put an else-clause that would set unrevealed[pieceType] = 2;

If we use my above suggestion it can reduce the table to 255. But it will be very approximate as we have to pick just one of our unrevealed piece to do search with instead of considering all alternatives. The fact that one can reveal hidden pieces at any ply may increase the size of search tree significantly. It seems that what matters the most is whether I want to reveal my pieces or not. For example when an attack zooms in, we may want to reveal our pieces that were targeted to save sudden losses of high valued pieces.

[Greg Strong]

I am thinking about converting my Xiangqi engine MaxQi to play it, using WinBoard as an interface.

Wow. You, sir, are very ambitious I have a few projects going and am having a hard time getting to completion on them without trying anything so radical. But more power to you! It would be very interesting to see this pulled off...

Thinking about the GUI, I see a couple of ways to go. The obvious way is that the GUI knows what all the unrevealed pieces are at the start. But another way to go would be for the GUI to randomly decide (based on appropriate probabilities) only when the piece is revealed. The first is certainly easier and cleaner, and may well be superior. I would just consider the saving of games and the export of FENs (extended in whatever way is appropriate for this game.) It might be advantageous if the FEN didn't express what the pieces are for a couple of reasons which are probably obvious. The only difficulty being that the FEN would then have to encode what has been captured so you could determine appropriate probability, so we'd be deviating from a normal Chess FEN quite a bit ...

[hgm]

I was thinking about using a Superchess-like FEN, where the captured pieces are written as holdings. (And also displaying holdings next to the board.) Unrevealed pieces could be indicated by a new piece-ID letter (say O).

I think I would go for a system where the GUI decides what is revealed at reveal time. Then you don't have to worry when loading a game that doesn't specify the hidden pieces in the initial FEN. In SAN the obvious way to indicate own-piece reveals would be as promotion suffix. Unfortunately it is possible to capture unrevealed with unrevealed, in the initial position, so there would have to be a notation for a double-reveal.

[JoshPettus]

How do the players know which side the piece is playing for when it's unrelieved as in my set there is no Red or Black on the flip-side and is just blank. In Xiangqi, like Shogi, the pieces have a tendency to really get mixed up. Also, is the color part of the randomness when it's revealed? (Aha, it's my piece after all!)

I'd be happy to make a blank SVG Xiangqi tile for you. Should be easy, All I have to do is remove the marking objects on an existing one. Should I leave the color ring on the outside of the tile or just make it completely blank?

[zamar]

For me it sounds like that some kind of Monte Carlo simulation technique is needed here... Something similar that is used in Go-engines nowadays?

[hgm]

How do the players know which side the piece is playing for when it's unrelieved as in my set there is no Red or Black on the flip-side and is just blank. In Xiangqi, like Shogi, the pieces have a tendency to really get mixed up. Also, is the color part of the randomness when it's revealed? (Aha, it's my piece after all!)

The way I understood the rules the color is not part of the randomness. So when setting up a game with woodware I suppose you first separate the two colors, and put them onto different heaps before you flip them backside-up. Then each player srandomly selects from its own heap to set up the pieces on his own board half.

I'd be happy to make a blank SVG Xiangqi tile for you. Should be easy, All I have to do is remove the marking objects on an existing one. Should I leave the color ring on the outside of the tile or just make it completely blank?

Yes, that would be nice, thank you! The XIANGQI font I used in WinBoard to render the oriental-style Xiangqi pieces already happened to have a 'blank' piece (encoded by B/b).

[JoshPettus]

Ok here you are, I put up both so you can pick which you prefer.

https://www.dropbox.com/s/nrh9dk33789cd ... iBlank.svg

https://www.dropbox.com/s/mg4pwk9s280rd ... Blank2.svg