Comments/Ratings for a Single Item

How do I specify 2 promotable types in with the script language?

You can add additional promotion rules for other promotable types.  You aren't limited to one.  So for the Maasai:

AddRule( BasicPromotionRule( Maasai, { Queen, Eagle, Lion, Sorceress, Duchess, Rhinoceros, Buffalo }, { location: location.Rank = 11 } ) );

How do I enter the pawn double move for the maasai pawn?

The simple way to do this is with XBetza.  Don't specify an internal type and set it's move with XBetza like this:

AddPieceType( "Maasai", "M", 200, 200, "Sergeant" );
Maasai.XBetza = "msWcfFmfR2";

In this example, Sergeant specifies the preferred graphic to use.  Also, under the Tools menu, there is an XBetza Expression Tester so you can make sure your XBetza is supported.  (ChessV does not support everything.)

For a more complicated example, lets say the double move is only supported on the second rank.  Then you have to use PieceType.AddMoveCapability, which takes a MoveCapability object, who's constructor looks like this:

MoveCapability( Direction dir, int maxSteps = 9999, int minSteps = 1, bool canCapture = true, bool mustCapture = false )

So you would have something like:

FancyPawn.AddMoveCapability( MoveCapability( <1, 0>, 2, 2, false ) ).Condition = { location: location.Rank == 1 };

The maxSteps is 2.  The minSteps is also 2 because the single step would already be generated by the regular move capability that is applicable everywhere.  canCapture is false, and mustCapture is left as the default (false).  Then we set the Condition under which the move is available, which is a lambda function taking a location as a parameter and returning a bool.  (location.Rank == 1 because, like all good programmers, we start counting at 0.)

For a good example of a game that does everything manually, look at the include file for Duke of Rutlands chess.

Why are the rank and files reversed when you define a move with steponly

Let me look into this.  The file offset should always come first.

Thanks, I made it work!

Why are the rank and files reversed when you define a move with steponly

You're right, the rank & file offsets are backwards when you use the <1, 2> notation.  I will have to fix this.  The file offset should come first.  For now, so that I don't break your code, instead of using the <1, 2> abbreviation, you can construct the Direction normally: Direction( 1, 2 ).  This calls the constructor directly and it takes the file offset first.

Thank you for pointing this out!

You are welcome!

I have stumbled on another hurdle, Greg. I need to not have more than a Joker on the board. So that means no promotion to joker unless my joker has been captured. I figured out I have to use PromoteByReplacementRule but I can't get my head around the second argument. Can you help, please?

No problem. Use the promotion rule as normal - always allow promotion to Joker. Then, there is another rule you can use to limit the number of pieces of a given type on the board. LimitPieceTypeQuantityRule( PieceType, maxCount ). So:

AddRule( LimitPieceTypeQuantityRule( Joker, 1 ) );

Ok, Thanks!

There is probably a bug with that instruction. I have sent you an email as the error message is very long!

I feel that this rule interacts badly with the joker. I have not seen other joker bugs, as of now!

Later edit. I have tried limiting the rooks to 2. There is the same error.

You're right, this rule is broken :(

I'll need to get that fixed.

Please let me know when you solve this, as I'm using ChessV for designing my games (not the intended purpose I guess, but ChessV is very general).

Helping to test game design is certainly an intended purpose. But do you need a new build just to correct this one issue? For test purposes, I wouldn't think allowing 2 jokers or not allowing promotion to joker at all would change very much.

Indeed.

But also from some point ahead, I prefer the correct rules. Anyway, for the purpose of measuring the piece values , I do not use the joker as it introduces many instabilities. By the way, in the few games I,be noticed so far there are no joker related bugs. But I do not know if I can suppress the special pawn powers when imitating a pawn. Also chessV does not use the move by move recalculation of the joker value. And these things are difficult to do. Partly this is why I'm trying my hand, at my own program !

So, the games I'm creating are 10x10 and the castling type is 2R-standard (it is correctly assigned this is not the problem). The ai is quick to move to the back rank most of the time for no reason before castling, and sometimes (rarely) after castling seemingly for no reason. In the latter case I can be totally wrong though. Anyway, how do I disable this tendency of the general 10x10 ai? Would you recommend I inherit from a more general class or general 10x10 is fine?

The piece-square-tables do encourage the king to retreat to the first row. You can see the PSTs by right-clicking on the piece, selecting Properties, and then look at the Midgame or Endgame PST tab.

We can eliminate that desire by zeroing the "forwardness" midgame PST component (which is negative for the king.)  In your AddPieceTypes function:

King.PSTMidgameForwardness = 0;

See if that helps.  There can be other factors as well, like the deveopment evaluation and king safety evaluation, although the development evaluation should be encouraging it to castle.

In variants where there is more than one rank behind the Pawns, and many strong pieces, castling directly behind the Pawns is often a very bad move. In general one could say that in such variants the castling rule is only added out of conservatism, but is as useless as adding a rule that at any time you can permanently remove your Queen from the board instead of making a normal move. No one in his right mind would ever do it. Even in the central files, a King on the back rank sheltering behind by a wall of Pawns plus a wall of pieces is usually a lot safer than a King directly behind the Pawns.

