Ratings & Comments

Also I do not know how to make the difference between white and black pieces.

If all your pieces have symmetrical moves, you could just include one direction in the image. Then you wouldn't need so many squares on a grid.

They're harder to quickly tell apart, and they can be hard to read. For example, I thought the third piece in your lineup was a Knight until I noticed the first piece, which is more clearly a Knight in a comparison between the two.

I thought so, too, but I cannot add a grid as there is not enought room on the 50x50 picture. Also it seems to me difficult to imagine pictoreals. For this game a rook+knightrider was already drawn by Greg. It has to be here somewhere. This will be called varan. Then I need a gnu, this is also on the website. And for now I'm using cobra for a piece that moves and captures like a rook and ferz and moreover captures like a cannon. Someone called it a mortar which sonds good enough, although I prefer something more mithical. These should go with both gamecode and interactive diagram, so I'll have to do some drawing, and it is easier to do these simbolic pieces.

What do you guys think about this?

I dislike movement diagram pieces and would not want to use them myself. They're harder to quickly tell apart, and they can be hard to read. For example, I thought the third piece in your lineup was a Knight until I noticed the first piece, which is more clearly a Knight in a comparison between the two. So, I would hope that a pictorial option remains available for any games you would use these for.

I think you can draw Allfarie pieces, with something like mspaint. Once drawn I think you need to work with the admins at this site to get the graphics installed into a particular web directory. Fergus has written a How-to on this. (I think). Your icons above look like Knight, Camel, Zebra, rook, bishop, ???, Gryphon. They are well done, but have a look/feel that is not as satisfying as an Allfarie piece. What got me interested in chess as a child was the pieces them selves, and the wood carvings. For your game, I love the introduction of the joker. It is a very interesting piece. If your game is showing legal moves I personally feel the arrow design is not needed. If you are making a commercial board game that is not a computer program, I admit your arrow piece set would be very useful.

This is just my opinion, and your piece set is well designed.

 As I'm not able to draw Allfarie pieces I have decided to create my own piece set. Here are the first attemps. What do you guys think about this?

249, 249, 249

@Greg, May you please tell me what is the RGB for the colour #f9f9f9.

I'm sorry to say but it works in the same way.

Okay, I made some corrections to a test version at this URL:

https://www.chessvariants.com/play/pbm/play.php?game=Apothecary+Chess-Classic&settings=fpdtest

In both your Post-Move code and the stalemated subroutine I gave you, I had to make sure that last_type_moved was updated before testing whether the King was in check.

With these changes made, all my tests worked. I created a position in which the White Joker was on a diagonal with the Black King. When White moved a piece with a diagonal move, it put Black in check. After blocking with a Knight, I was able to move the Knight away on the next turn. With the King in check again, the Knight could block, capture the Joker, or move to another space, which would end the check by changing the powers of the Joker. With the King not in check, the only legal move for one Bishop was to go between the Joker and the King, and the other Bishop, the Archbishop, and the Queen had no legal moves, because moving any would place the King in check.

@Fergus.

I'm sorry to say but it works in the same way. I tried black to move when the black joker has an unobstructed orthogonal path to the white king and when the black rook moved the white king was in check. Also when the king was 3 squares orthogonally away from an enemy joker all of that king's siege elephants should be pinned. This does not happen, but then when the king gets captured the game is over anyway so this is not such a serious bug. Only the fact that the players need to be careful.

I assume that for the first matter a fix would be to use the value of the piece moved 2 ply away. That would have to be stored in a different variable but if you think that is the case I could be able to make the changes myself.

I am getting now an error in the checked subroutine towards the end:

The error said : "The function 'last_type_moved' has not been defined. Its arguments are e11 f2"

This means it is trying to call a function by the name last_type_moved. It looks like the error is on the following line:

set ltm last_type_moved;

Change this line to this:

set ltm var last_type_moved;

This would depend on how those pieces are defined. If they are treated as making two separate moves on the same turn, and the second move is capable of checking the King, things could prove difficult.

Moves in general are a succession of 'legs', each leg having a specified step, but possibly undetermined length (for rider legs). The move generator treats the legs in the order they occur in the move: first it tries to realize the first leg, (i.e. find destinations for it that are compatible with the 'mode' of the leg, e.g. contain an enemy piece if the leg must capture) looping through all possible realizations, and for each of those recursively calling itself to treat any remaining legs. (And when it realizes the final leg, deliver the move). I suppose this is very much like what you call 'making separate moves in the same turn'.

I wonder if it makes sense to try saving on doing a full move generation for the opponent (in the position before the move). Because that move generation is also used to mark all the attacked squares, so that it is known which moves of the royal stumble into check. So it is not only a matter of deciding whether the royal is under attack, but also whether all squares where the royal can go are under attack. Without that information, you would have to test each move of the royal separately. In the case of an orthodox King that would be 8 moves, so even when you safe a factor 8 on the test because you have to try only a single move for each piece, you sitll have no gain over doing all moves of each piece once. And what exactly you would have to do would depend on how the royal moves, which makes it hard to use tricks to speed it up.

So I guess for now I stick to generation of all (pseudeo-legal) moves for the side to move (to create the list needed for highlighting), and, in the same position, a full move generation for the opponent. During which attacked squares are marked, and when these contain an enemy piece and an attacking slide has not yet exhausted its range, tabulate the origin and move of that attack with the square. So they can be retried in reply to moves that moved that piece away (to test whether it was pinned), or after every move when the piece was royal (to see if the pre-existing check was resolved).In most positions you will not be in check, and most pieces will not be pinned, so the common case is that nothing has to be done on a per-move basis. Only if the game contains 'unpredictable' pieces, such as hoppers or hook movers, then you would have to generate all moves of those in reply to every move of your own.

