![]() There was a field of about 30 players (I believe this was billed as a sort of city championship), the majority of the native players ranged from U1000 to around 1700, I finished second behind an expert from Germany. the unrevealed piece at b2, allowed to move as a Cannon, captured the unrevealed piece at b9, revealing itself, and indirectly revealing b9.I once played a tournament in Tokyo (I was there for other reasons), it was an interesting expierence to say the least. It could be that two pieces are revealed in the same move! You could start with moving a C'b2xb9, i.e. If revealing always goes accompanied with a move, this complicates notation. Of course for playing with traditional oriental pieces, one would have to think of some other distinguishing feature. XBoard already supports such piece symbols for Crazyhouse, where it is necessary to distinguish primordial pieces from promoted Pawns, because the latter revert to Pawns on capture. The best way to handle that in the GUI seems like this: just represent a piece that starts in a Rook position by a Rook-like symbol, to remind the players that it currently moves like a Rook, but will morph into another piece after its move. OK, so it is really like there are 6 different new piece types, which after their move would sort of randomly change into an orthodox Xiangqi piece type. The GUI would then only have to decide on reveals for moves entered by the user, and communicate these to the engine with the move. As long as there is only a single engine, however, this would not be a problem. when capturing an unrevealed piece, they could always say it is a Rook if both Rooks weren't revealed yet). if revealing a3 would produce a Cannon.) This does heavily rely on the honesty of the engine, though, and would open the door to cheater engines, who do not decide randomly, but bias the outcome of a reveal to what suits them best (e.g. (Direct reveals could be notated as drop moves, e.g. I guess one could get around this by letting the engine decide randomly which piece was revealed or captured, so it could be handled as a 'promotion choice'. This does require a feedback to the engine not present in other Chess variants, however: the engine can only say which piece it wants to reveal, but it must then be informed by the GUI what piece this actually became. Moving an unrevealed piece should make the GUI decide randomly what to replace it by (removing that piece from the 'hand'). ![]() The not-yet-revealed pieces could be displayed next to the board, like in Crazyhouse. I guess there should be introduced an 8th 'piece type', to represent unrevealed pieces. What if they are revealed outside the Palace? Are they now not allowed to enter it? Or when they could enter it, would they be allowed to leave again?Īnother matter of course would be how to display this game. Normally Advisers are not allowed to leave the Palace. One rule detail still needs to be cleared up, however. I also have written a minimalsitic Xiangqi engine MaxQi, though, for which this would not be a problem. Advisers outside the Palace!) My engine HaQiKi D could not handle that at all. Btw, do both players get to see what was captured in that case?Ī practical problem seems that Elephants and Advisers now can be revealed in places where they normally could not venture (e.g. ![]() I guess you should do the same when capturing an unrevealed piece. That means you have to average the score of all possible outcomes of a reveal, rather than take the highest score. The only difference is that you would not be able to choose what you get, like you would be able to choose where you move a chosen revealed piece. Each 'move' with an unrevealed piece expands to appearance of each of the yet unrevealed piece types (at most 6), which is on average not really more than the number of moves a revealed piece has. This should be comparitively easy to implement in an engine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |