Comments/Ratings for a Single Item

Please take a look at my 2 apothecary chess games. I think either I did not understood the way promotion should be implemented either there is a bug in the diagram! They are here:

https://www.chessvariants.com/rules/apothecary-chess-2 

https://www.chessvariants.com/rules/apothecary-chess-1

You do not specify what behavior you see that you did not expect / desire. But I did notice that it doesn't allow you to defer promotion by selecting a Pawn: the Pawn is not highlighted. I think that is because you specified the ID for Pawn as a lower-case 'p', but mention an upper-case 'P' in the promoChoice.

The !P in the promoChoice probabbly doesn't do what you want here, as it will disable the Pawn on the rank of brouhaha squares (which it considers the last rank). There is no notation to disallow a choice on the last two ranks. But it probably doesn't do any harm if the P is available even at the point where it would have no move left. No one would ever choose it.

I'm sorry for that. I meant the behaviour described in the game rules: "Pawns promote to any auxiliary pieces on the players 8th rank, any auxiliary or average peice at the 9th rank, and any piece at rank 10.For the purpose of limiting material when physical play is involved pawns are also restricted to promote to the pieces in reserve. In the reserve enter all the pieces captured of the colour of the promoting pawn and from the begining of the game 1 queen, 1 rook, 1 knight & 1 mameluk."

and

"Pawns may promote to any auxiliary piece on the players 8th rank, any auxiliary piece or average piece at the 9th rank, and any piece at rank 10.For the purpose of limiting material when physical play is involved pawns are also restricted to promote to the pieces in reserve. In the reserve there are initially 1 queen, 1 rook,1 champion and 1 knight and later on enter any of the player's lost pieces."

So mostly the same thing.

But what exactly of that doesn't work?

It promotes to archbishop and griffin respectively, automatically!

That is probably because you have not opened the piece table where you can select the piece from. In that case it just picks a default.

I guess I could have it open the table automatically, rather than picking a default.

[Edit] I have done that now.

You are correct, it works fine if the piece table is open!

I implemented a new feature to the Interactive Diagram: you can now also load games into it. The game record that is displayed in the 'AI bar' (which can be opened by clicking on the 'Play It!' link) below the navigation buttons is now editable. If a game record is pasted there, it becomes the current game, through which you can step using the buttons. This feature is still in the alpha testing phase; the design goal was mainly to make it understand its own game notation. So that people who played a game against the Diagram in an article can post their game as a comment, and others can then copy-paste it in the Diagram to use the latter as a game viewer. (This was an idea suggested by Fergus.)

E.g. in the Capablanca Chess diagram of this article you can now paste the game:

1. e4 e5 2. Nh3 Nc6 3. f3 f6 4. Bc5 d6 5. Ba3 Be7 6. Cg3 Ae6 7. O-O Qf7 8. Ad3 O-O-O 9. b4 g5 10. b5 a5 11. bxa6 bxa6 12. Axa6 Kd7

The Diagram uses Standard Algebraic Notation for the games. Interpreting that is not trivial, so there could still be errors. There should be alert popups when it encounters moves it cannot understand (e.g. because the mentioned piece is not present, or because multiple moves satisfy the notation). Especially moves with implied side effects (such as e.p. capture) are tricky; if no pseudo-legal move matches the notation as given, but there is a single move that matches what is given, but has additional non-mentioned locust capture or promotion, it assumes that move was meant. It should also accept non-pseudo-legal moves that are unambiguously specified (e.g. by fully mentioning the origin square, or by mentioning the moved piece type when only one piece of that type is on the board).

Note that the loading of the game is only triggered by pasting it; if you type moves there, they will be ignored.

Also note that drag & drop moving of the pieces in the Diagram is now fully supported: the dragged piece is animated (a feature that was lost when I switched to using the piece images as background, to make room for foreground marker symbols), and the piece disappears from the origin square while you are dragging it.

What about games where the initial position is varied like chess 960?

This does not work yet. I guess I must make the game record start with a description of the shuffle, and then parse that when you paste a game.

Very nice feature!

I fixed the problem for shuffle games with a quick hack, because I was to lazy to write a FEN generator and FEN parser for prefixing the move list with a FEN for the starting position. What I did instead was save the seed of the pseudo-random number generator that controls the shuffling, and print that in braces before the move list. On pasting this the seed can then be restored, so that we will get the same shuffle.

