Classes of chess pieces for chess variants

[hgm]

the values you quote contradict the results of tens of thousands of games by a large amount (more than a full Pawn!).

I guess the question would be if there's a way to extract, determine, or "guess" the value of a piece given its mobility and known board's topology, because if the only way to know their value is to play tens of thousands of games it becomes a stumbling block.

This could be considered the holy grail of piece-value theory. As the case of the Archbishop shows we are still pretty far from achieving that goal. Virtually every method I have seen, even those that look pretty advanced, tend to be off by a large amount.

[Ovyron]

Ah, so no matter how accurate and advanced a method is, someone can always come up with a new piece that has a mobility that breaks the system. That's actually very cool.

[hgm]

It is not proven that this is the case; it is conceivable that methods exist that are alsways highly accurate. It is just that no one has found one yet. The most obvious method of calculating the number of moves on an empty board averaged over the board is not even consistent:

Consider a piece that moves like a Bishop on black squares, and can also make one orthogonal step (everywhere). A Bishop on average has 8.75 moves. The orthogonal step contributes on average 3.5 move. The Bishop move on half the squares adds on average 4.375 move. So the total average mobility is 3.5 + 4.375 = 7.875. This is nearly one move less than a plain Bishop. While the piece is obviously superior to a plain Bishop, as you can always use it as one by staying on the black squares, and even then the threat it exerts on the other shade is still useful. (It would for instance be able to force checkmate on a bare King without ever leaving the black squares.) So the piece with the fewer moves is the stronger one. The counting method obviously fails because it does not take account of the fact that squares where the piece has very poor mobility will in real live not be visited as often as squares where it has good mobility.

[Ovyron]

Well, for this thread specifically, it might just be outright impossible to classify the pieces, because the cards in the game, which are hidden information, could just change their value drastically. Imagine that there's a special kind of pawn, that only captures towards the edge, and can't promote. When it reaches the last rank of the board it captures itself. How would it rank against the normal pawn? If most of the game a pawn is 1.00 even though it can turn into a queen?

Well, suppose that there's a Bomb card that allows this pawn to explode, killing any enemy piece on the 8 surrounding squares. Since you don't know if this card is coming, the King can't ever get near this pawn to capture it, as it potentially could get itself in check. Now, how do you even calculate the value of this pawn?? It depends on where on the deck is the Bomb card and we can't know that.

It's curious that the topic of classifying and valuing fairy chess pieces comes in the variant where cards change everything.

[RichV]

What is wrong with this, then?

I was referring to the jocly website (probably jocly.com) that was destroyed by hackers and there are evidently no plans to rebuild it. Apparently, some of the jocly developers have partially brought it back on GitHub. I followed your link, which opened the Jocly version of Byzantine chess on GitHub. I could move the pieces around to play a game, but that was about it. I could not even right-click a piece to see its properties (like in Zillions) to determine its point value. I had previously looked at some of the JavaScript on GitHub for Circular Chess, but the code was far too complex for a code novice like me to understand enough to know how it fully worked. Zillions of Games script is much easier (much more 'user friendly') for me to grasp without having to be a Zillions of Games programming expert. The code I created/manipulated was not pretty and probably not very efficient, but it works well. I am good at recognizing code patterns and seeing differences in blocks of script. But too much detail and a high use of hundreds of symbols quickly becomes overwhelming to me in JavaScript. Zillions of Games script is very clean looking with minimal use of symbols, so it was easy for me to analyze and figure out how it worked, especially when reverse engineering an existing chess zrf to convert it to my game.

It was especially easy to incorporate my CirSquare board into Zilliions. All I had to do was determine the 2D coordinates of two opposite corners of the invisible rectangle overlay for positioning a piece on each of the 96 spaces and then give each space a name. Creating the link groups for piece moves was also very easy. Looking at the jocly code, I don't have a clue where to start, even when trying to reverse engineer the jocly script for Circular Chess. However, since jocly appears to be my only real choice for programming my Castle Siege Chess game anytime soon, it looks like I will have to go to the local universities and try to find some students in the gaming programs that have had some JavaScript courses and see if any of them would be interested in trying to do the reverse engineering for me. Zillions allows a game player to very easily do many things - drop pieces, remove pieces, vary the power of the engine when playing the computer, etc., etc. Jocly seems to be able to do little more than make piece moves. It is too bad for me that the owners of Zillions of Games apparently lost interest in it over the years or it was just too much work for them for the money it was making them.