So the first issue to consider is whether it is really a good idea to force an engine to make poor moves just because the rules allow those. That being said, if it is really such that castling is good, the usual way is to discourage moving an uncastled King not by Piece-Square Tables, but by giving a hefty bonus for the possession of castling rights. (Which should reflect the PST and other positional score the King would get in the castled position. If they were higher the engine would never castle, because he would think it more important to preserve the rights to do so.) In KingSlayer I always evaluate the quality of the Pawn shield in the castled locations, and derive the value of each castling right from that. These are then devaluated a little depending on the number of pieces that still block the castling. And the total value of the rights is that of the best right plus a factor smaller than one times the other.

@Greg&@HG, Now there is the trouble that the ai moves the pawns ahead of the possible location of the castling king, or ahead of the castled king, again quite arbitrary. There is only one heavy piece besides the queen in the games I mention (between the value of the rook and of the queen) so deadly back rank incursion from the enemy don't seem the desirable. But there are 26 pieces /side, and some pawns need to move to bring some air into the position. So maybe some penalty from leaving pawns on one side OR the other side is welcome. This as it is needed to move some flank pawns in order to develope quickly. I agree with HG, KingSlayer approach. Maybe you can customize all of that, Greg.

There is one more issue. With a 10 files board one needs to get out three pieces before castling. In the games I had mentioned there are the bishops by the queen and king and 2 leapers. Then there are the rooks. On the other side there is also the queen. The fact that you have to take out 3 pieces hinders castling a bit. I was thinking about a "Bishop jumping rule during castling". This means the castling king may jump the bishop when castling but not to other pieces. Would this be a good idea. What do you guys think?

I would not introduce yet another form of castling. How about Kevin's 'fast castling' rule?

But normally getting out 3 pieces should not be a problem. Of course it depends on whether these pieces can jump, or otherwise get out without destroying the Pawn shield. If they had to compromise the Pawn shield (e.g. like starting a Commoner on the Knight squares of the FIDE setup) that would just count as bad design. (In the Daring Dragons army of CWdA I gave the Dragoon an initial Knight jump for that reason.)

In a Grand-Chess like setup with enough empty space on the back rank there would not be a problem to clear the 2nd rank for castling; one can just retract the pieces to the back rank.

In the KingSlayer approach moving the pieces out of the castling path is encouraged, because it makes the castling right in that direction more valuable (less discounted). And the castling right with the highest weight (because it is the best of the two) would be preferred, because it contributes most to the total. So it encourages clearing one path completely before clearing the other partially (other factors such as quality of the Pawn shield being the same). This usually leads to quick clearing of one castling path. But if the other castling is still possible, it would not immediately castle, because having a second right (even when weighted less than the best right) is worth slightly more than the difference between having the right and being in the castled position. Which is what you want: keeping the opponent in the dark as long as possible so that he doesn't know what wing to aim his pieces at during development is usually a good strategy.

Of course the quality of the Pawn shield (which also takes account of enemy Pawns, such as half-open files directed at the shield, or an approaching Pawn storm) remains part of the evaluation even after castling. (But then of course only the one in the direction you actually castled.) This prevents the engine from destroying its own Pawn shield later, while it 'liberates' the Pawns on the other wing.

All this is pretty cheap, as the shield qualities are part of the Pawn-Structure evaluation, which is rarely done, because it is stored in a Pawn hash table that has a very high hit rate. The K-side and Q-side shield qualities are just two items in the Pawn hash entry. (Together with info about half-open files, passers, edge Pawns etc.) And you can stop calculating them once all castling rights are gone, which is usually pretty early in the game.

I'm not sure if I have the current build. But I'd like the following features for batch mode. 1.Add an adjudication coefficient with a default of say 10 pawns. 2.In the save file add the end add the total score.

And a final thing which is rather hard. But if you can please add the customizable value for the joker. HG has proposed the ratio of the sum of squares of the piece value with the piece values. I think some coefficients are good to be in place. Something like (a1p1^2+a2p2^2+...+anpn^2)/(b1p1+b2p2+...+bnpn). where n is the number of piece types and a1,...,an and b1,...,bn are float coefficients. One utility of the coefficients is when imitating a colourbound piece as the joker is not actually colourbound. I know this takes time, so if you can... Good luck Greg!

That being said, if it is really such that castling is good, the usual way is to discourage moving an uncastled King not by Piece-Square Tables, but by giving a hefty bonus for the possession of castling rights.

This is already part of the development evaluation.  And the quality of the pawn shield is part of the king safety evaluation.  If it's not castling, it is probably because, as you say, it is not a good idea.  While the evaluation function cannot be perfect, ChessV does know what it's doing.

And a final thing which is rather hard. But if you can please add the customizable value for the joker.

I don't know about this.  The value of the piece itself cannot directly change, but it would be possible to add a new evaluation function that makes an adjustment to the final score based on the relative values of the joker(s).  I will give it some consideration.

I'm not sure if I have the current build.

The latest is what I recently posted on the Avatar Chess page.

Add an adjudication coefficient with a default of say 10 pawns

This would definitely be useful

