Ratings & Comments

We cross-posted.  I hadn't seen your latest message when I posted mine.

Instead of figuring out which additional moves have to be tried, I just try all moves again, including those that were temporarily rejected for the IllegalUnlessOnly reason, by redoing the entire node in a tail recursion.

Thank you, this makes a lot of sense.  It is cleaner and should occur so infrequently that the cost is minimal.

I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case

Certainly.  I'd imagine there are other cases that will turn up.

Of course one can argue that this entire anti-trading business is pretty much a dedicated feature for Chu Shogi

Sure, but Chu Shogi is important enough to warrant support and the anti-trading rules are appealing enough that they have been implemented in some fashion in several variants (Elven Chess, Golem Chess, Odyssey).  BTW, I now support Elven Chess, although still not Chu, mostly because I haven't found the significant time it will take to code all that and gather the graphics.

I find the idea that a bishop on d1 can only move to a4 or to H5, or a bishop on e8 can only move to A4 or h5, to be completely illogical.

Assuming you mean the spaces in a Switch it can move to and not the full range of its movement, this logically follows from the geometry of the board.

You can bend it with corners and sides so that it seems logical, but basically, from my point of view, it leads to complicating the rules.

As an experienced programmer of Chess variants who has tried to program your game, I can give you my expert opinion that this is not true.

The rule that a switch is a place of decision to occupy the squares of a switch uniquely, no matter from which direction the switch is occupied, seems to be a clear rule that everyone can understand. I do not think that such a rule complicates the course of the game.

It really does complicate the course of the game. It is a tacked-on that does not follow from the geometry of the board, and the code required to enforce it would be more complex than the code required to enforce the rule you mistakenly imagine is illogical.

I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case

Certainly.  I'd imagine there are other cases that will turn up.

Actually, this could also be used for Losing Chess, where you can only make a non-capture if there are no captures.  So all non-captures could be IllegalUnlessOnlys.  Although this would be an inefficient way to do it since it's likely to happen a lot.  A more efficient way would be to have the losing rule listen for both MoveBeingGenerated and MoveBeingMade messages.  In MoveBeingGenerated it just needs to make note of whether any capture was generated.  This wouldn't work if we had to worry about pseudo-legal moves, but Losing Chess has no check/checkmate so I don't think that's a concern.

I have to agree with Fergus. You've created an interesting geometry, but then decided not to honor it.

Every single finished shogi log is saying a move is illegal for some reason.

From the looks of it, a good amount of logs are going haywire; at some point some specific move is regarded as broken and so it can't display the log on the interface itself

Everything here seems to have been designed with the goal of confusing the player as much as possible as leading principle. The board is needlessly distorted, coordinates are needlessly garbled... It is also possible to to draw a regular 8x8 board such that all squares become diamonds, and files and ranks become spirals. Or to assign the rank labels a-h in the opposit direction on ranks 5-8.

Actually it is Suicide/Giveaway that has no checking. In Losing Chess the checking rule does apply, and you lose by checkmating or baring the opponent. So the situation you sketch is not entirely hypothetical. But fortunately engines like to search captures first anyway, so it would be very easy to stop when you reach the captures if the bestScore is no longer -INF (or the legal-move count is non-zero), in variants with mandatory capture.

I have gone through the alphabetical index A-D systematically to see which variants could be handled by the Interactive Diagram. For very many of those, some programming was involved in the form of user-supplied routines for interdicting some moves ('BadZone()'), or forcing type changes ('WeirdPromotion()'). The latter also because the Diagram does not support location-dependent movement rules, but uses the kludge of changing the piece type (often 'invisibly', i.e. to a type with the same image and same ID) to alter the move.

As requiring user-supplied JavaScript severely resticts the user-base, I would like to avoid the need for that as much as possible. So I have been looking for alternative ways of specifying what BadZone() or WeirdPromotion() should do, which can be supplied as Diagram parameters, from which the general Diagram script then would construct the required functions BadZone and WeirdPromotion to implement it. (E.g. by using a table-driven standard function for  it.) This is mainly an interface problem: how can you specify what needs to be done without resorting to Turing-complete programming languages?

The rules for which I had to provide custom JavaScript mostly fell into two categories: "something happens when you reach a certain square/zone", and "something happens when you make a certain capture/move". That 'something' then usually was changing piece type, terminating the game, or forbidding the move.

As a result of this reconnaisance mission, I already implemented a morph parameter that can take care of the majority of 'to-square-triggered' events, through which one can supply a FEN-like description of the board to indicate an event to happen when a piece of the type it applies to reaches that square. Which can be 'declare illegal', 'declare immediate/delayed win', 'change into type ...' or 'offer the standard promotion choice'. Note that game-theoretically declaring a move illegal is the same as specifying it as an immediate loss for the player who makes it.

The other case is still unsupported (or partly supported in an unsystematic way, such as all the anti-trading options). The Golem business also falls under 'capture-triggered event'. I guess a good solution for this could be to have a parameter through which the user can specify a 'capture matrix' of N rows and N+1 columns (where N is the number of participating piece types), rows separated by slashes in FEN-style. The options per square could be change into a piece of a given type (capitals for color of the mover, lower-case for the enemy color), 'declare illegal' (iron or relative iron), 'declare win' (royalty). Iron and royal are really two sides of the same coin, (game-termination, but with opposit result), so it is not surprising that these can be handled in a unified way.

E.g. for Golem Chess (piece types PNBRGHK) the value of this capture matrix would be

.....h../.....h../.....h../.....h../.....H../.....h../.....h..

representing

   - P N B R G H K
