[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Check out Janggi (Korean Chess), our featured variant for December, 2024.
Check out Janggi (Korean Chess), our featured variant for December, 2024.
OK, the marker images were just a flat color, which was a bad idea. I have now given them all a black outline, and have tried to make the inner colors brighter by mixing in some white for the darker colors red and blue. This should now be recognizable against any background.
As to the betza2 moves: the problem is that this piece is defined as a Grasshopper. So it has no moves on an empty board! Which is what the diagram shows, moves of the piece on an empty board. This is very nice for ordinary leapers and sliders, because you see their complete move potential, without anything being blocked. But for hoppers, which acquire moves only because of obstacles, it is not very satisfactory. That also holds for locust capture, which is not possible without a victim being present, but there (like with ordinary captures) the ShowMoves routine at least shows the location where a victim would have to be. But you still cannot see where the piece would end up if it makes such a locust capture.
I don't have any good ideas for how to solve these problems. For sliding hoppers, rather than making the board empty, the ShowMoves function could dump some platforms in their path. But then you would never know if the hopper could have moved beyond those if they had been absent. You can of course hope that if the platform is located far enough from the piece, the suggestion that it is an infinite-range sliding hop is correct. But in the case of a Dababba that mandatorily jumps (jD), you would have to place an obstacle next to it to enable the move, and you would not be able to see or even suggest that there could also be a on-capture to that adjacent square. For locust capture, a piece could have multiple possible targets (a Checker has two), and statically indicating where the piece ends up after such a capture would not reveal which final destination belongs to which capture target. (Think of the Chu-Shogi Lion, or Ultima pieces.)
How about the following?: When displaying the move diagram of a piece on an empty board, the mouse cursor becomes a 'virtual opponent piece'. If the user hovers it over the board, the diagram would be recalculated as if there was an enemy piece on the square he is hovering over. In particular, if he hovers over a square marked as locust victim, it will show where the piece can land after taking that victim. And if the square is in the path of a hopper, it will show the moves of the hopper with a platform there. (Where capture-only destinations are indicated in red even though the board is currently empty, as it now does for divergent normal pieces.)
When pieces get too complex, i.e. their moves depend on too many conditions in other squares, it is just ot possible to illustrate it in a static diagram. This is the whole idea of providing a diagram where people can move around pieces, rather than just responding to clicking on a piece name. They can then set up situations they wonder about, e.g. for the locust capture, to see what happens if they make it. But it is true that the move diagrams makes the user aware of locust captures, while potential hops remain completely 'silent'. Perhaps there should be a marker symbol (like an inverted white triangle) in the move diagrams to indicate squares where the piece could hop over something. The Grasshopper then would show up as a Queen. Not sure how I should do it for the Pao, which has both real non-captures and potential hops for capturing on the same squares...
That seems to do the trick! Thanks! This is really starting to look good now.