Comments by GregoryStrong

If anyone hasn't checked out ChatGPT, it's worth a look. It's creativity is pretty impressive. I asked it "Can you invent a chess variant?" and it responded:

Sure, here's a simple chess variant:

1. Introduce a new piece called "The Timekeeper". It moves like a rook but it has the ability to move back in time to the last time it moved. It will change the position of the board as it was in the previous move.

2. Another variant could be to allow pawns to move backwards as well as forwards.

3. Introduce a new piece called "The Portal". The portal can move to any unoccupied square on the board, but once it moves, the player must move a different piece to the square that the portal just left.

4. Another variant could be to allow pawns to move diagonally when capturing, but not when moving normally.

5. Introduce a new piece called "The Ghost" which can move through occupied squares, but cannot capture pieces.

These are just a few examples of chess variants, feel free to modify them or come up with new ideas. The possibilities are endless!

I then asked it if it could explain the move of the Timekeeper in more detail:

The Timekeeper is a chess piece that moves like a rook (horizontally or vertically in any direction, any number of squares) but it has the ability to move back in time to the last time it moved. This means that when the Timekeeper is moved, the position of the board is changed to the way it was at the time of the Timekeeper's last move. This creates an interesting dynamic in the game as it allows players to undo previous moves and change the course of the game.

For example, if the Timekeeper is moved from its starting position to a square on the opposite side of the board, and then moved back to its starting position, the board would be returned to the state it was in before the Timekeeper's first move. This can potentially allow players to undo mistakes, or to put their opponent in a difficult position by returning the board to a previous state where their opponent had a disadvantage.

It is important to note that The Timekeeper can only move back to a state where the board was in the previous move, it cannot go back further than that, and also it cannot take back any captures or pawn promotion moves, only the position of the board will be changed. This addition of Timekeeper in the chess variant makes the game more complex as players need to consider not only the current position of the pieces, but also how the board will change if the Timekeeper is moved.

Then I asked it to write a rap song about chess variants:

Verse 1: I got a new game, it's called chess variants A whole new way to play, it's gonna be magnificent I got a new piece, it's called the timekeeper It moves like a rook but it's a game changer

Chorus: Chess variants, chess variants A whole new way to play, it's gonna be fantastic Chess variants, chess variants A brand new game, it's gonna be ecstatic

Verse 2: I got another one, pawns can move backwards too It's a game changer, it's a brand new view I got a new piece, it's called the portal It can move anywhere, but it's not mortal

Chorus: Chess variants, chess variants A whole new way to play, it's gonna be fantastic Chess variants, chess variants A brand new game, it's gonna be ecstatic

Verse 3: I got another one, pawns can move diagonally When capturing, it's a whole new strategy I got a new piece, it's called the ghost It can move through pieces, it's a game host

Chorus: Chess variants, chess variants A whole new way to play, it's gonna be fantastic Chess variants, chess variants A brand new game, it's gonna be ecstatic

Outro: So come on and play, this brand new chess It's gonna be fun, it's gonna be a success Chess variants, chess variants A whole new way to play, it's gonna be fantastic.

I ran the test again with the value of the Cannon set to 500/400 (midgame/endgame), Nightrider still set to 500.  This time the Nightriders won 41, the Cannons won 8, and there were 51 draws.  So this increased the cannon's win percentage slightly and the number of draws dramatically but not the overall outcome.  Given this, I think we can safely conclude that the Nightrider is worth than the Cannon, meaning the results of my first test were more accurate.  That test had a 76% win percentage for the Nightrider, which is very close to H.G.'s result of 78.6%.

As an aside, here are the Betza mobility scores of the pieces:
Equus Rex 12.60
Queen 15.91
Marshall (RN) 14.77
Paladin (BN) 12.65
Nightrider 9.87
Rook* 9.01

* The cannon will be somewhat less than this, but I cannot calculate it.  I also cannot calculate the Cavalier presently.

I would think that Nightriders are stronger than Cannons, but certainly worth testing. I'll set ChessV up to test this out overnight.

