Comments/Ratings for a Single Item

Me too like Aurelian, I was not understanding the controversy. There is an old entry for the Joker in the Piececlopedia: https://www.chessvariants.com/piececlopedia.dir/joker.html where the Joker is defined relatively to the last move of the opponent. Which is Aurelian's definition I believe.

Beside this, is that discussion at the right page? It looks like if ChessV page is hijacked.

Yes, that was what I also said to Greg. There exist various kinds of Imitators. But the practical difference is very slight, as delivering check makes any difference for castling out of check (while normally you would castle before the opponent has any opportunity to check), and deciding whether a mate is checkmate or stalemate (while stalemate is usually only possible when the opponent's King is bare, in which case you will have many ways to checkmate that are not affected by the precice Imitator properties). So it is really a moot point.

Well,HG, Even the rarest of situations have to be taken into consideration.I'll wait to see what Greg has out of all of that!

Ok, I think we are all on the same page now.  Yay!  So we have three different options to choose from.  The difference is what powers of movement a Joker is considered to have when it is the other player's turn.  This only matters for purposes of deciding if that player is in check, or moves through check when castling.

Option 1: The Joker is "reinitialized" each time the owning player moves, returning to its initial state of having no moves at all.  This is how ChessV currently works, and I think the Game Courier preset as well.  Personally, I consider this a reasonable option, but it seems others do not, and it has the unfortunate consequence of meaning that King+Joker cannot checkmate a bare King.

Option 2: The Joker retains the move capabilities of the last piece moved by the opponent.  Therefore, both Jokers always have moves (except on the very first move of the game), and the two Jokers will not necessarily have the same moves.  This is consistent with the description on the Apothecary Chess Modern page.  But I don't think the description on Wikipedia is sufficient to distinguish between this and:

Option 3: The Joker imitates the last piece moved by either player.  This is how the Interactive Diagram currently works and is consistent with the description of the 'I' atom in XBetza.  (That said, I assume there is still ambiguity in the XBetza definition because of questions like whether it imitates the two-space pawn move, can capture en passant, castling, or any other game-specific rules.)

[Edit]: The diagram I posted is a checkmate in both options 2 and 3, but a stalemate in option 1.  The situation H. G. posted is a checkmate in option 2, but a stalemate in options 1 and 3.

Personally, I have no strong preference between these options.  Option 2 is slightly harder to implement but I can still do it if that's the concensus.

The ‘castling out of check’ case suggests to me another definition again: if we consider the restriction on castling out of check to be an extension of the restriction on moving through check — in effect that the K can be captured en‐passant on its starting square, upon having decided to move — then check for castling purposes would always be calculated with an effetive K move for the joker. Iow the move of the J, and whether it gives check, is defined at ‘touch move’ time.

For the case of determining checkmate or stalemate, that would mean that the J would give check with the intersection of the moves of all pieces able to move pseudo‐legally. As such KJK would still lead to checkmate, but with most other combinations of material the J would not give passive check at all. But in e.g. KJKQ the J would give passive check as a K. With more complex pieces (esp. those that can be blocked — particularly the Vulture of the large Apothecary games) this would potentially be position dependent. (And I think it's a little subtler yet in the hypothetical case of a game with both a joker and two royals with disjoint movesets)

Ofc this is probably horribly inefficient to program, provided it's even deemed to make sense (I like it for castling‐out‐of‐check restrictions, but I'm ambivalent between it and Option 2 (by Greg's numbering) for check‐/stalemate — it avoids the surprising(?) behaviour of HG's example where the J checks as a piece that's no longer on‐board, in exchange for arguably slightly greater opaciity of definition), so take it or leave it :‌)

Option 2: The Joker retains the move capabilities of the last piece moved by the opponent.  Therefore, both Jokers always have moves (except on the very first move of the game), and the two Jokers will not necessarily have the same moves.  This is consistent with the description on the Apothecary Chess Modern page.  But I don't think the description on Wikipedia is sufficient to distinguish between this and:

I think this is the implementation I want for my games! 

I don't think the XBetza definition is ambiguous. It says "all moves of the most-recently moved piece type". 'All' really means 'all', so including double-pushes and e.p. captures. (I do not consider promotion part of the move.) It also mentions that it imitates the piece type, rather than a particular piece. So it doesn't matter whether the piece that moved still was able to make its initial move; it is the Imitator that should satisfy the conditions for making the initial move.

This is also how I implemented it in the Diagram: the I atom in the move decription of the Imitator's move is simply replaced by the move description of the piece it imitates, as if the Imitator was of that piece type.

Problems could occur with piece types that do not have a fixed move, like the Elk in Elk Chess. Because the Diagram treats that as two piece types, that promote to each other depending on where they land. The implementation would then imitate the type the Elk promoted to, even if it was on a square shade where a 'unified Elk' would have moved differently. I see this more as a problem / ambiguity in the implementation / definition of the Elk than in that of the Imitator.

in effect that the K can be captured en‐passant on its starting square

This is exactly how I implemented castling in Fairy-Max and the Interactive Diagram. So these would not castle away from an adjacent enemy Imitator, even if it just had landed there through a Knight move. This is an ambiguity in the definition of castling, however. The condition for legality of castling could have been formulated as "when the King could be moved to any square between and including its origin and destination without exposing it to capture". As this describes a stay at the origin as a (null-)move of the King, a Joker should use a King move to capture it even there.

NOTE: When this conversation is concluded, I will move comments to more appropriate places (Apothecary, XBetza, etc.)

The ‘castling out of check’ case suggests to me another definition again ... 

Ofc this is probably horribly inefficient to program

Yes, I'm sorry, this is more complicated than I'm prepared to implement.  And I'm concerned people won't sufficiently understand it.  Look how hard it has been to even get everyone understanding the current issue, and we are all experienced players of chess variants.  H.G. did present another idea which we could call Option 4 - for purposes of check determination when the other side is on the move, the Joker is always considered to move as a King.  (Sorry if I'm not understanding that right.  But I don't think this will be a popular option.)

I don't think the XBetza definition is ambiguous. It says "all moves of the most-recently moved piece type". 'All' really means 'all', so including double-pushes and e.p. captures.

That means that the Interactive Diagram isn't compliant with other rules of Apothecary.  That said, I think that is fine.  It is unreasonable to expect a simple "prototype" testing engine like the ID to enforce very nuanced rules exactly for all games.  But I do think the question is not as clear as you make it out to be.  If you add a Joker to Xinagqi, how does it imitate the King?  Is it restricted to the palace?  If it is not currently in the palace, can it move?  Does it "check" the opponent king across an open file?  Only in the palace?

If you add a Joker to Xinagqi, how does it imitate the King?  Is it restricted to the palace?  If it is not currently in the palace, can it move?  Does it "check" the opponent king across an open file?  Only in the palace?

I was thinking just that, too! 

Yes, I'm sorry, this is more complicated than I'm prepared to implement

I expected as much :)

I'm concerned people won't sufficiently understand it

That is my main reservation with it as well

Look how hard it has been to even get everyone understanding the current issue, and we are all experienced players of chess variants

To be fair, most variants are in this respect noticeably simpler; temporal imitators raise some very subtle timing‐related issues that ‘normal’ pieces can easily ignore

H.G. did present another idea which we could call Option 4 - for purposes of check determination when the other side is on the move, the Joker is always considered to move as a King

Indeed, I saw. For moving out of check, this proposal is equivalent to mine as H.G. has since noted; for mate, it differs only in that the null move (per H.G.'s explanation) can be performed by any piece (with a pseudo‐legal move — though I suppose it'd be a valid simplification to allow it to simply be any piece), not just the King.

(But I don't think this will be a popular option.)

Indeed; it seems a tad artificial to me. My proposal eliminates a bit of the artifice at the expense of some definitional clarity. Which is a tradeoff that I can understand one might be reluctant to make (especially if, as in your case, one finds the J distasteful in any case ;‌) )

If you add a Joker to Xinagqi, how does it imitate the King? Is it restricted to the palace? If it is not currently in the palace, can it move? Does it "check" the opponent king across an open file? Only in the palace?

That depends on how much of the restriction is considered to be a property of the General and how much is considered a general game rule. There's no general consensus on where that line lies; I think all of the particulars you list have been interpreted in a variety of ways by different extrapolations

That means that the Interactive Diagram isn't compliant with other rules of Apothecary.  That said, I think that is fine.  It is unreasonable to expect a simple "prototype" testing engine like the ID to enforce very nuanced rules exactly for all games.  But I do think the question is not as clear as you make it out to be.  If you add a Joker to Xinagqi, how does it imitate the King?  Is it restricted to the palace?  If it is not currently in the palace, can it move?  Does it "check" the opponent king across an open file?  Only in the palace?

Indeed, I don't worry about that. The purpose of the ID is not to provide an exact implementation of any particular variant. Just to provide a set of tools that makes it possible to get a fair approximation. And, as I said, this whole issue is a moot point. You could probably play hundreds of games before you encounter a situation where a Joker check would or would not make castling illegal or would checkmate or stalemate depending on this.

In general I don't think much of rules or rule complications that have next to zero effect on actual game play. I would always go for simplicity when it does not matter.

As for a Xiangqi Joker; this doesn't seem decidable by logic. It depends on whether you consider confinement as part of the move rules, or as an independent property of the piece type. Like the Joker would not mimic the royalty either, and can use a King move to step to an attacked square any time it wants. But of course you could make rules that would mimic any properties of the last-moved piece type.

Option 2: The Joker retains the move capabilities of the last piece moved by the opponent.  Therefore, both Jokers always have moves (except on the very first move of the game), and the two Jokers will not necessarily have the same moves.  This is consistent with the description on the Apothecary Chess Modern page.  But I don't think the description on Wikipedia is sufficient to distinguish between this and:

I think this is the implementation I want for my games! 

Ok, if there are no objections, this will be the behavior of the ImitatorRule in ChessV.  (I do not really want to support different flavors of imitators if I can help it.)

As long as we are revisiting the Joker, I would also like to address the pawn issue.  I would like to avoid the Joker imitating the pawns differently in different Apothecary games if we can.  I think the easiest and cleanest way is for me to add an ability to specify a position-dependant move by a Rule so that it won't be imitated.  This way the game designer can have it either way -- as a regular MoveCapability of the piece (if you wanted it imitated) or as a Rule (if you don't).

Those sound great!

Ok, if there are no objections, this will be the behavior of the ImitatorRule in ChessV

No objections from me

as I said, this whole issue is a moot point. You could probably play hundreds of games before you encounter a situation where a Joker check would or would not make castling illegal or would checkmate or stalemate depending on this.

In general I don't think much of rules or rule complications that have next to zero effect on actual game play. I would always go for simplicity when it does not matter.

It's effectively moot in the Apothecary games, sure. Nevertheless it's not so difficult to contrive games where the issue would carry greater importance: consider a game featuring both a joker and an orphan. Such a game would have an equivalent problem with determining under which conditions the joker threatens — and thus relays moves to — the orphan, which one would imagine would have a substantially greater effect on gameplay (especially if it's a gimmick game with several of a few different imitators).

The latter case is (much like the orphan itself, and perhaps even the joker) ofc of even greater interest to problemists than variantists, and they don't really tend to have much of a presence here

consider a game featuring both a joker and an orphan

Yeow.  Just as a practical matter, a game with both a Joker and an Orphan is unlikely to ever be supported by ChessV, and that probably goes for most any universal chess engine that wasn't built specifically for that.

ChessV has fundamental movements that are handled natively by the internal move generator, but some capabilities that you would like to be intrinsic to the piece itself are implemented by special Rules that are plugged into the game.  For example, the internal move generator does not understand capture-by-advance.  So the Advancer in Butterfly Chess gets this capability via the CaptureByAdvanceRule.  The ImitatorRule doesn't "know" anything about the CaptureByAdvanceRule, so if you drop a Joker into Butterfly Chess, it will not be able to imitate the Advancer's power to capture by advance.  This is unfortunate, but it is just a practical reality.  In order for ChessV to do everything that it does as well as it does, and without bugs, some functions need to be encapsulated in a strict separation-of-concerns.

Besides, if we did contemplate a game with both of these pieces, I bet we could come up with a LOT of complex corner-cases where it isn't clear how they should interact anyway.  (But that's just a hunch.)

As for a Xiangqi Joker; this doesn't seem decidable by logic. It depends on whether you consider confinement as part of the move rules, or as an independent property of the piece type. Like the Joker would not mimic the royalty either, and can use a King move to step to an attacked square any time it wants. But of course you could make rules that would mimic any properties of the last-moved piece type.

I agree 100%.  I was just making the point that the XBetza "I" atom doesn't answer all questions.  I think the XBetza page should probably note that different implementations may vary.

What board dimensions does ChessV allow, and is that determined by the total number of squares or are there strict limits on the width and height?

What board dimensions does ChessV allow, and is that determined by the total number of squares or are there strict limits on the width and height?

Both.  You are limited to a maximum of 16 files and 16 ranks.  But there is also a limit of 192 squares, so you can't really get 16x16.  The largest size is essentially 16x12 or 12x16.  Someday this might be increased, but not any time soon.  Going to 16x16 would not be too large a code change, but it would have a performance cost for every game, even small ones.

A (late) question to Greg. In your Option 1: Option 1: The Joker is "reinitialized" each time the owning player moves, returning to its initial state of having no moves at all. This is how ChessV currently works, and I think the Game Courier preset as well. Personally, I consider this a reasonable option, but it seems others do not, and it has the unfortunate consequence of meaning that King+Joker cannot checkmate a bare King.

I have not understood how the joker is moving. I understand Option 2 and 3, but what about 1? Let's imagine the Owner moves a Rook, then the opponent moves a Pawn. How is the Joker moving now if it has no moves at all?

Both.  You are limited to a maximum of 16 files and 16 ranks.  But there is also a limit of 192 squares, so you can't really get 16x16.  The largest size is essentially 16x12 or 12x16.  Someday this might be increased, but not any time soon.  Going to 16x16 would not be too large a code change, but it would have a performance cost for every game, even small ones.

Isn't there a more sensitive choice to have a ChessVBig build separatly? This would not cut the performance for chessV small and allow users to have speed in the smaller boards case and also allow to implement 16x16 games.! 

Isn't there a more sensitive choice to have a ChessVBig build separatly? This would not cut the performance for chessV small and allow users to have speed in the smaller boards case and also allow to implement 16x16 games.! 

Sure, this could be done, but I am not enthusiastic about maintaining two versions.  And I am not sure this is a problem in practice.  There are other reasons it is not going to play Dai Shogi or Tenjiku Shogi.  I'm sure there are less crazy 16x16 games, but I still don't know how well it would work.  ChessV is well-written and modern computers are powerful but at some point exponential growth still overwhelms you.  I don't think 16x12 has even been tried.  You could try this and see how it goes.

The only game I'd like to invent of this size would be an 16x16 Chu Shogi variant, named apothecary of course. But for this it is way more important to see chu shogi in ChessV which is in itself stretchy!

I have not understood how the joker is moving. I understand Option 2 and 3, but what about 1? Let's imagine the Owner moves a Rook, then the opponent moves a Pawn. How is the Joker moving now if it has no moves at all?

Ok, one last try.  The question is how a Joker moves when it is not that player's turn.  When it is white's turn to move, how does black's joker move?  After white moves, of course black's joker moves like whatever piece white moves.  But when it is still white's turn, how does black's joker move?  Under option 1, it has no moves at all.

This usually makes no difference because black pieces don't move when it is white's turn anyway.  The only time it matters is for deciding if the current player is in check.

It is black's turn to move.  Is he in check?  That depends on how the white joker moves at this moment.  Under option 1, the white joker has no moves because it is not his turn.  So black is not in check.  The game is still over!  If black moves, then the white joker will again be able to move like a king and black will be in check.  It is not legal to move into check, so black has no legal moves and the game ends.  But it ends in stalemate, not checkmate, because he is not in check at this moment.  It would be the same outcome if the white joker could move, but was currently emulating a rook.