In the save file add the end add the total score

You mean at the end of the tournament, list the total win counts?

Yes, at the end of the tournament list may you place something like: playerfoo:51 playerbar:49

Thanks for taking the joker evaluation into account in your own time!

With the:

King.PSTMidgameForwardness = 0;

instruction applied I have watched 4 games at 2 mins + 7 seconds. Only once in 8 cases the ai has not castled choosing a back rank diagonal move (so there is something about it.). Once there was the opposite sides castle going on. I am not sure exactly how to do it but the above-mentioned instruction definitely makes things more castlely.

I think I figured out why the pawns move so quickly in the opening. It is the promotion rule. Now one can promote even at rank 7 (out of 10). So pawn pushes are more tempting. I do not know if it is the correct strategy. I'll play the opening myself, to see what is going on!

How do I delete a color scheme?

I have downloaded the latest build and, in the game anonymous, there is an inaccuracy in the definition of the butterfly.

The correct definition should be that:

    AddPieceType( "Butterfly", "H", 800, 800, "Butterfly" );
        Butterfly.Step( <2, 2> ).SlideAfterStep( <1, 0> );
        Butterfly.Step( <2, 2> ).SlideAfterStep( <0, 1> ).MinSteps = 2;
        Butterfly.Step( <-2, 2> ).SlideAfterStep( <-1, 0> );
        Butterfly.Step( <-2, 2> ).SlideAfterStep( <0, 1> ).MinSteps = 2;
        Butterfly.Step( <2, -2> ).SlideAfterStep( <1, 0> );
        Butterfly.Step( <2, -2> ).SlideAfterStep( <0, -1> ).MinSteps = 2;
        Butterfly.Step( <-2, -2> ).SlideAfterStep( <-1, 0> );
        Butterfly.Step( <-2, -2> ).SlideAfterStep( <0, -1> ).MinSteps = 2;

@ Greg,

1. Is there a possibility to have a time handicap against the computer?
2. Is there a possibility of defining a color scheme with the script editor?

How do I delete a color scheme?

I guess I should add an option for that.  Presently, you'd need to remove it from the registry...   Run Registry Editor, go to  Computer > HKEY_CURRENT_USER > Software > ChessV > Color Schemes.  Then delete the key for the scheme you want to delete.

Is there a possibility to have a time handicap against the computer?

Probably.  I'm dreading doing any modifications to that dialog box - it was tricky getting it to look and work correctly.  Maybe I'll add the ability to change the clocks from within the came.

Is there a possibility of defining a color scheme with the script editor?

Sort of.  You can set custom colors for a game but it won't be saved as a named scheme that you can apply to other games unless you save it.  The include file for Palace Ninja Guards sets the square and border colors.  You can also set Player1Color and Player2Color in the same way.  NOTE: This is only setting the defaults for a game.  Any game you have already played already has your color choices saved in the registry so this won't change anything.  But you can delete the registry key for the game if you want and then it will reset to the defaults specified in your include file next time you open the game.  Computer > HKEY_CURRENT_USER > Software > ChessV > Games.

Thanks, Greg!

@Greg,

And another thing I discovered about the value of the joker. It matters also how many pieces the opponent has. Imagine on a 10x10 board (where I had measured that the chancellor and gryphon are equal, and also it is known that the RN and the BWN are also equal) and endgame with king, joker, gryphon, chancellor and the BNW against king, joker and 3 chancellors. The side with the more diverse pieces has an advantage. There is a lot of consideration to be put into this I'm afraid. Good luck!

I wouldn't get your hopes up for anything that sophisticated. It will be basic, whenever I get to it. The Joker is not something I am interested in spending a lot of time on.

Ok, thanks!

Hello Greg! Have you had time to include the features I asked about a few weeks ago?

@Greg, Please notice my previous comment!

I don't have anything to release at this time

Ok! Thanks for everything!

@Greg,

I'd like to make chessV play custom variants against another chessV copy where the small parameter would yield different results. May you write a small guide on how to do that?

Unfortunately, there is no way to do this at present. ChessV can be used to test changes to its parameters by playing against another engine, but as far as I know there are no other engines capable of playing your games. You certainly could run two instances of ChessV but they won't talk to each other.

I need to separate the game representation used in thinking from the one in the GUI. This would not only allow testing of different parameters but would also make multi-threaded thinking possible.

Ok, Thanks

This is a technical follow-up to recent discussion in other threads.  Overview: there are cases where whether a move is legal depends on what other moves are available.  These follow the general pattern where a certain class of moves are only legal if there is nothing else that is legal, in which case this class of moves all become legal.

I originally raised this in response to the Golem Chess rule that "a Golem or Half-Golem may not capture an opposing Golem or Half-Golem if the opposing Golem or Half-Golem is two squares away and defended by a piece on its own side" ... UNLESS there is no other legal move.  I then realised this was similar to the Losing/Giveaway Chess rule that non-capturing moves are only legal if there are no captures.  We discussed a plan for implementation, which I have started implementing.  While doing this, I found a place in ChessV where I had already encountered this problem and "hacked" it in a less general way and forgot about it ...  That is the Jumping Chess rule that if there is a piece on an edge square that can make a capture, the player must make one of those moves (their choice) but nothing else is legal.  Having come up with these three cases already, I must assume there are more.  So, on to how these can be solved in a universal chess engine ...