In my opinion Zillions is completely out when estimating the value of the Cannon, and other hoppers

Zillions is out, period.  Even in standard Chess, it thinks a Queen is worth less than Rook+Bishop when we know it's worth more.  Its evaluations should be given no consideration whatsoever.

j2j7 doesn't seem all that decisive. ChessV does like to respond to it likewise (a9a4), but other responses seem OK. I tried a black response if f8e6, then let ChessV compute on this for 15 minutes, reaching a search depth of 23. It responds with j7b7, threatening the Marshall, and thinks white has an 1/8th pawn advantage. So there may be some advantage, and certainly some harassment potential, but it doesn't seem too bad.

BTW, I consider the khaki/smoke theme presented in Fergus' latest posting excellent

I do think these are aesthetically pleasing.  If there are no objections then they are fine with me.

But we should be aware that the technical possibility exists to use different defaults in both cases. And that this might make sense. After all, we also print the comments on different background color as the articles.

I think this makes sense.  Making the khaki colors the defult only for comments seems like a good idea.

I object to the lack of process.

I will restate again, we have colors we have used for a very long time.  They are not what I would choose, personally, but they have worked:

It's possible that these colors are what nobody still here would specifically choose, but they could still be a reasonable compromise.  If we are going to make a change, then we need a DEFINED PROCESS.  If we need a change, why, what are the criteria, and how are they to be judged?  This is a long established forum, the results of which are the results of the free contributions of hundreds of people.  Given that, we cannot make such sweeping changes just because one editor wants to.

I will anticipate the response: these changes are forward-only changes and have no effect on the existing content.  Ok, while there is truth to that, the argument is insufficient.  The only reason this forum has any value, (the only reason people are reading it), is because of the established content.  And it only continues because a community drives it forwards.  Almost no one would be here if it wasn't for our foundation.  We stand on the shoulders of giants.

So any posting of new default color schemes is completely inappropriate without first establishing a DEFINITION OF PROBLEM to be solved and a PROCESS for how changes are to be submitted and results are to be measured.

I'm considering changing the comment background color to #FFFFF0 to match the ivory page background color. This would make it easier to use darkkhaki and beige for the diagram colors, since in my mobile tests, darkkhaki contrasts better with the pieces than olive or olivedrab do.

Is this really necessary?  We need to change the color scheme of comments just to get the color scheme you've decided we should have for board diagrams?  I think it would be appropriate to get some community feedback on what colors are desired before we start making far-reaching changes.  I've heard nothing on why the standard board colors we've been using for 15+ years are no longer acceptable.  And, if it's decided they should change, then we should vote on a replacement.