Testing this revealed that the shuffling itself had a bug, which is now also fixed: When a King with castling capability was shuffled, but the Rooks (or other corner pieces that served as castling partners) were not, the code that should keep the King between the Rooks was erroneously triggered. As a result a KQ shuffling step could lead to disappearence of the King (replacing it with a second Queen), because in the cases where it wanted to swap them it suppressed placement of the King, supposing this would be done later together with the Rooks. (Which it then wasn't.)

In making my own interactive diagrams, I decided to add functions for getting FEN codes from board positions and loading positions from FEN codes. They work pretty flawlessly, provided you use an ID w/ at least one letter for each piece. It even works w/ multi-character IDs, which are enclosed in curly brackets in the FEN code.

I also made functions for getting and loading game moves using a more specialized notation, w/ each element of the move separated by hyphens. Though it isn't standard algebraic notation, I have tested this system and it works very well.

If you would like, I can send you a text document w/ the functions.

Well, for displaying the game I prefer SAN, as it is the commonly used notation by regular Chess players. I would like the game parser to be as universal as possible, though. At the moment it would not understand formats with multiple hyphens; I assumed that intemediate squares only had to be mentioned with locust captures, and would be preceded by an 'x'. Then only the final leg of a multi-leg move could go to an empty square. But this is wrong; e.g. the Valkyrie of Odin's Rune Chess needs to go to the square where it wants to move the displaced piece to first. So I suppose I should first replace all 'x' in the move by hyphens, and then split by hyphens.

The problem is how to distinguish an intermediate square from the square of origin. When there always was an 'x' in front of intermediate squares, that was easy, as there never is an 'x' between the piece ID and a (possibly partial) square of origin. It would be problematic if there could be a hyphen between piece ID and origin. I guess I could check whether the first square, when it is fully mentioned, contains the mentioned piece. If not, it must have been an intermediate.

I have not decided about how to indicate the position. The method of random seed works, but cannot be used if the game was not generated by the diagram itself. FENs become pretty ugly with multi-letter IDs. And they are a bit overkill, as we don't want to indicate arbitrary positions, but just how the pieces are permutated. E.g. for Chess960 it would be enough to print the back rank. And that is small enough to make it a comma-separated list.

So perhaps the following would be a good solution: the Diagram's shuffle parameter contains piece types. During a raster scan of the board (say a1->h1->h8), any square that contains a piece that occurs in that list in the 'nominal' (= pre-shuffle) start position can potentially get another piece, and you the Diagram then print/reads the piece that actually ended up there. If the shuffle was symmetric you only do that for white pieces.

Your program for pasting games works pretty well. To be honest, I didn't expect you to pull that off, though you probably aren't one to give up easily.

The problem with SAN is that it is very vague. It only shows you the piece ID, where that piece moved to, if it captured, a letter and/or number for disambiguation, and promotion choices, if any (and possibly if en passant capture was used). Basically, it shows you the minimum amount of information that required. However, this also makes parsing the moves very complicated (but not impossible). Game Courier has to deal with this same problem at an even larger scale, as some presets use different coordinate systems compared to SAN (i.e. Shogi and its variants). This is why Game Courier uses the notation it does. The notation my functions use an even simpler notation, with each move being a list of coordinates (and sometimes piece IDs) separated by hyphens, a character unlikely to be used in an actual piece ID. This allows the moves to be parsed quite easily using the following process:

• Split move string into components and pass to an array, with a space as the delimiter.
• For each move in the array, split into its components and pass to another array, with a hyphen as the delimiter.
  • Process the move based on the length of the array. Unless stated otherwise, all elements must be coordinates. Piece IDs are uppercase for White and lowercase for Black, and setting the shogiMode flag reverses this.
    • If length 2, single move or drop. First element may be a piece ID or a coordinate.
    • If length 3, single move with promotion or double move. Last element may be a piece ID or a coordinate.
    • If length 4 or more, multiple move with or without promotion. Last element may be a piece ID or a coordinate.
  • If an error occurs, exit loop without moving anything for this move and print an error message (moves successfully parsed before the error are still executed). Otherwise, make the move accordingly

As for FEN code, I am not sure how else to print the current position to and load positions from strings. It seemed like the best system to use for this when I made the functions, since none of my games involved random shuffling of the initial position.

Hello HG, You have said a while ago that the joker does not receive a piece value. You have also said that the sum of the squares of the values of the opponent's pieces over the sum of the values of said pieces could be a good approximation. This should not be hard to implement, when you have the time, otherwise as the computer makes some funny decision.

Have you seen my last comment HG? Was I clear enough?

HG, If you have time please work towards giving a value to the joker.

The problem is that giving it a value will not solve the problem of strange trades, no matter what the value is. Basically the Joker affects the value of other pieces. E.g. if both sides have a Queen and some Pawns, but one side a Joker (and one less Pawn) the side with the Joker probably has the advantage. At least, I would not trade it at the earliest opportunity for a Pawn. But trading Queens would make the Joker much less useful, and the player with the Joker should avoid it. But to do that it would have to understand that the Queens are not equally valuable. Otherwise it would happily trade them no matter what value was given to the Joker.

I see that is part of the problem, but a value of zero is very naive. Thanks for the wonderful tool!

Where does it get a value 0? When I try your diagram in Apothecary Chess - Classic, it lists it as 455.

If this is not reproducible, then something can be done about that. I can for instance always make it mimic the royal piece, while taking statistics on the number of moves it has (from which the value derives).

I thought it was zero. I must have misunderstood an earlier comment of yours. But this is indeed a difficult problem. I can't even think on how to tackle it.

I've been working on a side project of mine called the Universal Chessboard, a stand-alone application designed to support as many chess variants as possible, within certain parameters. It is somewhat similar to and inspired by these interactive diagrams - for example it uses the same general format for its presets as the format that is used to parse these diagrams (albeit with some parameters added/missing/different). Although it is still very much in its infancy (as it is currently at version Alpha 0.0), it already has many basic features implemented. You can move pieces with the mouse or with text, navigate through the game, undo moves. reset the board, load board positions, load game presets, etc.

You can check out the application in its current state as an Eclipse IDE project or a runnable .jar file here: https://github.com/amdewitt/Universal-Chessboard.

Interesting! I took a look through your source code and it looks like you are off to a good start. Good luck on your ambitious project!