P  . . . . . h . .
N  . . . . . h . .
B  . . . . . h . .
R  . . . . . h . .
G  . . . . . H . .
H  . . . . . h . .
K  . . . . . h . .

where the first column of the matrix specifies what happens on a non-capture (e.g. for pieces that morph every move, like in Kyoto Shogi). To keep the size of the parameter manageable several shortcuts could be introduces, like a number for specifying a number of repeats of the previous symbol (implied to be . when there was none, the 0 being reserved for indicating 'kamikaze capture'), a double-quote for repeating the entire previous row (which would reduce the Golem matrix to 5h/"/"/"/5H/5h/").

With a special symbol for 'illegal' (like !) such a matrix can be used to specify absolute or relative ironness, or a Stratego-like pecking order. Absolute royalty could also be specified this way (e.g. by #). Unfortunately conditional anti-trading can collide with morphing, as under some conditions the move would still be allowed, and it should be specifiable what happens then. This could be solved by adopting the convention that symbols representing such rules (capture of protected, counterstrike) do not define a new matrix element, but apply to the preceding one. If counter-strike was represented by =, and capture of protected by %, the special rules of Golem Chess could have been specified by the matrix 5h=/"/"/"/5H%.%/5h%.%/5h= .

The same symbols could be used in the value string for the mateExemption parameter to indicate which anti-trading rules can be broken when there is no alternative legal move. I guess this even could be used for King Succession when the matrix is extended to 2N+1 columns, the final N columns for friendly capture. Then you would put a Betza move udU on the King that would allow it to 'capture' any friendly piece by teleporting to it, but unload it on the square it came from. You would forbid that move in the King's row of the capture matrix for all friendly piece types other than Prince. Under normal conditions you would also like to forbid it for Prince, but suspend that latter restriction in case of checkmate. To be able to specify such a selective suspension, there should be two different symbols for indicating 'illegal'. E.g. ? and ! . King x friendly Prince would then get ?, King x any other friend would get ! , and you would add mateExemption=? .

I now understand that a bishop from d1 can only reach H5 - sometimes it takes a little longer, sorry. G4 shares a side with h5 and so a move to h5 is not diagonal. But why can't a bishop from d1 move to A4 and what am I still overlooking here? B3 shares neither a side with a4 nor with A4. In this respect, a move from b3 to a4 is just as diagonal as a move from b3 to A4. If A4 is not possible, then a color change of the bishop from d1 via A4 to e8 is also not possible. Only the color change from e8 via A4 to d1 would be possible. The situation with the switch h5/H5 applies vice versa. What do I not realize here?

Should the description consider the following knight moves?
Knight on b3, is the move to a5 possible, because on the same diagonal? Or a knight on a3, are the moves to a5 or b5 possible, because on the same line?

@H.G.,

In another comment you said "Actually it is Suicide/Giveaway that has no checking. In Losing Chess the checking rule does apply, and you lose by checkmating or baring the opponent."  This page is titled Losing Chess but says that other names are equivalent: Suicide Chess, Giveaway Chess, Killer Chess or Take-all Chess.  (The filename of the HTML page is giveaway.html)

According to this page, there is no check/checkmate but the rules for stalemate vary.  According to the Wikipedia page for Losing Chess, the "main variant" also has no royal king and a pawn may be promoted to a king.  But it also lists variant #3 with a royal king, which is also mentioned as a variant in Pritchard.

The page for the XBoard chess engine communication protocol lists:

So, I guess we had a number of variants that were collectively known under a variety of names, and someone gave specific names to the specific variants?  Which is a logical thing to do.  This page should probably be updated, but it would be good to know more about how this happened.

Have read your explanations in Reroute66 and am now calmed down that from d1 a4 and A4 can be reached (was completely unsure for me before). In this respect, the color change of the bishop from d1 via A4 to e8 takes place (vice versa the situation from e8 to H5).

In the following constellation you show the possible moves of a knight in Reroute66.

Is it possible that the move to d5 is missing here? 

Why Horde chess exist on Lichess and aren't on Chessvariants? I tried to write Horde's rules but I met a page's number limit) Please write. Lichess is free chess site with billions of games and millions of players worldwide♡

Post a comment if you judge that your submission is ready.

 It is ready now! Please, I have more cool ideas but I haven't place for them on chessvariants.com now. I can wait.

Why Horde chess exist on Lichess and aren't on Chessvariants?

Well, it is nearly the same as Dunsany's Chess. Perhaps it could be added as a note to that page, and the page also put in the alphabetical index under Horde?

As to why variants that are on LiChess might not have an article here, you should pose that question primarily on the LiChess forums. If no one from LiChess creates a page for it, then it is unlikely to be here. Most people here do not visit LiChess, and even when they do, not many people would create articles about someone else's chess variant.

This one definitely does not seem worth publishing. Every one knows that letters can be used to designate pieces, and no one would be interested to use letters for it that virtually no one has on his keyboard. It is also very unlikely that the this particular set of pieces (or a subset thereof) would have to appear in the same variant, and none other. And even when they do, whether the variant designer would use those under the same name, so that the IDs would make sense.

I have updated the ability to mark moves. The ! symbol now displays a dot in the last color. So, if you want to use a specific color, you can add it to the list of colors.

The braces can now be used to display multiple items on the same space. Symbols between braces should be separated by spaces. They will be drawn in the order that they appear. So, if you want a dot over a piece, put the piece label first, then after a space, put a # or !.

I hope triple captures besides those of the Lion Dog become a thing in the future. Perhaps by using two additional variables ex2 and ey2? It shouldn't be too hard, at least for updating the functions that use the variables for the move coords to use the and updating the code for highlights, though I could be wrong. If it becomes too complicated for the AI there's always the enableAI=0 option.