;filter:url(#filter855)

Very interesting.  This is similar to the code that was injected into the Chancellor that Jean-Louis reported that I can't explain.  Perhaps we should just search the text for "filter:url" and get rid of all of that.  Absolutely nothing I have done should involve hitting the web to load any filters.  AFAIK my images should be nothing but local layers, paths and polygons.

Okay, I got the left and right x coordinates for the triangle's base and used these to match the lower base to it.

Try InkScape.  No reason to hack the SVG text directly if that's what you are doing.

I have converted 23 pieces from the Abstract Piece Set to SVG and placed them in /graphics.dir/abstractSVG.  They should be extremely close to the originals.  The geometric nature of them made it fairly easy to match most of them up exactly.

Nice! Not high urgency, but it's nice to see the original pieces getting a renovation.

I still don't see what was wrong with the square colors used by Zied's Board Painter

These are ok.  Not crazy about it, but I can live with it.

The first one proposed by Fergus also seemed to have good contrast

This is nice except that the light squares are exactly the same as the comment background, so they disappear into it, so it should have a border color.

And as long as we are volunteering suggestions, this is what I use as the default in ChessV:

I have made auto-alferie-svg the default set. This is a new set I created today.

Thank you.  I'm pleased to see the alfaerie set as default, since it is the most complete and most recognizable.  What is 'auto-alferie-svg'?  This doesn't seem to be a GC piece set.  I'd like to see an index.

While this set should have as many pieces as alfaeriePNG35, alfaerie-many has more than both, as several alfaerie pieces have not been converted to SVG yet.

For sure.  There are dozens, possibly hundreds, of pieces that haven't been converted.  Some are obscure, some have unknown purpose, and some just look terrible.  I'd like to expand the set in a controlled manner.  And there are even a few that have been converted that I'm not happy with.  There are also a few more that are done and still need to be added.  I have a few days off so I'll try to get a handle on this.

A lot is happening recently.  Very happy to see it!  Happy New Year, everyone!

Why only the number of columns can be entered and not the number of rows?

Because it will keep making new rows until it reaches the end of the FEN.

Drawing the board at a larger size and displaying it at a reduced size does eliminate any problems caused by zooming

Excellent.  I'm glad we've agreed that there is an issue and that we have ways to address it.  Thank you.

I think it would be good to have SVG images of other piece sets

Indeed.  I've made SVGs for probably a couple dozen of the Abstract set pieces over the last year or two.  Unfortunately I can't upload them right now.  The power cut out last night and since it's come back my file server has not wanted to turn on.  Hopefully that won't be too hard to resolve and I have backups if need be.

The comparison was about how they each appeared at normal size

Are you serious?  You already said you "could not detect much difference through visual comparison".  And Jean-Louis, H.G., and I have already responded.  Regardless of how they appear at normal size, there is a difference if you operate your browser with a zoom, which many people do, INCLUDING YOU.  And, for about the tenth time, you still have not acknowledged this. 

Now you have resorted to making up "expirements" that I guess are supposed to demonstrate something.  I am at a loss for any reasonable hypothesis why you're so desperate to ignore the actual issue and invent others, but it really doesn't matter.  Since it's painfully obvious to me that you are just being intellectually dishonest, I see no reason to continue the debate.

I could not detect much difference through visual comparison

Did you zoom way in?  If so, I can't see how you could miss it.  It is literally the difference between these:

I took screenshots and replaced the original piece and space colors with the same color

I'm not sure what this is supposed to indicate, beyond the fact that they are different, but there are issues with your test.  First, on #1 you have already corrupted the original output by going from SVG to PNG (vector to raster).  Secondly, you didn't replace the original piece colors on #3..  I inspected the white pixels to verify that they are FFFFFF, so something went wrong with your expirement.  And I still see dark pieces on #2, so probably something went wrong there too.

Sabotage is a loaded and totally inappropriate word to use here. It's like a font designer saying that displaying his font in boldface is sabotage.

Absolute rubbish.  It is nothing like that.  You are changing a smooth transition into a blocky transition, a very obvious phenomenon that you have avoided acknowledging.  Reduce your zoom to the default 100% and it will be quite obvious that the originals are smooth and yours are jagged.  But I don't expect you to acknowledge this.  This coversation has gone on long enough that I am reaching the conclusion that you are just being disingenuous.  You have been very particular about how your graphics are to be used.  It would be nice if you'd give others the same respect.

You should just render the entire image twice (or 5 times) the size you want it, and use the width and height attributes on its image tags to scale it back to the size that was requested

Yes, this is what I was suggesting.  Have diagram designer render everything double.  Have the square size be 100x100, the pieces be 100x100, the border be double.  Then scale the final image back down.

I updated your HTML to use IMG tags, but your images are still not showing up. Check that your URLs are correct.

They show up for me

The images you posted didn't come through, but I looked on Safari on an iPhone and I see it but I cannot explain it. As far as I know, that image is no different than any of the others. Very strange

I believe you had a script for rendering the entire set of SVG pieces as PNG.

Indeed I do.  Although it needs to be updated for new pieces ...  You've added some and I have added a few too that I will need to email you to put on your server.  Let me go through and find out what they are.  It's been a while.  I know I did the Rose but I don't remember what the other couple were.

I was thinking of trying some very wide boards, like 8x20 or 8x24, which would fit the 192 squares limit. Is the reason for the 16 file and rank limit that larger dimensions might be more difficult to display clearly?

No, this was not the primary reason.  It has to do with the size of various pre-allocated arrays.  I don't actually remember the implications of more files very clearly ... it might not be that bad.  I will take a look.  Exceeding 192 squares would be far more costly.

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.

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.

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.

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.)

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).

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?

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.