Typically, moves are either legal or not.  It is true that a move generator generates so-called "pseduo-legal" moves they might turn out not to be legal when made (if, for example, they expose your King to check or leave him in check.)  But when these pseudo-legal moves that are not really legal are actually made, it is detected that they aren't actually legal and they are skipped.  Details of how this happens varies but it doesn't really matter.  This is simple and doesn't depend on any other moves.  ChessV handles it like this: whenever a move is made, a MoveBeingMade message is routed to every Rule in the Game that receives that message.  The rule can then return an IllegalMove result code to rule the move illegal.  Besides exposing your King to check, other reasons exist such as a LocationRestrictionRule stopping your King from leaving the castle or your Elephant from crossing the river, or the TradePreventionRule making Lion "iron" by preventing captures after you've captured the opponent's Lion.  (As an irrelevant aside, MoveBeingMade messages are also handled just for the purpose of updating game state - such as the EnPassantRule determing when a pawn push creates the possibility of an en passant capture.)

But now we have pseudo-legal moves who's legality depends on what other legal moves exist.  This presents a new challenge.  The general idea is this: allow the MoveBeingMade function to return a new code, which I originally called IllegalUnlessOnly but am now calling FallbackLegality.  Moves of FallbackLegality are all legal if and only if all pseudo-legal moves are either FallbackLegaltity or IllegalMove.  These moves could be temporarily set aside and tried again later if appropriate, or, if appropriate, a new node could be launched with tail recursion wherein FallbackLegality moves would be accepted.  For purposes of this discussion, the implemention details don't matter.

So now that I'm actually implementing this, of course I've found an issue - which is the reason for this post.  What we have so far is straight-forward ... until we get to Quiescent Search.  I won't define QSeach in detail since I've explained it several times before, and since this conversation is only really of interest to implementers of chess variant engines who should know this anyway.  But in qsearch we only try captures so we don't actually know what all the legal moves are.  For purposes of determining the impact of this issue, a quick revisit of the three known use cases of FallbackLegality:

1. Losing/Giveaway Chess: If a player can make a capture, he must (although he can choose which).  So all moves which are not captures are FallbackLegality.

2. Jumping Chess: If a player can make a capture with a piece that is on a boarder square, he must (although he can choose which).  So all moves which are not captures of a pice on a border square are FallbackLegality.

3. Golem Chess: a Golem or Half-Golem may not capture an opposing Golem or Half-Golem if the opposing Golem or Half-Golem is two squares away and defended unless there is no other legal move.

Impact on qsearch?  For cases 1 and 2, I think there is no impact.  These rules already consider everything that is not a capture to be of FallbackLegality.  Easy peasy.  But #3 is a problem.  Here a capture can be ruled illegal if there is a legal non-capture, which we won't know in quiescent search.  We could generate and test them all, but that would be way, way too expensive.  (Something like 90% of nodes are qsearch nodes.)  So, if we treat this case like 1 and 2 and sweep it under the rug, we can consider a golem capture of the enemy golum legal when it is not.  This could have a dramatic impact on the score.  So I think we should not consider this capture in qsearch, since the circumstances where it would be legal are quite rare.

We could rule out all FallbackLegality moves in qsearch ... That would not affect case #1 at all and it is what we want in case #3, but it would be bad in case #2.  In case #2, we want to do exactly what we normally do - generate all captures and use our normal rules for FallbackLegality.

I think this is solved by adding another Game variable.  As I have variables for things like whether Static Exchange Evaluation should be enabled, I plan to add a Game variable called "ConsiderFallbackLegalityMovesInQSearch" to control whether normal rules for FallbackLegality should be applied in qsearch or if we should just rule all these moves out.  In case #1, the setting wouldn't matter.  In case #2, we would want the setting to be true.  In case #3, we would want the setting to be false. (This will result in an incorrect evaluation on occasion, but qsearch isn't perfect.  This is the lesser of the two evils.)

I think you are making too much of this. For one, QS is never omniscient. The stand-pat assumption that the best non-capture will leave the evaluation approximately as it is, is just an assumption that is often false. There could be forks, or skewers. There could even be mate in one. Minimax turns out to be very resistant to random perturbation of a reasonably small fraction of the scores in the leaves; you must be very unlucky for such a perturbed score to affect the root score and move.

You actually defined different classes of legality, and why stop at three? Generalizing this you could have an arbitrary number of such classes. I would prefer to call these 'priority classes'. You must play a move from the highest non-empty class.

What to do is just a matter of statistics. How are the moves typically distributed over the classes, and how are the moves that typically change the evaluation distributed. In Suicide captures are class 1, small in number, non-captures class 2, large in number. The situation that there would be a class-1 move we do not want to consider in QS, which would outlaw all moves we do want to consider, because these are all class 2, never can occur. Same with Jumping Chess; the unconsidered moves are by definition class 2. Of course QS is still affected, because if there are moves to be considered, there will be no stand pat.