@Fergus,

I'm not sure if you noticed, I have found an error earlier!

With regard to Sissa, perhaps the hybrid solution is the right one.

While that might make the notation look better, it's not really required for moving the piece, since it does not capture anything on the space where it turns.

This would depend on how those pieces are defined. If they are treated as making two separate moves on the same turn, and the second move is capable of checking the King, things could prove difficult. If their move is treated as a single move that requires a turning point, or checking is allowed only on the first part of a move, then it's not a problem. There could even be a hybrid solution, in which the piece has a checking-only move that completes the whole move, but it otherwise handles actual moves as a pair of separate moves.

With regard to Sissa, perhaps the hybrid solution is the right one. Take into account the uniqueness of this piece. In the diagram below the blue King is in check in two different ways but what is somewhat paradoxical is that by moving to d6 or e6 it evades the check.

My code is not that brute force. It does not try all possible opponent moves. It limits itself to checking whether each enemy piece can move to the King's position. So, it checks no more than one move per enemy piece. Second, it returns a true value as soon as the first check is found.

That is a very good method for most pieces. The problem is that I have to be completely general, as users can in principle define sliders that turn corners, such as the Sissa or the Hook Mover from the large Shogi variants.

This would depend on how those pieces are defined. If they are treated as making two separate moves on the same turn, and the second move is capable of checking the King, things could prove difficult. If their move is treated as a single move that requires a turning point, or checking is allowed only on the first part of a move, then it's not a problem. There could even be a hybrid solution, in which the piece has a checking-only move that completes the whole move, but it otherwise handles actual moves as a pair of separate moves.

Thanks, it works now!

No Erik That was me testing. Once again I had ventured my testing on the real thing. I'm sorry. You may now proceed!

I am getting now an error in the checked subroutine towards the end:

for (from piece) fn enemies

994 if fn const alias #piece #from var king

995 return #from

996 endif

997 next

The error said : "The function 'last_type_moved' has not been defined. Its arguments are e11 f2"

Sorry, but now when I try to click on the log I arrive on an error page. Maybe I should not have played the last move and I should have waited that the problem is solved.

My code is not that brute force. It does not try all possible opponent moves. It limits itself to checking whether each enemy piece can move to the King's position. So, it checks no more than one move per enemy piece. Second, it returns a true value as soon as the first check is found.

That is a very good method for most pieces. The problem is that I have to be completely general, as users can in principle define sliders that turn corners, such as the Sissa or the Hook Mover from the large Shogi variants. Such moves could come from anywhere, and they do not have to start in the direction of the King to hit the latter. Note that with the short-cut it is not that much 'brute force' anymore, because for each move it tests the legality of it selectively only tries the sliding moves that were hitting the moved piece as a reply. And most pieces were not attacked by an enemy slider at all, and for those you don't have to do anything. But the preparation step, to figure out what enemy slider moves are blocked, (done as a side effect of the test whether you are actually in check to begin with) is currently purely brute force.

I cannot even abort that when it does find a check, because I have to make sure it will detect every piece that blocks a slider. Otherwise it might use a pinned piece to interpose on the check. But that is no big loss: usually you are not in check, and then has to run the test to the end to conclude that. And it only doubles the effort compared to pseudo-legal highlighting: for that you have to generate all moves of the player that is on move anyway, and now you also have to do it for the opponent.

It sounds like this can handle riders, but what about hoppers or other complicated pieces? This reminds me of code I wrote just for Chess, which was optimized for Chess but couldn't handle every type of piece that might show up in a variant.

Indeed. Hoppers (or locust capture) are a pain. In principle the same method could be used if I also recorded for every square which hopper moves pass over it, and then recalculate these moves only as a reply to a move that lands on such a square. But there are typically many more empty squares you pass over than there are enemy pieces that block you, so that is a lot of overhead. (But there could be far fewer hoppers than other pieces in the game...) Application of the short-cut is controlled by a configurable parameter, and the only way to do fully-legal highlighting in a game with hoppers is currently to disable the short-cut. Which can make the preset annoyingly slow, as it would then do a full opponent move generation for every move. This is definitely something that begs improvement.

I guess a first step would be to tabulate which piece types are 'unpredictable', and classify hoppers (and imitators) as such. And then always try all moves of these pieces in reply to the 'move under test', but forget about the others (except for the pre-existing checks and the discovered slider moves).

To speed up fully-legal highlighting, I use a short-cut: Instead of trying all possible opponent moves to see if they capture the King, I only try those that might have been affected by the move of which we want to judge the legality.

My code is not that brute force. It does not try all possible opponent moves. It limits itself to checking whether each enemy piece can move to the King's position. So, it checks no more than one move per enemy piece. Second, it returns a true value as soon as the first check is found.

To that end it first marks all squares attac[k]ed by the opponent in the original position with its own King removed, and for every piece it makes a list of moves (origin and direction) that they obstruct. It also makes a list of pre-existing checking moves. After trying a move, it then only reruns the pre-existing checks in the resulting position (to see whether these are now resolved), plus the moves that were blocked by the moved piece (to check whether that piece was pinned). And for King moves it tests whether these go to a square that was marked as being under attack.

It sounds like this can handle riders, but what about hoppers or other complicated pieces? This reminds me of code I wrote just for Chess, which was optimized for Chess but couldn't handle every type of piece that might show up in a variant.