[RichV]

BTW, just out of curiosity: you say you also want to include other Musketeer Pieces. But some of those (e.g. Cannon) are not fully 8-fold symmetric. They have moves in some directions, but not in other symmetry-equivalent directions. But directions are not a well-defined concept on your CirSquare board, where rays that start out in parallel can later intersect perpendicularly. You could define the moves relative to a current 'orientation' of the piece, and have rules for the relation between orientation before and after the move. But the natural rules for this would not always conserve the orientation while moving along a closed path. In particular when the path encloses a triangle, a piece moving along it will experience a 90-degree rotation.

That is true. I would have had to create more link groups that specifically had only vertical orthogonal moves for particular moves of the cannon. Since I was already at the 100 link group names maximum, I had to allow those moves to be both vertical and horizontal and change the name from 'Canon' to 'Falcon Cannon' which was a popular small medieval cannon for both the battlefield and warships.

To script piece moves in Zillions, all I had to do was create lists of links that represented all of the possible moves and also create zones for things like Pawn promotion and the King being next to a castle wall when in check. The only problem I had to work around was the maximum of 100 named groups of move links. The move descriptions you talk about for other chess engines sounds very complex to me, but I am sure it is much more efficient for the chess engine to run. If my games ever get online and become as well-liked as the board game versions, then I will need to have a good computer game company program the games properly. But for me it is sort of the 'chicken and the egg' problem--although my board games are well liked by most of the players that have played them, they all want to be able to play it online, too. So before I can spread the board game far and wide, I need to have it available online first. Therein lies the problem.

[RichV]

Well, for this thread specifically, it might just be outright impossible to classify the pieces, because the cards in the game, which are hidden information, could just change their value drastically. Imagine that there's a special kind of pawn, that only captures towards the edge, and can't promote. When it reaches the last rank of the board it captures itself. How would it rank against the normal pawn? If most of the game a pawn is 1.00 even though it can turn into a queen?

Well, suppose that there's a Bomb card that allows this pawn to explode, killing any enemy piece on the 8 surrounding squares. Since you don't know if this card is coming, the King can't ever get near this pawn to capture it, as it potentially could get itself in check. Now, how do you even calculate the value of this pawn?? It depends on where on the deck is the Bomb card and we can't know that.

It's curious that the topic of classifying and valuing fairy chess pieces comes in the variant where cards change everything.

The Action cards provide only a temporary change in power for a piece for one turn. The increase in power is not permanent. Thus the Action cards have no effect on the placement of a piece in the Class list.

I want the class list to be a way of having a hierarchy (of not more than about a dozen levels) of pieces in fairly small groups (no more than about 6 to 8 piece types per group) based loosely on their relative powers/usefulness for playing a particular chess variant on a particular chess board. This will allow me to keep the number of Action cards to minimum for any particular variant while allowing the maximum number of chess pieces to choose from for playing the game. Each game would have its own printable class and piece list to use for reference while playing a game that uses Action cards.

[hgm]

I was referring to the jocly website (probably jocly.com) that was destroyed by hackers and there are evidently no plans to rebuild it. Apparently, some of the jocly developers have partially brought it back on GitHub. I followed your link, which opened the Jocly version of Byzantine chess on GitHub.

That was actually on my website, not Github. The source code of the Jocly interface is on Github, so that anyone could install it on his own website, which is what I did. (I also added some games of my own, which are not available in the Github verson, such as Shogi, mini-Shogi, Tori Shogi, Chu Shogi, Tehjiku Shogi, Werewolf Chess, Spartan Chess, and Scirocco).