In Golem Chess typically all moves are class 1, and the occasional move that can be class 2 is even rare amongst captures. The logical thing to do, considering these statistics, is assume there will be class-1 moves amongst the non-captures. Unless you have reason to suspect there might be none. You would only be interested in knowing that if you did not find any class-1 captures, and when a lot of captures turned out to be illegal you could suspect that might be true for non-captures as well. (You know from the rules there cannot be any class-2 non-captures in Golem Chess.) Or you could simply know that you are in check, and that this is the reason for the large fraction of illegal moves. Especially if it is a contact check, for which the only legal non-captures can be King moves. But then you would probably extend even in QS, and the problem disappears. Otherwise you assume there will be legal non-captures, and guess their score as the current evaluation, to stand pat. It is what you always do when not in check, and the fact that there was only a capture that was discarded because it wasn't class 1 doesn't do more damage than that there occasionally is a class-1 non-capture that would score far higher than the current evaluation.

Note that the engine is very well capable of determining the distribution of moves over the various priority classes from nodes in the full-width part of the search. In particular you could make it keep track of how often there are no class-1 non-captures in the case there are no class-1 captures, and use that to decide whether to do a class-1 stand pat in QS. If there are more priority classes you would want to know what typically the highest-class non-capture is, given the highest-class capture that is available. If that is lower or equal to that of the highest-class capture, the capture can be searched, and a stand pat of the assumed highest-class non-capture can be tried only if that belongs in the same class.

I think you are making too much of this.

That is a disctinct possibility!  And that's why I wrote out all of that... so you could tell me if I'm on the wrong track, or overlooking the obvious.  I appreciate your time.  And, while I agree with what you've written, I'm not sure it justifies me doing anything differently.

You actually defined different classes of legality, and why stop at three? Generalizing this you could have an arbitrary number of such classes. I would prefer to call these 'priority classes'. You must play a move from the highest non-empty class.

Absolutely.  It did occur to me that one could invent a chess variant where there are even more tiers of legality...  But I'm not aware of any such game.  I've only come up with 3 instances of needing a middle ground between "legal" and "illegal".  I guess one could argue that as long as I'm making the change, I should go all the way and make an expandable hierarchy of legality.  But that seems more complicated and unnecessary.  And if it's not much more complicated, then it should be easy enough to adapt this should the need arise.  (And, while I would like to support as much as I reasonably can, it is not my goal to support anything that may come along.)

In Suicide captures are class 1, small in number, non-captures class 2, large in number. The situation that there would be a class-1 move we do not want to consider in QS, which would outlaw all moves we do want to consider, because these are all class 2, never can occur. Same with Jumping Chess; the unconsidered moves are by definition class 2. Of course QS is still affected, because if there are moves to be considered, there will be no stand pat.

I do not entirely understand this, but I think you are in agreement that "fallback legality" moves should be considered in qsearch in Giveaway and Jumping.

In Golem Chess typically all moves are class 1, and the occasional move that can be class 2 is even rare amongst captures. The logical thing to do, considering these statistics, is assume there will be class-1 moves amongst the non-captures.

I interpret this to mean that you agree that "fallback legality" moves should not be considered in qsearch in Golem Chess.

Note that the engine is very well capable of determining the distribution of moves over the various priority classes from nodes in the full-width part of the search. In particular you could make it keep track of how often there are no class-1 non-captures in the case there are no class-1 captures, and use that to decide whether to do a class-1 stand pat in QS.

Ok ... so if I understand correctly, your are not disputing that qsearch needs to be treated differently in Golem vs. Giveaway, but that, rather than a configurable variable that the programmer must set, the engine can determine this for itself.  Hopefully I got that correctly.  If so, my question is how much extra complication does this involve?  Certainly, I'd rather not add another user-configurable element if it's not necessary.  Heck, even the name of this hypothetical variable, "ConsiderFallbackLegalityMovesInQSearch", makes me a little embarassed.

Let's make sure I've isolated the questions to be decided correctly:

1. Do we need to expand beyond the standard determination of pseudo-legal moves as strictly legal or strictly illegal to account for games that have these types of "illegal unless there's nothing else" type moves?

2. If the answer to #1 is yes, do we just do as I've proposed and add a middle "fallback legality" category or do we go all the way and make a structure for any number of tiers of legality?

3. If the answer to #1 is "yes", regardless of the answer to #2, we have the issue of qsearch.  Do we have programmatic variables to determine what should be considered in qsearch, or do we determine that from statistical analysis?

Do I have this right?  And, if so, what are your answers to these questions?

International Draughts is such a game: not only is capture mandatory, but you must capture the most chips that you can.

In Suicide only non-captures are FallBackLegality, and you never want to consider these in QS. So it is a moot point. (Note, however, that the champion Draughts program Scan does consider moves that invite capture in QS, and considers a position only quiet when there are no such moves, and no captures.) In Jumping there can be captures amongst the FallBackLegality. You must consider those in QS, but only when you actually have to fall back, of course. Always consider the highest non-empty class, and none other.