Well, I think he meant that during your own turn enemy Jokers have no move (so that you can never move into their check), but that whether they deliver check should be judged in the opponent's turn (after he released the piece, but before he pressed the clock, as it were).

This does not make sense to me.  It sounds good but does not really clarify anything for me.  It might be helpful to discuss an actual situation.  In this position, black has just moved his King into the corner:

So now white's Joker moves as a King and moves to b2:

Is black's King in check or not?  If not, then that's a stalemate.  I do not think saying "whether they deliver check should be judged in the opponent's turn (after he released the piece, but before he pressed the clock, as it were)" changes anything.  Any move the black King makes, it will then be judged that he is in check, so that move is illegal.  Any move the black King makes is illegal, so the game is over.  Whether it is checkmate or stalemate is determined by whether the King is in check.  Am I missing something?

Oh, now I understand. After white has moved the white joker has no move as it is it's default. Check should be checked only immediately after the enemy moved.

Ah!  But now we're right back to exactly how ChessV is implemented now!  Where KJK is a draw, not a win...  If the Joker doesn't check the enemy, how can King+Joker possibly checkmate?

in KJK the joker should unambiguously move as a king

Sure - there is nothing else so this is a pretty easy case.

so if white has moved a queen then it's black's turn and the black joker has queen powers for the purpose of checking

This is not the question.  The question is, after white moves a Queen, how does white's Joker move for the purposes of determing if black's King is in check (or moves through check while castling).  Does it also move as a Queen, or does it move as whatever piece black last moved?

I'm not sure why the rest isn't just an implementation problem.

There is obviously an implementation issue, but there may also be conceptual issues.  We have run into lots of questions, have we not?  And, years later, we are still not sure.  H.G. seems to think we can eliminate all ambiguity with careful definition.  And he might be right; I'm not so sure.

Thanks a lot guys for taking the time to do this for me

You're welcome.  But this is the kind of thing that we like thinking about, which is probably why we have both been working on universal chess programs for decades now :)

That might technically work, but I do not see any positive in hijacking the e.p. square in this way. The ep square is used by the code handling en passant - it won't and shouldn't know anything about imitators. Sure, I could program the en passant rule to just ignore values that don't seem appropriate, but that is just a hack and hacks don't lead to long term code understandably or maintainability. And, as you note, this wouldn't even work with the scenario where different colored Jokers move differently.

Some games just need additional state information to be stored - there's no way around it. For example, Carlos Cetina's Symmetric Chess needs to store the Bishop Conversion Rule properties. I don't think you will come up with a clever way to sneak that information into existing FEN structure. (This reminds me, I need to post on that page exactly how I've extended FEN to accommodate this. Been meaning to do that for a long time now.)

But I do agree that both Jokers having the same move is conceptually simpler and therefore preferable.

Ooo... Something else I didn't consider. Games with Jokers need to amend the FEN format. The FEN will need to store what type(s) are currently being imitated.

It can still be freely chosen whether the Joker would mimic the last-moved piece of the opponent, or the last-moved piece period. The rules could have been such that the black Knight move switches both Jokers to Knights, instead of just the black one. This is just a different kind of imitator.

Hmmm... The second option would be slightly easier to implement because it's closer to how it is currently written.  It also might be easier to understand -- maybe.  But I have no strong opinion either way.

Most of this makes sense.  I'm not entirely sure -- the thread on talkchess was so long ago I don't really remember, but people much smarter than I argued the point -- but I don't really care either.  I consider the Joker itself a bad idea, so I don't care exactly how it acts so long as I can implement it without making any significant changes to the architecture of the program itself.  And I think that is doable...  It makes the implemention of the ImmitatorRule a bit more complicated because it needs to track how each side's Jokers move individually, but that shouldn't be a big deal.  I think attack detection should also be ok.