I could move the pieces around to play a game, but that was about it. I could not even right-click a piece to see its properties (like in Zillions) to determine its point value.

Jocly never did this, isn't it? Or was that possible when they were still running it at Jocly.com? BTW, Jocly has no heuristics to calculate piece values from the way the piece moves; the implementer of a Jocly game has to specify both the move and the value of each piece. Of course they can be read from the source code. But I think it would be rather pointless; taking those values would just mean copying whatever the game implementer had guessed. There is absolutely no way to know whether his guesses would be any better than your own.

I had previously looked at some of the JavaScript on GitHub for Circular Chess, but the code was far too complex for a code novice like me to understand enough to know how it fully worked. Zillions of Games script is much easier (much more 'user friendly') for me to grasp without having to be a Zillions of Games programming expert. The code I created/manipulated was not pretty and probably not very efficient, but it works well. I am good at recognizing code patterns and seeing differences in blocks of script. But too much detail and a high use of hundreds of symbols quickly becomes overwhelming to me in JavaScript. Zillions of Games script is very clean looking with minimal use of symbols, so it was easy for me to analyze and figure out how it worked, especially when reverse engineering an existing chess zrf to convert it to my game.

True, Jocly is a superb program, but the code was not written with easy implementing of new games by non- or novice programmers in mind.

It was especially easy to incorporate my CirSquare board into Zilliions. All I had to do was determine the 2D coordinates of two opposite corners of the invisible rectangle overlay for positioning a piece on each of the 96 spaces and then give each space a name. Creating the link groups for piece moves was also very easy. Looking at the jocly code, I don't have a clue where to start, even when trying to reverse engineer the jocly script for Circular Chess. However, since jocly appears to be my only real choice for programming my Castle Siege Chess game anytime soon, it looks like I will have to go to the local universities and try to find some students in the gaming programs that have had some JavaScript courses and see if any of them would be interested in trying to do the reverse engineering for me.

It depends on what you want the program for. Jocly is a superb interface, but its generic AI is quite weak. And it doesn't easily allow playing of many games and collecting statistics on those for deriving piece values. Such things would be much easier with a conventional engine running under a GUI like WinBoard. But as an interface for a game on a CirSquare board WinBoard would suck even compared to Zillions: the board would have to be mapped on a conventional grid board (e.g. 12x12), where you would skip some of the squares. For automated engine-engine play you would not care about that at all, but for human-engine games it would probably be unacceptable.

Zillions allows a game player to very easily do many things - drop pieces, remove pieces, vary the power of the engine when playing the computer, etc., etc. Jocly seems to be able to do little more than make piece moves. It is too bad for me that the owners of Zillions of Games apparently lost interest in it over the years or it was just too much work for them for the money it was making them.

True, Jocly is intended to be an interface, and the AI is quite rudimentary, little more than a demo to practice the rules. I guess the main envisioned use case is to act as interface of a server to allow humans to play the supported games on line against each other.

[hgm]

BTW, if you are interested I can make an attempt to convert Fairy-Max for playing on a CirSquare board. You would have to remind me a bit of how exactly sliders move through a triangle; I vaguely recal that you wrote on chess.com that their trajectory forks there, but that they are allowed to do that only once. (While the triangles are positioned such that the orthogonals and diagonals through them often lead to a second triangle.) Does that mean they can move onto the second triangle, but not past it? (And can they also do that when they start from a triangle, i.e. move to the next, pick one of the two continuations there, and land on the third?)

The whole Fairy-Max AI is only about 200 lines of code, so it should be pretty easy to change. The way I would do it is by changing the inner two nested loops of the move generator (which step through directions and for each direction through travel distance). Instead of looking up the board step for each direction in a table, and then (possibly repeatedly) add that to the start square for as many times as the range in that direction (also tabulated) allows, I would do the following:

Make a 'rays' table that contains all possible slider paths over the board, as a sequence of square numbers (terminated by the invalid square number -1). For each type of move (orthogonal, diagonal, ...) I would, for each board square, contain a list of where in the rays table the moving should start, and then the move generator would just step through the ray from that point on until it has done as many steps as the specified range in that direction, or reaches the -1 (indicating the ray runs off board). E.g. for a conventional 8x8 board the ray table could start as