You have to assign a class to standing pat, to decide whether you can do that, and whether that would be higher class than de highest non-empty class amongst the captures. Usually this can be based on statistics. For Suicide and Jumping stand pat is always FallBackLegality. So no standing pat when there are legal captures. For Golem stand-pat will be legal. So no FallBackLegal captures.

What you want to consider in QS can very well depend on variant. Beside captures one usually considers promotions. In Shogi considering promotions for pieces already in the zone is counterproductive. Promotion is almost a certainty there, and the static eval can assume, say, 90% of the value. Most Chess programs consider non-capture check evasions.

Hello Greg,

How can I add evaluations for the maasai pawn pushes?

How can I add evaluations for the maasai pawn pushes?

You can set the Forwardness Piece-Square-Table componenets.  For the regular Pawn type, it is 7 midgame and 10 endgame.  For user-defined pieces it's 0.  So you can set PSTMidgameForwardness=7 and PSTEndgameForwardness=10 to make it consistent with the Pawn.

You can look at the PSTs in the piece properties.  And you'll need to restart the program after making changes to an include file.  They are parsed at startup.

Thanks, Greg!

Hello Greg,

I have 2 questions:

1. How does the colourbound pieces bonus/penalty work when more pairs of colourbound pieces are involved?
2. Does the endgame value of a piece influence opening exchanges, or is it just the middlegame value?

Hello Greg,

I had 2 questions earlier this month:

1.How does the colourbound pieces bonus/penalty work when more pairs of colourbound pieces are involved?

2.Does the endgame value of a piece influence opening exchanges, or is it just the middlegame value?

You probably missed them.

I have seen that you have programmed beautiful sun chess. Why not Xiangqi also?

How does the colourbound pieces bonus/penalty work when more pairs of colourbound pieces are involved?

The current approach is pretty simple.  First, it only applies to pieces that split the board into two regions.  Pieces with higher-order colorbindings, like Dabbabahs, are not considered for colorbound bonus/penalty at all.  A player is given a half-pawn bonus for having at least one colorbound piece on each "color" (see note below) and given a significant penalty for having two pieces on the same color with nothing on the other.

Note: All pieces with bindings that split the board in two are considered equivalent.  This is not ideal.  It is possible to have two different types of pieces that have two different "color" bindings that are not the same.  This happens in Alice Chess for example.  In Alice, both the Bishops and the Knights can only see half the boards, but they are not the same bindings!  (Any pair of bishop and knight will be on the same squares on one board and on opposite squares on the other.  The current strategy isn't smart enough to account for this.)

Does the endgame value of a piece influence opening exchanges, or is it just the middlegame value?

Endgame value will have no influence.  The evaluation of a position is interpolated between the midgame and endgame values based on the amount of material remaining.  It does not even start sliding from midgame to endgame until 20% of the starting material has been captured.

I have seen that you have programmed beautiful sun chess. Why not Xiangqi also?

The issue with Xiangqi is the very complicated and hard-to-implement repetition/anti-chasing rules.  I'm not even sure I understand them, much less know how to implement them (although I haven't really spent time on it.)

Hello Greg!

I have encountered a very weird bug. It happens when I try to add a piece that has camel or zebra moves to a new fairy piece. Curiously is that when deleting the AddPiece from the Siege elephant or Mamluk the problem goes away and everything is going according to plan. Also adding Giraffe or antelope works fine all the time. The error message is index out of bounds. Any Idea?

Yes, I know what that's about. For efficiency reasons, there is a maximum number of directions that can be used in a game. It was 48 but I have increased it to 72. I'll post an update soon.

I still don't understand why adding antelope or giraffe powers work but zebra or camel do not. Is that because of the Vulture?

Probably. The antelope and giraffe aren't adding any new directions but the camel and zebra are.

I just posted a new build: ChessV 2.3 RC4

This will be the final pre-release build before I officially release version 2.3 by Christmas.  It addresses a number of things you've asked about.

There is a new evaluation for the Joker to make it's value proportional to the average value of the enemy's pieces.  This will not be reflected when looking at the Joker's properties.  The built-in material value can't change but the evaluation will scale them up or down as appropriate.  (Much like the Pawn's properties don't reflect evaluation changes related to pawn structure.)  To use this in a custom game, you'll need to add the evaluation:  AddEvaluation( JokerEvaluation( Joker ) );  (where "Joker" is the name of the piece type to receive the evaluation adjustment.)

You can pause or change the clocks.  This will let you play a game with a time advantage.  Just click in the clock panels when it is your time to move and the clocks will pause and it will give you a dialog box allowing you to resume and/or change the times.  But it must be your turn - clicking on the clock panel when it's the computer's turn won't do anything.

The maximum number of directions has been increased to 72.

The <1, 2> direction notation has been standardized.  Now in all places the file offset comes first and the rank offset second.

Lots of improvements to the scripting language.  Many things have been cleaned up to require less code.  New capabilities have also been added, such as allowing piece shuffling by custom logic which will be mapped to position numbers.  (See the include files for Arktur or Massai for examples.)

There were a couple of breaking changes to the scripting language.  If you email me your include files, I'll update them.  They could use an update anyway.  Looking at the code you posted there is a lot of extraneous stuff.  There is no need to define PieceTypes outside of the game.  Games can define custom types on-the-fly.  And there is no reason to specify all the specific movements except in very unusual circumstances (e.g. Osprey).  In most cases you can just set the XBetza property.