Aurelian, are you in agreement that this is how it should work?  To be clear, let's make sure I understand...  White moves a Queen.  Then black moves a Knight.  It is now white's turn again.  At this instant, for purposes of determining if the white King is in check, black's Joker still moves as a Queen.  White decides to move a Bishop.  At this moment, for purposes of deciding if white's King is in check, black's Joker moves as a Bishop.  If white's King is not in check, it is black's move again.  At this instant, for purposes of determining if black's King is in check, white's Joker moves as a Knight.

with a lame Dababba (nD) on d1, could you play O-O? I would say 'no', because after the King steps to f1, the nD could capture it. But with the King still on e1 the nD cannot capture to f1.

Now this is an interesting question.  I'm inclined to agree ... castling should not be allowed because the lame Dababba could theoretically capture the King as it moves through.  That said, that is probably not how ChessV works at present.  I guess the truly correct way to do it is to move the King to each square in sequence and ask "am I in check" at each step.  But that's expensive.  It would probably be adequate just to lift the King off the board before doing the attack detection on the squares.

"null move" is not no moves. A null move is a player passing a turn without moving. This is not legal in Chess, but chess programs do it anyway as a way to cut out part of the search tree.

https://www.chessprogramming.org/Null_Move_Pruning

From what I understand a stalemated king passes nothing to the joker. Am I correct?

I'm sorry, I do not understand what you are asking.  When a King is stalemated, the game is over.

I don't think this is the most natural interpretation of the Joker. I would opt for rules where the Joker keeps mimicking the previously moved piece after null move (just as it would after opponent Joker move).

There was a very long discussion about this on talkchess and another discussion here.  The way I've programmed it was the concensus at the time, and for good reasons.  I could change it, but I think you would like the results of that even less.  It would forbid a lot of King moves.  (The problem goes way beyond castling through check.)  A King cannot move to any square that is attacked -- if the Joker still has its previous powers, it is potentially attacking a lot of squares and stopping the King from moving to them, despite the fact that if he did, the Joker would no longer be able to capture him because its powers have changed.  Whether or not the Joker could actually capture the King on the next move is irrelevant.  At the time of the King's move, the Joker either still has its powers or it doesn't.  You can't have it both ways.

After some more consideration I would prefer the "null move doesn't change imitation" over "null move = King move" rule. Because then it would not matter whether you define check by a second move in the same turn, or as a move after a hypothetical null move. I am afraid the concept of a null move is only natural to engine programmers.

The Joker having the powers of the King when the other side is on the move is at least logically consistent.  I don't like it, but then again, I don't like the Joker.  Also, I don't understand why you are mentioning null move.  I'm not sure what that has to do with anything.

I do not think I have expressed myself well about the joker. The K and J do manage to force the enemy king to the corner, but then it is not doing the obvious checkmating move.

Ok, I have done some testing and we were looking in the wrong place.  The reason it does not do the obvious checkmating move is because that move is not checkmate, it is stalemate.  Until that point, the computer thinks it is ahead by one Joker.  It doesn't want to trap the King in the corner with the Joker because that ends the game in a draw.

Per an earlier discussion, the Joker only has movement capabilities when its side is on the move.  When the other side is on the move, the Joker has no movements at all.  So the King in the corner cannot move, because then the Joker would be checking it.  But the King is not actually in check before it moves.  It has no legal move, so it is a stalemate.  I had not considered this situation before.  But, under the current rules, King+Joker vs. King is a draw.

Can't major or minor be a user defined property of a piece?

Sure, it could.  But is that the right thing to do?