1, 2, 3, 4, 5, 6, 7, -1, 6, 5, 4, 3, 2, 1, 0, -1, ...

describing the orthogonal rays b1->h1 (1->7) and g1->a1 (6->0). The table for orthogonal moves would then contain for start square e1: 4, 11, ..., meaning that slider paths start at the 4th element (the 5; counting starts at 0) and the 11th element (the 3), and from there travers through 5, 6, 7 or 3, 2, 1, 0, respectively, when generating orthogonal slides. (And of course abort when a piece is encountered along that path.) For square c1 the start points in those rays would be 1, 8, ... (i.e. they would use the same part of the ray table).

The size of the ray table can remain quite limited that way, as each tabulated ray can be used by many squares. If I fold out the CirSquare board to a 12x12 square board, there would be 16 orthogonal rays of length 12 passing through the central 4x4 area, and 6 'race-track' (3 pairs of opposite travel direction) and 4 'star' paths that can be traveled in 3 directions each. The length of the race-track rays is a bit tricky, as they close on themselves after 20 steps, and thus have no natural end; perhaps these are best tabulated for two laps around the board, always starting from a square in the first lap, so that you can be sure enough length remains to reach every square (and then limit the range always to 19).

[RichV]

BTW, if you are interested I can make an attempt to convert Fairy-Max for playing on a CirSquare board. You would have to remind me a bit of how exactly sliders move through a triangle; I vaguely recal that you wrote on chess.com that their trajectory forks there, but that they are allowed to do that only once. (While the triangles are positioned such that the orthogonals and diagonals through them often lead to a second triangle.) Does that mean they can move onto the second triangle, but not past it? (And can they also do that when they start from a triangle, i.e. move to the next, pick one of the two continuations there, and land on the third?).

That would be fantastic and highly appreciated!! I still want to send you a physical copy of my game. To cut down on the weight, I will only send the Archers (Longbowmen) and Catapults (Onagers) because I feel sure that you have at least 2 classic chess sets. I will put 2 boards in the game box and include a printed rules document. I will pay for shipping. That way you can have the actual physical game to manipulate and play. I just need an address to mail it to.

Some of the more important rules pages on my CastleStrife.com website are:
Setup: http://castlestrife.com/03_csc_03_03_csc_g_setup.html
Piece moves: http://castlestrife.com/03_csc_03_05_csc_pc_moves.html
Rules different from classic chess: http://castlestrife.com/03_csc_03_06_csc_diffs_tc.html
Move examples: http://castlestrife.com/06_ccc_06_04_warmovesweap.html

The Move Examples page has many good examples of pieces moving through the triangular spaces, especially the B and R. Click the brown buttons on the Move Examples page; on the piece page, click the Piece Moves Home button at the bottom of the content to return to the Move Examples menu page.

The long-range pieces (B, R, Q, etc) when lined up with a triangular space can often pass through more than 1 triangular space. Each triangular space acts as a fork in the road--enter the triangle across a corner, the piece can exit across either of the other 2 corners; enter the triangle across a side, the piece can exit across either of the other 2 sides. As the piece moves, it must abide by the castle walls rule that states that on a single move a piece cannot have more than 2 castle wall crossings, and crossing the same wall twice counts as 2 castle wall crossings. Thus a B can only pass through 2 triangles and it must exit the second triangle without crossing a castle wall; and a R or Q moving across sides can pass through as many as 4 triangles, as long it does not have more than 2 castle wall crossings during the move.

I am very hopeful that you are successful with programming Thrones Chess II (aka Castle Siege Chess) in Fairy-Max. After putting the Musketeer Chess pieces into the Zillions of Games Thrones Chess II variants (70 to date based on the pieces used and the setup of the pieces), I will start incorporating the Fairy Chess pieces that are different from Musketeer Chess. That will take me quite a while.

Thank you very much!!!