Thank you very much!

Does the joker evaluation include all pieces or all piece types? How are pawn taken into account?

And by the way Greg, I have decided to remove the rule that there shouldn't be more than one joker for a player on the board. It happened once, and in the endgame, when this happens it was not as game breaking as I thought!

All pieces including pawns are taken into account. The midgame adjustment is proportional to the sum of the midgame values of all the opponent's pieces divided by the number of pieces. The endgame adjustment is proportional to the sum of the endgame values of the opponent's pieces divided by the number of pieces. So the Joker winds up being worth about one pawn more than the average piece value.

Thanks! This is so useful!

Just for the record. I have watched twenty engine vs engine games, and there were no crashes, there were no bugs and the games were fun to watch. You deserve all the praise!

I think the X and Y in XBetza are not implemented. For NmAY I actuially get an NmA.

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.

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.

This is more a matter of taste than an objective advantage, though. The [x,y] notation needs at least 5 characters. With that many characters the XY notation can go up to [15,3] (GXXXX) or [11,11] (GYYYY). At which point the [x,y] notation already uses double digits. So the first cases where [x,y] would be more compact are [19,0] and [16,16]. It is extremely unlikey that such large leaps would be encountered in practice. (Perhaps for mapping a dual board or a two-level board on a rectangle, such as for Alice Chess.)

Even if it could be argued that [2,1] is better notation than N, it is just not Betza notation. Using multi-letter atoms for indicating atoms for which no single-letter notation exists has already been done by Betza himself (e.g. NN).

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.

Easy to understand and easy to parse and implement is what I consider important.

Well, parsing the X/Y in the Interactive Diagram was as trivial as it can get. After reading an atom and looking up the (x,y) step and default range, you have to examine the following characters anyway for being a digit that would overrule the range, or duplication to toggle the range 1<->inf. When you encounter an X in that process you just add (3,0) to (x,y) (and (2,2) for an Y), and keep looping until you encounter the digit or something else. Having to test for en entirely new (x,y) syntax would have been far more complex.

Betza notation is intrinsically more difficult to understand than (x,y) notation; you have to remember what all letters mean. If that was an argument you should not use Betza notation at all. And only having to remember that X boosts the leap by 3 steps gives you a lot of extra leaps for just remembering one more letter.

Suffice it to say I disagree with most of that but debating it is not a good use of my time. The time to debate the merits was when this came up, but instead you just did what you wanted.

Really, this is the least of it. Your XBetza has become so insanely complicated that most of it is of no use to me. There is absolutely no chance that I could implement it in a bug-free way, and some of it I don't even understand.

Fortunately, all I need to do is parse those strings that represent moves that ChessV's internal move generator is capable of anyway, and it does that with a clean subset of the grammar.

Guys, I think that both sides of the argument have merit. But it is important to have one standard. Anyway I know how to implement the NmAY in chessV so that is the most important thing. I also don't think that very long leaps will often be used, but the antelope and the giraffe should appear often enough on 12x12-16x16 boards.

Hi Greg,

In the five games I have published the joker imitating a pawn gains only it's regular move power, no double step, no en passant, no promotions. In the games that I am testing now with ChessV the double step is allowed to the joker if on the proper rank. The double step move is implemented as a move of a pawn on the second rank and, not as a first mover property. I'm prepared to change the rule here so that double step is allowed. It is not very important, and anyway it works this way and I have sample games like that. What are your thoughts on the matter so far?

Next, do you foresee any related problems? What scares me is to publish the game with a set of rules and then someone finds an exception or to implement my own program a slightly different game because of that.

I thought it would help if you can provide the code of the joker. But it is not only that it is also how the joker connects with other classes in your design. This is why I ask the broader question.

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

Don't worry about that. I just wanted to know how it works, because of the reasons I have stated earlier. I'll allow the double move from the proper rank.

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.

No, for historical purpose I think they should remain the same.

The rest I'm leaving them as they are no enpassant. Thanks for your help!

Hello Greg, More questions from me I'm afraid. How do I tell the AI that a piece is minor or major? I noticed the ai knows that KBvK is a draw, probably also KNvK too. I do not know about KNNvsK. I am interested in KMvK,vwhere M stands for mamluk(CW).

Oh,

also in the KJvK endgame the AI does not know how to mate. It manages the heard the king to the corner, but then it does not give the final blow.

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

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

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.

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?

Forcing the opponent's last remaining piece into a corner can never hurt. So it should probably be the dominant eval term. Fairy-Max doesn't have true PST; just a centralization bonus, and a weight for each piece type to multiply it. Originally that weight was 0 or 1, configurable by the user. When the King is bared, I now increase it to 10. I don't see any reason to discard other eval terms.

What holds to K-K distance in the bared case should probably hold for all short-range leapers. Removing their centralization drive does not help them seek out the bare King, even though it doesn't obstruct it. In Fairy-Max this was a problem in the KNFFK and KFFFK (Makruk!), where K + two pieces is enough to corner the King (and N + F even enough to trap it there), and then it had no incentive to approach the remaining piece(s), which are needed to execute the checkmate. You would probably see the same in KNNNK, certainly on large boards.