Perhaps any non-pawn (or any piece that doesn't promote) should activate the KxK endgame evaluation.  When active, the evaluation is determined 100% by (a) material, (b) how close the weak king is to the corner, and (c) how close the two kings are together.  All other considerations are switched off.  Maybe this should apply for King+Minor vs. King also?  In which case the distinction doesn't matter.

@H. G., any thoughts on this?

There is an evaluation function called LowMaterialEvaluation that does a few things. It will immediately terminate the game if we are down to KNK, KBK, KNNK, and even KBBK if both Bishops are on the same color.

It will return a flat evaluation of zero for KBKB, KBKN, and KNKN but won't terminate the game. It also has a setting called KRKIsDraw that, when set, will return zero if down to KRK (for Cylindrical Chess and Omega Chess), but doesn't terminate the game (although perhaps it should.)

It will also perform specialized evaluation for KRKP, KRKB, and KRKN so that it can win those. And there is a KxK function (where x is Rook or other piece with an endgame value of 500 or more) which returns an evaluation based on how close the losing king is to the corner plus how close the two kings are together.

Basically, it assumes a piece can mate the enemy king if it has an endgame value over 500 and switches to specialized evaluation. If it's not over 500, it will not terminate the game except in those special circumstances dictated by the rules of chess. Perhaps it should for situations like King + Camel vs King. It could decide this if the last piece is colorbound I suppose.

In all other circumstances, the standard game evaluation function applies. So for King+Joker against King, I am not surprised it does not know how to win. Perhaps I should activate KxK evaluation for any x that doesn't promote... And perhaps I should activate it for multiple non-promoting pieces against a lone King. Certainly there is more work to be done here. I have wanted to make a specialized KPK function for a long time. Knowing how to win when down to only a couple of pieces is tricky business in Chess and obviously harder in a universal chess program where your pieces can be anything...

EDIT: There are also a couple of games where I turn off the LowMaterialEvaluation completely because it would not do "the right thing" (for example, Knightmate).

Ok, that makes the implementation cleaner. Do you want me to change the two original games? Right now they are not allowing the Joker a pawn double-move. And if a Joker makes a double move when emulating a pawn, should it be possible to capture it en passant? (This is easy - just add Joker to the EnPassantRule.VictimTypes). But a Joker cannot capture a pawn that has just double-moved en passant.

The Joker piece will normally emulate all the movements of other pieces that are handled by the internal move generator, but not movements that are enabled by Rules (en passant, castling). The pawn's double move is handled by the internal move generator so it does get emulated. I knew you didn't what that, so in the two built-in Apothecary variants I added a hack to prevent it. Unfortunately, that hack will not work with the scripting language. If the boards are the same for your new variants, you could probably derive them from 'Apothecary Chess Classic' or 'Apothecary Chess Modern' and they will inherit the hack. Otherwise I will need to give this more consideration...

How about letting someone drag a piece around the board to see how it can move from different locations?

This does not seem like a good solution to me.  They would need to know to do that (most pieces in most games don't move in different ways from different spaces) and dragging the piece around willy-nilly to see what happens doesn't seem very efficient.  A note saying "the King cannot cross the river" would be the efficient way to communicate this.  It isn't really possible for move diagrams to show the nuances of special rules.  In Elk Chess, for example, the Elk moves like a Rook on light squares and a Knight on dark squares.  Expecting the user to drag the piece around until he notices the pattern would not be reasonable.  The diagrams give a quick overview of how the peices move, but to understand all the details, you still need to read the rules.

Sure, there's a subjective element to it, and I'm not actually arguing that [2,1] is better than N (I don't, that was just an example to explain how the notation works.)

The fact that it is less compact is almost meaningless to me. Easy to understand and easy to parse and implement is what I consider important. These long moves are very rare. No need to be cryptic to save a character or two. I also consider NN to be unnecessarily bad and I don't support it either. I use N0, which Betza also suggests.

That's right. I consider the X and Y thing bad design which I argued against. You can make longer jumps with [x,y] notation. These are automatically mirrored so either [1,2] or [2,1] is exactly equivalent to N. And you probably know this, but for the benefit of other readers, there is an XBetza expression tester under the tools menu so you can test expressions and make sure it is interpreting it the way you want.