Of course forcing into a corner can backfire if it is the wrong corner (KBNK!). In Fairy-Max I solved this by switching to a centalization bonus that awards driving to another corner once the bare King visits one. The idea is that if there is a mate in the current corner, the search will always be deep enough to see it when the bare King is already trapped there.

With orthodox Kings (and a rectangular board) many pieces can be classified as minors with certainty: if they do not attack two orthogonally adjacent squares. That of course includes color-bounds. But also many more (all elementary obliques, Omega Wizard, Phoenix, Mamluk). Not all pieces that fail this test are majors, though. E.g. Silver or Wildebeest. But is seems a better criterion than piece value; the >500 criterion also gets the Wildebeest, Commoner, Gold and WD wrong. In I once made a Fairy-Max derivative 'Pair-o-Max' where I apply the color-binding and value criterion, but the user can force a piece to be considered a 'weak major'.

Other user-configured end-game properties in Pair-o-Max were 'defective pair' and 'strong defender', which could indicate KxxK or KQKx are draws, respectively.

There is also the reverse case where a heavy minor manticore can't mate!

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.

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

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). But that for implementation of the 'castling through check' rule the partial-move interpretation would be used: would the King be capturable if it only performed the move up to that point? The castling issue is not only relevant to the Joker. E.g. 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.

[Edit] Another interpretation could be that the Joker during the opponent turn it always moves as King (or whatever royal you have). A null move cannot be unambiguously assigned to any piece, but for the definition of check we could use the fiction that the royal must make it, in contexts where it matters what piece was moved.

Of course it is still a matter of taste what the Joker imitates after castling. If we consider castling a 3-step move (K+K+R), it would be most natural if it imitated the Rook.

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

I agree with HG. It makes sense that a joker imitating a king to be a man so KJK is exactly like KMK. 

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.

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 don't understand the null move usage here either. The way I have made the rules, the joker has a null move only at the beginning of the game!

"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

Oh, ok!

The FIDE "laws of Chess" define check in terms of being attacked, and 'attack' in terms of pseudo-legal moves of the pieces. This does not allow for the pseudo-legal moves to change over time, and tacitly assigns the same pseudo-legal moves to a piece whether it is its turn to move or not. So it involves the fiction that the checking side can move, even if it is not his turn. To move out of turn you would either have to do two moves in the same turn, or let the opponent pass his turn between the two moves. This is how the null move enters the discussion.

Legality of moves in FIDE in general is completely covered by the rule "it is not legal to expose your King to capture, except for capturing the opponent King". Only castling is special, in that it is additionally declared illegal when the King starts or moves over an attacked square.

'Exposing to capture"is completely unambiguous. And it definitely does not indicate the interpretation you sketch above, where the Joker would "forbid a lot of King moves". The ambiguity is what moving out of check or through check means. Note that Fergus avoided any ambiguity by stating that the Royal Queen in Caïssa Britannia can not pass through a square that it could not legally move to". This also seems the logical way to treat passing through check in the context of castling. (Except perhaps for 3-step castling, where the second step in itself would be illegal because it is not even pseudo-legal, and the phrase would have to replaced by "where it cannot legally teleport to if teleporting was a pseudo-legal King move.) The spirit of the rule is all about the King being shot down during the attempt, like e.p. capture. Like I said, this is not a Joker-specific problem; many other pieces whose pseudo-legal moves depend on context (lame leapers, hoppers) require more precise definition of when castling is allowed.

Being in check at the beginning of your turn (and moving out of it) is yet another matter. Which affects both castling legality, and the stalemate definition.

To apply these definitions to a Joker, it becomes essential to define when exactly the pseudo-legal moves of the Joker change. It cannot be at the start of a turn, as at that point it is not yet decided which piece is going to move, so you cannot know what the new moves are. Declaring it has no moves at that point comes "out of nowhere"; no other piece loses all its moves (for determing whether the opponent would castle out of check) after it finishes is move. It seems much less arbitrary to let it keep its moves until another piece actually starts moving. That would affect whether you consider the side to move to be in check or not. And thereby whether castling is legal, or whether a terminal position is checkmate or stalemate. But nothing else.

This is not legal in Chess, but chess programs do it anyway as a way to cut out part of the search tree.

Or to test for check: when passing the turn would get your King captured.

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.

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.

That seems consistent. If black would have moved his Joker (as a Queen) instead of the Knight, and this Joker would then have delivered a Queen-like check at the end of this move, it seems logical that you could also use it to deliver a discovered check, by unblocking it with the Knight.

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.

All this would only be relevant if you aim a Joker at an uncastled King, which would want to castle on that move. It seems unusua that someone would expose his King this way, so the practical difference might be awfully small.

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.

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.

Use the e.p. square to indicate the last-moved piece. For true e.p. rights it would be empty, implying a Pawn must be imitated.

This is also simpler when differently colored Jokers always have the same move. Which I think is conceptually simpler anyway. So it would probably the best choice.