I can't get that download link to work.

I mean the link to download ChessV 2.3 verison

Also, when i go to your ChessV.org site, on mainpage, I just see the 2.2 version.

Game Reference Documentation

ChessV is designed to allow easy creation of new games through the customization of existing games. Unfortunately, documentation has been sorely lacking. I have now posted reference pages for the predefined games:

These games are organized into a useful hierarchy with many extension points. Hopefully, browsing through these pages will provide some insight into the inner workings of ChessV. Please feel free to post any questions you might have!

Ok, Thanks!

In apothecary chess classic the knight does not get it's extra moves (it is a NmZ)

Thanks for pointing this out.  It will be corrected in the official release.  In the meantime, you can play with an include file like the following:

Game 'Apothecary Chess Classic (fixed)' : 'Apothecary Chess Classic'
{
    AddPieceTypes
    {
        Knight.XBetza = "NmZ";
        Knight.MidgameValue = 425;
        Knight.EndgameValue = 425;
    }
}

In apothecary chess classic the knight does not get it's extra moves (it is a NmZ).

I see only apothecary chess Modern. Probably it is a superficial problem.

Later Edit: Sorry for that My bad!

ChessV 2.3 Release Candidate 1

It's been over a year, so time for a new release! This is a pre-release of upcoming version 2.3. It should be fully functional but I am posting a Release Candidate first to give the community a chance to give it a test drive. Since it is not an official release, there is no installation program. Just unzip to a new directory and run ChessV.exe. The official release will contain an install program.

This release has lots of improvements:

• Anti-aliased graphics for both alfaerie and abstract sets where available – some less common pieces will still result in the game reverting back to bitmaps.
• Support for bent riders. Grant Acedrex, for example, is now supported.
• Support for imitators. The Apothecary Chesses are now supported.
• Continued improvement to the capabilities of the scripting language. New pieces can now be defined with XBetza in most cases. An XBetza expression tester is provided under the Tools menu.
• Many more games have been added. We are up to 138 variants supported, with 44 of those defined via the scripting language.
• Many bug fixes and improvements to playing strength

Download here:
/programs.dir/ChessV2.3 RC1.zip

Please let me know if you run into any issues. Enjoy!

If you're deriving from one of the board-size specific games then there are shortcuts to enable these easily. But the options vary depending on the board size, so for unusual sizes it is a little more work.

You can look at the include file for Duke of Rutlands Chess for an example but here are the relevant bits. For castling, conventional chess would be:

            AddCastlingRule();
            CastlingMove( 0, "e1", "g1", "h1", "f1", `K` );
            CastlingMove( 0, "e1", "c1", "a1", "d1", `Q` );
            CastlingMove( 1, "e8", "g8", "h8", "f8", `k` );
            CastlingMove( 1, "e8", "c8", "a8", "d8", `q` );

The arguments to CastlingMove are: player (0 or 1); the square the king starts on; the square the king ends on; the square the other piece starts on; the square the other piece ends on; and a single character specifying what letter should be placed in the FEN to represent the availability of this move.

For the two-space pawn move, in chess it would be:

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

The last bit, { location: location.Rank == 1 } is a lambda function taking a location and returning true or false specifying where on the board this new move should be available.  Ranks are counted starting at zero, so Rank == 1 means whenever on the second rank.  The arguments sent to the constructor of MoveCapability are: the direction of the move, <1, 0> means rank offset of 1 and file offset of zero; minimum number of steps; maximum number of steps; is capture allowed; and is capture required.  We did not set the minimum number of steps to 1 because the pawn already has a single-space move and we don't want to generate it twice.

Finally, if you want en passant, just set EnPassant = true in your SetGameVariables function.

I would like to script some small chess variants. I started by looking at the Los Alamos chess, but can't figure out how to enable castling or allow an initial double pawn move.

Thanks!

You don't need (and can't use) the namespaces in the scripting language.  This should do it:

AddRules
{
    FindRule( Move50Rule ).HalfMoveCounterThreshold = 200;
}

I have eventually found it in the chess and a half game!

But it seems I cannot acces : ChessV.Games.Rules

I could not find an example where the 50 moves rule is replaced by an 100 moves rule. How is that done?

What about QSearch? I assume it just doesn't consider drops at all?

Indeed. I never managed to get a non-exploding QSearch that searched captures plus drops, even when I limited it to safe check drops. Even an extension for check evasions can be dangerous in QS. At least, if you allow drops as evasions. (I forgot to mention that: when in check at d=1, it is of course pointless to try check drops, and I try drop evasions instead, to prevent seeing false checkmates.) The problem is that the drop evasions can add captured pieces back to the board for the side that is being checked, and if the players alternately check each other this can go on indefinitely. (I never saw that problem in my Shogi engines, but in Crazyhouse it did happen.) So it is probably safest to ignore checks beyond a certain QS depth, or limit the number of checks, or limit checking to one player only. Very powerful pieces can cause problems with search explosion in QS anyway.

That is really painful.  I wonder if it is possible to collect this information incrementally during the search rather than searching deeper to determine?

That is hard because of alpha-beta pruning, which might prevent the relevant moves from being searched. And you wouldn't want to do anything extra on the off chance that the current position might later run into a repetition; repetitions are not all that numerous in the tree.

As to castling: In Joker I had the problem that the castling bonus was so large that it could give rise to "positional horizon effect": it started to sacrifice material just to push the castling over the horizon. Which, predictably, only brought temporary relief for a permanent sacrifice. So in KingSlayer I make the associated King Safety bonus available in small steps. Clearing the path for castling to a location with a good Pawn shield already gives you part of the bonus for that shield. Or, in other words, the value of the castling right is a fraction of the bonus,and the more pieces are still in the way, the smaller the multiplier gets. And the availability of a second castling right gets added for 1/8 to that for the primary one. The Pawn-shield bonuses for all 4 locations are stored in the Pawn hash table, and also depends on the opponent having half-open files aimed at your shield.

I found the following search scheme to work quite well in games with drops: you distingush check-drops from other drops, and make a special move generator to selectively generate those (by generating retro moves for all piece types, starting from the King). At d=1 the only drops searched are the check drops; at d>=2 LMR reduces non-captures by 1 ply, and (non-check) drops by 2 ply.

Well, that sounds pretty easy.  What about QSearch?  I assume it just doesn't consider drops at all?

In CrazyWa I used a King Safety evaluation that seemed to work quite well generically across many drop variants. It was kind of unusual by being asymmetric. It awardeds a bonus to the side to move which is the product of the hand value and the number of squares attacked next to the enemy King (the possible drop locations). The latter could be cheaply calculated as side effect of the move generation, while the hand value can be kept track of incrementally. The idea was that in games with drops 'initiative' is all important, and the side that has the initiative typically checks the opponent all the time (mostly through drops, and captures with the slider it just dropped when evasion was an interposition). The side that is in check will never evaluate, but extend for the evasion even at d=0. So the leaves typically have the side on move that has the initiative, and this player usually doesn't have to worry much about his own King Safety.

This also makes sense.  I'll make a note of this.

Xiangqi chasing rules indeed are very annoying; especially the fact that they are based on legal attacks and protects means that you have to search 3 ply ahead to judge them: one to play the attacks that are  chase candidates as a capture, then the possible pseudo-legal recaptures, and finally the potential King captures resulting from these. And you have to do that for every position in the repeat loop. Always for both sides, because they could be mutually chasing, and then it is a draw again.

That is really painful.  I wonder if it is possible to collect this information incrementally during the search rather than searching deeper to determine?

Ok I went back and checked on the castling using only the ChessV engine with default settings with me as white. I've been playing mostly standard, gothic, and omega. Of three quick openings/midgames, Omega alone castled. What seems to happen is that the engine will push pawns away from a potential castle position before it gets the chance to castle into it.

Yes, I did some testing and I see what you mean.  It has no particularly strong desire to castle, so I'm increasing the castling bonus.  I'm also increasing the length of the opening phase.  The development evaluation bonuses/penalties "fade out" as the game progresses.  (By the endgame, it doesn't matter if you've castled or not.)  So some games it just doesn't get around to castling before the bonus is no longer applied.  And maybe this is right - maybe sometimes there are more urgent things going on.

On a different note, I tried to get P2P.exe (http://hgm.nubati.net/p2p.html) to work with this to play over the internet, but through no fault of either programmer, it won't work. This is because when you bring up the engine settings there should be a specialized window, but in ChessV there is always the same variation, weakening, etc. I only bring this up bcs there might be an easy fix ;)

Interesting.  I'm not surprised this doesn't work, although I don't know of any specific reason why it shouldn't.  The ChessV GUI doesn't support everything in the xboard protocol and there could be bugs with that which is implemented.  I may dig into this at some point, but there are other things needing attention more urgently.  At some point, ChessV should just have the ability to play matches across the internet on its own.

Ok I went back and checked on the castling using only the ChessV engine with default settings with me as white. I've been playing mostly standard, gothic, and omega. Of three quick openings/midgames, Omega alone castled. What seems to happen is that the engine will push pawns away from a potential castle position before it gets the chance to castle into it.

On a different note, I tried to get P2P.exe (http://hgm.nubati.net/p2p.html) to work with this to play over the internet, but through no fault of either programmer, it won't work. This is because when you bring up the engine settings there should be a specialized window, but in ChessV there is always the same variation, weakening, etc. I only bring this up bcs there might be an easy fix ;)

I found the following search scheme to work quite well in games with drops: you distingush check-drops from other drops, and make a special move generator to selectively generate those (by generating retro moves for all piece types, starting from the King). At d=1 the only drops searched are the check drops; at d>=2 LMR reduces non-captures by 1 ply, and (non-check) drops by 2 ply.

In CrazyWa I used a King Safety evaluation that seemed to work quite well generically across many drop variants. It was kind of unusual by being asymmetric. It awardeds a bonus to the side to move which is the product of the hand value and the number of squares attacked next to the enemy King (the possible drop locations). The latter could be cheaply calculated as side effect of the move generation, while the hand value can be kept track of incrementally. The idea was that in games with drops 'initiative' is all important, and the side that has the initiative typically checks the opponent all the time (mostly through drops, and captures with the slider it just dropped when evasion was an interposition). The side that is in check will never evaluate, but extend for the evasion even at d=0. So the leaves typically have the side on move that has the initiative, and this player usually doesn't have to worry much about his own King Safety.

Xiangqi chasing rules indeed are very annoying; especially the fact that they are based on legal attacks and protects means that you have to search 3 ply ahead to judge them: one to play the attacks that are  chase candidates as a capture, then the possible pseudo-legal recaptures, and finally the potential King captures resulting from these. And you have to do that for every position in the repeat loop. Always for both sides, because they could be mutually chasing, and then it is a draw again.

It can be acceptable to only detect chases for repeats that have a certain minimum search depth left (say 4 ply).

Hi Elco. Thank you for your interest in ChessV. I'm glad you like it!

Regarding not castling - was with the ChessV engine? And if so, what variants? Almost all variants in ChessV should be using a function to evaluate development, which would reward castling and penalize losing the ability to castle.

Regarding Asian variants - I hope to support these as time goes on. Makruk is currently supported but without the endgame counting rules. This still needs to be done. Xiangqi would not be hard to do, except for the complicated chasing rules. Chu Shogi also isn't too far away. But games with drops are a much bigger challenge.

There is no reason why an AI should never castle without book. I am pretty sure that the included Fairy-Max and KingSlayer engines would castle very quickly. I don't know about ChessV's intrinsic AI, but if it never castles it means the evaluation can easily be improved. In KingSlayer the castling is driven by a bonus for having a King near a corner behind a Pawn shield.

I guess that conventional chess AIs (i.e. not the alpha-zero type neural networks) are always mostly tactical.

Having used a lot of Zillions, I really like this interface, and the fact that a few extra engines come pre-installed. Zillions is all tactics, but I don't think these engines are.

AI never castles, but it probably wouldn't without an opening book, and making 100 opening books seems a bit much :o

Everything I would want in western chess variants, but I hope someday someone will add Asian variants. That someone might be me if I can find enough time.

I think it would be nice to add a documentation of .cvc (ChessV Code) so I can understand more of how it works.

Indeed it would but writing documentation is very time-consuming.  That said, I do have a lot of reference material that I need to upload.  It does not explain all the details of the language, but it does at least document all the game classes with the pieces and game variables they expose.  This, combined with the 20 samples in the ChessV include directory should go a long way.  I will try to get this posted this weekend.

I think it would be nice to add a documentation of .cvc (ChessV Code) so I can understand more of how it works.

I am sad to say that there still seems to be a problem with the ChessV.Engine.exe WinBoard engine, which I failed to catch and report before, even though I should have realized something was amiss by the long time it took to load ChessV. When I run this engine from the command line, it nicely prints "feature done=1" at the end of a long list of features (ending with the variants feature), in response to "protover 2". But when I run it under WinBoard it does not do that. So that WinBoard, after a timeout (which fortunately occurs after 10 sec, as ChessV did not start with feature done=0), WinBoard qualifies it as a WB v1 engine, which apparently sets the variants list to just the current variant, 'normal'. (This is arguably a WinBoard bug, but it was a hack to make WB v1 engines dedicated to a specific variant, such as TSCP-G work.)

This doesn't seem just a failure to flush the feature done=1 when running under a GUI; in the WinBoard debug log the "feature done=1" never appears, but after sending the engine a move, before it starts thinking, it resends the option definition for "Weakening" instead.

Btw, the syntax of that option definition is wrong (which causes it to be rejected by WinBoard): the closing quote should be at the very end, not immediately after the option name, like

feature option="Weakening -slider 0 0 15"

[Edit] And from the command line it doesn't seem to respond to the 'quit' command.

I have posted a patch to bring ChessV2.2 up to Service Pack 1 (SP1).  This is a zip file that just contains replacements for the EXE and DLL files.  Unzip it into your ChessV2 program files directory to overwrite those files.  If you are still on Release Candidate 1 (RC1) that is ok, this will still bring you up to SP1.

Download ChessV2.2 SP1 Patch

This contains everything we discussed below plus a couple of other small fixes.

I will also be updating the regular installer version and source code.  I will post when those are updated, in case you prefer to download the full installer, uninstall, and reinstall.

Yup, I've tracked that down too.  Thanks for pointing it out!

Well, while you are at it, could you also check out why the engine version prints such strange values for the time in CECP Thinking Output? That must be pretty trivial to fix.

Thank you very much for the help.  I think I've gotten to the bottom it.  It was tricky because there were several things going on.

I think the main problem was indeed with the TT.  Those 169 scores you were seeing were mate positions but those weren't true mate scores.  Amateur mistake here ...  At some point I increased the value I was using to represent INFINITY (CHECKMATE) and I made the value larger than the number of bits I had reserve in my TT entry for storing the score.  So those 169 scores kind of worked - it still prefered them to other things and prefered quicker mate, but other things didn't work.  For example, the mate distance pruning didn't trigger because it didn't consider them mate scores.  I'm sure there are other places in the code with similar issues.

I found this last night but correcting for it did not solve my problem because I had since introduced a new problem since the release of version 2.2.  One of the things I'm doing for 2.3 is streamlining the code for Rules that store state information.  Instead of each Rule-derived class handling this itself, I now derive Rules that store state information from a template class RuleWithState.  Well, in doing that, I broke the DrawByRepetition rule and that was the reason I was still experiencing draws where there should have been wins.

Since things are still needing work on 2.3 and since this is a pretty major problem, I will release a service pack for version 2.2 today or tomorrow.  I will also add the feature for saving the games for games in run in batch mode.

I presented the position to ChessV 2.2RC1, and after 5 min (the time it reports itself is bogus!) it produced a move at 32 ply:

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
32	+169.59 	106.2M	8:50:53	f2f3 f5e5 d4d1 e5e6 f3f4 e6f6 d1e1 f6g6 f4g4 g6f6 g4f3
31	+169.59 	45.1M  	3:35:35	f2e3 f5f6 e3e4 f6g5 d4d3
30	+169.58 	28.1M  	2:11:14	f2e3 f5e5 d4d3 e5f5 e3d4 f5f6 d4e4 f6e6 d3d5
29	+169.55 	19.1M  	1:25:46	f2e3 f5e5 d4d1 e5f5 d1d5 f5f6 e3e4 f6e6 d5d2 e6f6 d2a2 f6e7 e4e5 e7d7 e5d5 d7e7 a2a5 e7f7 a5a3 f7f8 a3a7 f8g8 d5d6 g8f8 a7b7 f8g8
28	+169.55 	15.9M  	1:08:52	f2e3 f5e5 d4d1 e5f5 d1d5 f5f6 e3e4 f6e6 d5d2 e6f6
27	+169.55 	13.3M  	56:28.33	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7
26	+169.55 	11.1M  	46:51.12	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7
25	+169.55 	8.86M  	37:24.84	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7
24	+169.55 	6.49M  	27:22.68	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7 e4d5 e7f8 d6e6 f8f7 e6e1 f7f8
23	+169.55 	5.23M  	22:09.12	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8 f5e5 f8f7
22	+169.55 	3.91M  	16:38.40	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8 f5e5 f8f7
21	+169.55 	2.79M  	12:06.96	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8
20	+169.55 	2.39M  	10:25.56	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f8 d2d8 f8f7 d8d5 f7e7 d5d3 e7f8 d3d6 f8f7 d6e6
19	+57.24 	1.85M  	8:09.84	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2
18	+169.56 	1.42M  	6:22.20	f2e3
17	+169.56 	1.13M  	5:12.00	f2e3
16	+169.56 	895583	4:14.28	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f8 d2d8 f8f7 d8d5 f7e7 d5d3
15	+57.24 	696806	3:22.80	f2e3 f5e5 d4d2 e5f6 e3e4 f6e6 d2d5 e6f7 e4f5 f7e7 d5d3
14	+57.04 	435297	2:11.04	f2f3 f5e5 f3e3 e5f6 e3f4 f6e6 d4d3 e6e7 f4f5 e7f7 d3d7 f7e8 f5e6 e8f8 e6d6
13	+56.96 	285881	1:27.36	f2f3 f5e5 d4d3 e5f6 f3f4 f6e6 d3d4 e6e7 f4e5 e7f7 e5f5 f7e7 d4d5
12	+56.88 	187028	0:57.72	f2e3 f5e5 d4d3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5 e7f7 d3d7 f7g6 e5f4
11	+56.80 	115957	0:34.32	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4d5 e6e7 e4e5 e7e8 e5e6
10	+56.72 	68603  	0:20.28	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5 e7e8
9	+56.72 	39705  	0:12.48	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5
8	+56.64 	23739  	0:07.80	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4c4 e6d6
7	+56.64 	12952  	0:04.68	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4c4
6	+56.64 	5601    	0:03.12	f2f3 f5e5 f3e3 e5e6 e3e4 e6e7
5	+56.64 	2579    	0:01.56	f2f3 f5e5 f3e3 e5e6 e3e4
4	+56.52 	1034    	0:01.56	f2f3 f5e5 f3e3 e5e6
3	+56.56 	418      	0:01.56	f2f3 f5e5 f3e3
2	+56.52 	121      	0:01.56	f2f3 f5e6
1	+56.64 	28        	0:01.56	f2f3
0	#

So like micro-Max it finds a mate score pretty fast; difference is that it seems to be that the pretty slow over-the-horizon mate it finds first isn't improved as much as the depth goes up. Still it is strange that it wouldn't simply play out the mating line it found, and is now in its TT, in the following moves.

[Edit] Umm, I might misinterpret the 169.xx scores as mate scores: when I let ChessV play out this position against itself there do appear standard mate scores at the end. Strange thing is that after the black engine admits to being 'mated-in-1' is its last move, the white engine crashes without performing the checkmate.

It could be that the new condition just makes hash cuts so rare that the damage they do is not apparent. And can you still solve Fine #70 with this new condition?

Some of these end-games are really difficult (like KBNK), but KRK is not amongst those. If the start position is not extremely unfavorable (like the shown mate-in-12 rather than the worst-case mate-in-16), a fresh search should show you a mate score after a few seconds. Once there is a mate score, it should just start playing from the mating line that is now in the TT. Just walking the winning King to the center should already be enough to get better than mate-in-12.

How long does it take ChessV to get a mate score from the given KRK position, and what depth does it reach? Not being able to act out an already found mate would point to entirely different problems than not finding the mate in the first place.

Thank you for the help.  It is indeed pretty strange.

First, I should clarify a couple of things.  The problem isn't specific to KRK - I know it appeared in other situations as well, but KRK was an easily reproduced and extreme example.  Also, the special endgame code isn't specific to KRK, it is really KxK (King + plenty of material against bare king, probably the same idea as your bare king eval.)  This KxK code comes from Stockfish but adapted to do the right thing on boards of any size.  The other specific endgame evals I have so far are KRKP, KRKB, and KRKN (also from Stockfish.)  There is also some special handling for KPK which overwrites the eval to return draw scores on certain positions that are known to be draws (this is custom code based on Wikipedia's KPK article - the Stockfish KPK code uses a bitbase which doesn't help me given variably sized boards.)

The null move was a good idea, as well as draw scores getting into the TT, but neither of these seem to be the cause.  Null move is disabled with low enough material and disabling draw-by-repetition and/or 50-move rule didn't help.

With a fair amount of expirementation, I found another "solution".  If I change the TT cutoff condition at PV nodes from hash depth >= depth remaining to hash depth > depth remaining that solves the problem entirely and my searches seem totally consistent.  But I have "solution" in quotes because I'm not 100% sure this addresses the real problem either, but I think it probably does.  Somehow something is getting off by one somewhere.  I still need to understand it better because the underlying problem may be affecting non-PV nodes too resulting in weaker play that is not so obvious...

This is very strange. Why do you need custom evaluation for KRK in the first place? Fairy-Max had absolutely no trouble to win KRK on its normal evaluation. (Which has Rooks completely neutral, and use the parabolic centralization table for Kings.) In the latest Fairy-Max version I use what you could call custom evaluation for checkmating a bare King (it just multiplies the centralization bonus for that King by a large factor), but that was only needed for end-games with many centralizing pieces (such as KFFFK in Makruk), because these did not bother to leave the center just for driving a single piece into a corner. Checkmating with Rook is very easy on any size board; you almost need no search depth for it at all. You just shephard the King towards the corner with your Rook, keeping the latter protected from behind by your King.

I suppose you do switch off null move?

The only thing I can think of that causes what you describe is contamination of the hash score with draw scores resulting from repetitions. What happens when you disable repetition detection (accepting PV hash cutoffs)? I don't really understand how a line that makes progress could get draw scores from this, though.

Can you post a game of how it typically plays KRK? (Best would of course be one that it bungles.)

Here is thinking output from a version of Fairy-Max that doesn't use the special bare-king evaluation, for position 8/8/8/5k2/3R4/8/5K2/8 w - 0 1 :

mover viewpoint		fewer / Multi-PV margin = 0 / more
exclude: none best +tail                                          
dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
28	  #12 	121.4M	1:17.65	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Re4 Kg6 7. Rf4 Kh6 8. Kf5 Kg7 9. Kg5 Kh7 10. Kf6 Kh8 11. Kf7 Kh7 12. Rh4 
27	  #13 	61.4M  	0:40.03	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re6 Kf5 5. Re4 
26	  #12 	46.8M  	0:30.38	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
25	  #12 	28.3M  	0:18.23	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
24	  #12 	15.6M  	0:09.85	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Kg3 
23	  #12 	10.3M  	0:06.45	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
22	  #13 	7.44M  	0:04.55	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re2 Kg5 5. Re5 
21	  #14 	5.88M  	0:03.52	1. Kf3 Ke5 2. Rd3 Kf5 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Kf4 
20	  #18 	4.72M  	0:02.74	1. Kf3 Ke5 2. Rd1 Ke6 3. Kf4 Kf6 4. Re1 Kg6 5. Re3 Kf6 6. Re5 Kg6 7. Kg4 
20	  #22 	4.50M  	0:02.59	1. Ke2 Ke6 2. Kf3 Kf6 
20	+4.59 	3.68M  	0:02.07	1. Ke3 Ke5 2. Rd8 Kf5 3. Re8 Kg5 4. Ke4 Kf6 5. Re5 Kg6 
19	+4.57 	2.37M  	0:01.27	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kc6 4. Kd4 Kd6 5. Re5 Kc6 6. Rd5 Kc7 7. Kc5 Kb7 8. Rd6 Kc7 9. Kd5 Kc8 10. Ke4 
18	+4.56 	1.54M  	0:00.81	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kh5 6. Rg4 Kh6 7. Rg8 
17	+4.55 	1.12M  	0:00.57	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kg6 6. Kh4 Kg7 7. Kg5 Kh7 8. Rf7 Kg8 9. Kf6 
16	+4.54 	729185	0:00.35	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
15	+4.54 	518699	0:00.25	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
14	+4.54 	354924	0:00.15	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kc7 6. Kd5 Kd7 7. Ke5 
13	+4.53 	218794	0:00.09	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kb5 6. Kd5 Kb4 7. Ke5 
12	+4.53 	150300	0:00.06	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg5 4. Rf4 Kg6 5. Kg4 Kh6 6. Kf5 Kh5 
11	+4.52 	107753	0:00.04	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Kf4 Kf6 5. Re3 Kg6 6. Ke4 
10	+4.50 	54436  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 Kf6 
9	+4.52 	36093  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 
8	+4.51 	20251  	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 
7	+4.50 	9192    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Re8 Kf6 4. Ke4 
6	+4.49 	5719    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 
5	+4.49 	2747    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 
4	+4.48 	559      	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 
3	+4.48 	223      	0:00.00	1. Ke3 Ke5 2. Re4 
2	+4.48 	23        	0:00.00	1. Ke3 Ke5 
1	+4.49 	13        	0:00.00	1. Ke3 

@HG:

I had a problem.  ChessV sometimes wasn't able to find the mate in KRK (for example), despite the fact that I have a custom endgame eval for this combination (which I'm sure is correct.)  I was able to solve this by no longer returning on TT hits on PV nodes.  This is an acceptable solution since you seldom get a cut-off on a PV node so it does not speed things up much, if at all, and it reports shorter PVs.  But I'd still like to understand the problem in case there is something else wrong.

I only return at a PV node if the TT entry depth >= depth remaining and the entry type is Exact.  I also shift mate scores by the ply before returning, as is typically done.  Do you have any insight why I might be missing mates and stumbling into draws by repetition or 50-moves?  I guess my TT code could have a bug, but I don't think so.

Actually saving each game could help beacause I can't stare all day at the monitor and the aftergame survelliance could be fun! For know nothing more. Good luck, Greg!

It was a FF-CC game (could have been reversed). An option to save all games could come in handy!...

I'd need a saved game file to investigate.  You should be able to save even during self-play but you have to catch it before the game ends.  Or I can modify it to save out all games.  What armies were you using?

I have tried similar experiments for Chess with different armies. It seems the endgame is bad as the computer leaves without reason pieces en prize. Tell me how to help you reproduce this bug. That has probably made results skewed in ENEP games, to!

Final results on the enep experiment. There were 100 games at 1 minute + 3 seconds of added time.

enhanced knight 42

extra pawn 58

from which draws were 48 games

The final batch of games is over:

augmented knight 17

extra pawn 23

with 22 draws

Look at the cwda include file:

https://www.chessvariants.com/play/pbm/includes/cwda.txt

Towards the end, the switch #wx and switch #bx are placing the appropriate pieces for each army on the board.  Maybe you can set the values for these to something > 4 before the line that includes this file to get around it.

I am wondering why that is so? I don't clearly see anything in the code that precludes mixed pieces.

Remove all the Game Code and it will work (although with no rule enforcement.)  Apparently the code in the preset doesn't support mixed pieces like that.

I am testing with a modified preset

/play/pbm/play.php?game%3DAssymetric+army%26settings%3DFIDE-Assym1

But whenever I tried to actually play a RR vs FF preset appears, not my modified army. I would appreciate any help.

A third batch of 20 games resulted in:

enhanced knight 7.5

extra pawn 12.5

there were 9 draws.

Another batch of 20 games resulted in:

augmented side 8.5

extra pawn side 11.5

with 7 draws.

The bug appeared again. It seems it does not get the time to increment itself or somethig.

The results for enep with time control 1 min and 3 sec/turn, with 20 games played ,are:

Augmented side 9

Extra pawn 11

There were 10 draws

But the program displayed 8-11. For some reason game (victory for the augmented side) 20 did not get counted. A small bug in here Greg. Also if I may a suggestion it would be nice if in the output file the final score is written at the end!...

Cool.  Let us know the results :)

It works. Many thanks Greg!

That's right.  If your games are all playing from the starting position, you would just paste those two lines over and over again.

Thanks a lot. What I don't understand how many repeats will there be? Does it involve copy pasting the two lines over and over again?

The control file is a tab-delimited text file.  The first row is the header row identifying what is in each column.  Each row after is a game that will be played.

The required columns are:

Game - the filename of a saved-game file (*.sgf)

Engine1 - the engine playing player 1 ("ChessV", "Fairy-Max", etc.)

Engine2 - the engine playing player 2 ("ChessV", "Fairy-Max", etc.)

Time Control - the time controls (“1:30” would be entire game in 1 minute 30 seconds, “0:10+2” would be a base time of 10 seconds, plus an increment of 2 seconds for each move.)

Other columns are optional:

ID - If you want to identify the games in some special way.  By default they will just be identified by row number.

Variation - The variation of play (“None”, “Small”, “Medium”, or “Large”.  Default is None.)

Player1 and Player2 - How you want the sides identified for purposes of counting up statistics.  By default, it will use the engine names.  Which is reasonable if the purpose of the test is to pit ChessV against Fairy-Max and see which one does better.  For ChessV vs. ChessV, it won’t accomplish much.  In your case, you are testing Augmented Knight vs. Extra Pawn, so name your player accordingly.  Also note this can do variable substitution in the form of #{variable}, so for testing different armies, you would specify #{WhiteArmy} for player 1 and #{BlackArmy} for player two.

For your purposes, let’s say you have two saved game files - WhiteAugmented.sgf and BlackAugmented.sgf.  They don’t need any moves in them unless you want to have multiple files from different start positions.  Given this, your control file could look like this:

Game    Engine1    Engine2    Time Control    Player1    Player2    Variation
WhiteAugmented.sgf    ChessV    ChessV    0:30    Augmented Knight    Extra Pawn    Small
BlackAugmented.sgf    ChessV    ChessV    0:30    Extra Pawn    Augmented Knight    Small

I have whatched a few games today, engine vs engine mode, and chessV2.2 is definetly a marvel. Extremelly fun! Big congratilations!

I want to try batch mode on Enep to find out which side is better. I'd bet on the side with the extra pawn based on the few games I watched with ChessV 1, but who knows. For that I'm asked for a control file. How do I write one?

Ah, I forgot this detail. They don't all have the same castling rules :(!

Actually, this does not quite work.  Waffle Chess has a unusual castling rule (which is why it was not included.)  I had planned to add support for "Fast Castling" but it didn't make it into this release.  Probably it will be in the next one.

@Kevin Pacey

I have noticed the new version (maybe from before) Hannibal Chess & Frog Chess are present but not Waffle Chess.

I have created a script, which is quite easy. If you are curious to adding it into your copy of chessV2.2 there you go:

Game 'Waffle Chess' : 'Generic 10x8'
{
Invented = "2017";
InventedBy = "Kevin Pacey";
Symmetry = MirrorSymmetry;

SetGameVariables
{
Array = "rnbwqkwbnr/pppppppppp/10/10/10/10/PPPPPPPPPP/RNBWQKWBNR";
Castling = "Standard";
PawnDoubleMove = true;
EnPassant = true;
PromotionTypes = "QRBNW";
}

AddPieceTypes
{
AddChessPieceTypes();
AddPieceType( Phoenix, "Waffle", "W", 285, 285 );
}
}

Well I actually don't know the invention year :)!

Hi James.  Thanks for the post.  If you had the issue, it is likely other will as well.  It is good to know an uninstall is required.  I will edit my annoncement post to add this note.  I wonder if I can modify the installer to do this automatically ...

BUG ALERT: Do not set the transposition table size to anything larger than 1 GB.  If you chose a size larger than 1 GB, you will only get 16 MB (no matter how much RAM you actually have.)  This will be fixed in a future release.

I'm not sure, I don't really use WinBoard.  You specify the engines with /fcp and /scp switches (first chess program and second chess program.)  If you don't specify them on the command line, I believe it will ask you.  You don't neeed to make two copies of ChessV - you can point both to the same executable.  Then, somewhere in the user interface, are options to set engine parameters.

@Greg

I'm quite sure I did not made myself clear earlier, so the question was: How would setting up winboard play by 2 ChessV engines, one with small variation anoter with medium work :)? Thaks!...

I have found it Greg!... No trouble! But how do I put things together now?

@Greg

Where do I download winboard?

I have already downloaded the new version. Thanks again for your excellent work. I think the released date mentioned on your website has the wrong year.

Watch ChessV acting in all its glory!

That's right, that should work.  And the Variation of Play parameter can be set through the Winboard interface.

It would be interesting to compare the small and medium variations of play. Greg has told me that it is not possible internally. But I think winboard can accept two *.exe files. It would not care that it is the same engine with diffret parameters. Is that corect?

ChessV 2.2 Released

The newest version of ChessV has finally be released and is available for download here.

New Features

• About 30 new variants have been added. The total is now over 100.
• Playing strength has been increased significantly.
• The engine now has a few configuration options:
  
  
  • Variation of Play - When set to "None", ChessV is completely deterministic as it was with previous versions. Options "Small", "Medium", and "Large" use various means to increase the variety. Small should not weaken the playing strength although higher settings probably will.
  
  
  • Weakening - A setting from 0 to 15 to reduce the strength of the engine
  
  
  • Transposition Table Size - This is now configurable from 16 MB to 4 GB
  
  
• The ChessV engine can now be used separately from the GUI if you wish to use it under a different GUI, such as WinBoard. The separate engine is ChessV.Engine.exe
• The power of the scripting language has been increased. 23 of the included games are now implemented with the scripting language.
• Various tools have been included such as a basic facility for running games in batch mode for testing and analysis.
• Lots of bugs have been fixed. Thanks to all those who helped with testing and reporting issues!

IMPORTANT: If you have a previous version installed you should uninstall it first. (This only applies to versions installed with an installer. If you used one of the test builds by unzipping and running you should be fine.)

Hi, Carlos.  Thank you for finding and reporting these.  Good catches!

I was able to fix numbers 1, 2, and 3 in just a few minutes.

Unfortunately, #4 is not really a bug.  The chess board display does not scale - the resolution of your screen must be large enough to accomodate it.  Perhaps your screen resolution is too low to fit a 12 x 12 board (or you have a zoom setting turned on.)  I want to improve this, part of which will be using the scalable vector graphics that H. G. made.  Currently the piece graphics are bitmaps so they would not scale well.  Some option to shrink would be nice anyway, but it will not make it into this version.

But if you find any other bugs, please let me know :)  I am going out of town for a few days and plan to make an official release of 2.2 when I get back if no new issues have been discovered.

Thanks, Greg, for answering. Hopefully soon some mobile apps developer could join and help in your ChessV undertaking.

I'm sorry to tell you that I have found these bugs:

1. In Ministers Chess setup the i-rook and the h-knight from White side are switched.

2. In Sac Chess both kings cannot castle.

3. When rotating the boards the numerical coordinates remain unchanged.

4. In Gross Chess the window size does not fit proportionally to the PC screen.

Aside of that, I'm enjoying immensely your masterpiece!

Hi Aurelian

This may belong under the Hannibal Chess thread; I'd consider multiple setup positions for any number of my CV inventions at some point, once I'm sure I know how to get that available to Game Courier (GC) play.

 I think the type of elephant you've diagrammed is known as the lieutenant piece in Spartan Chess (that is, it's a ferfil that also has available to it non-capturing moves one step left or right orthogonally, if I understand the notation right). I've used that piece type already in a CV invention of mine (called Wide Chess, 12x8, hardly played yet - although I played you a game of it long ago). I'm not sure it would make Hannibal Chess (the way it stands) at least as playable, or more popular, in GC play - perhaps the straight ferfils, when in the current setup, are already pretty potent (though I know I mentioned people on the whole seem to prefer adding in powerful pieces, in CVs).

One other thing I concluded about popular CVs on GC from cursory study of the 1200+ GC games played list is that the most popular CVs on GC tend not to have many asymmetric-moving pieces (if any at all) in their setups; IMO, this is in line with Fergus' suggested guidelines for trying to design good CVs. Someone I've chatted with once told me they don't like to 'fight against their own pieces' (as opposed to those of the opponent), though they didn't like even Nightriders (or Waffles [WA]{!}) for that reason. Maybe it was mostly their own viewpoint, as Nightriders seem fairly popular with players, and not too irregular, perhaps.

Sorry guys but I don't see any video.

Kevin, would you consider electing among several eligible initial position, hannibal chess 2  for example(akin to fisher 960 )?! Why choose when you can enrich?

Also I'd really perfer this elephant, but this is probably a matter of taste:

x              x

    x     x

    mEm

    x     x

x              x

Nice video!

To answer your question, sure, I'd like to have a version for mobile devices, but it would not be simple.  All the user interface code would probably have to be changed and I do not know anything about mobile development.  I could learn, but there are so many things I want to do.  (One of the next things I plan to do is support hexagonal chess - that I know how to do.)  It would be nice if someone who had experience with mobile development took that on.

You are welcome, Greg. Let's follow playtesting your masterpiece! Have you thought about developing a ChessV app for mobile devices, tablets and phones?

Those who are participating in the current tournament and are playing Symmetric Chess for the first time maybe might be interested in seeing how ChessV manages the matter.

Carlos,

Thank you for your help testing.  We have been able to resolve three different bugs.  Releasing an official version with an installer is a pain so it is good to get these issues solved first.

Aurelian,

There have been three different issues.  The first, with the previous release, involved buttons on the main screen being the wrong size with certain display settings.  The second, with the previous 2.2 release candidate involved errors related to trying to load DLLs dynamically not being allowed on Windows 10.  (Not actually a Windows 10 problem, but a problem related to the fact that it was built with a newer version of the .NET Framework which had extra restrictions.)  The most recent, from last night, "Fatal Error. Directory of piece set graphics could not be found. Please re-install ChessV" was caused by an issue with the path.  I need to make that more robust.

Which error you were talking about guys?!...

Okay, following your instructions, I was finally able to run the program. It's wonderful! 106 chess variants available!

Congratulations Greg. You have done an excellent job.

Thanks again for all your support!

The ChessV.Engine.exe shouldn't show you anything.  That is just a stand-alone engine for playing with Winboard or another GUI.  To use ChessV interactively, run ChessV.exe.

Ok, let's try one more thing to fix the problem.  I think I know what this issue is.  I see in your path that you have two folders named ChessV2.2RC2, one inside the other.  Please rename the first (outer) one to something that does not contain ChessV.  For example, you could rename it Test and then your path would look like this:

C:\Users\Carlos\Downloads\Test\ChessV2.2RC2\ChessV.exe

Then try running ChessV.exe again.

Hi Greg.

Unfortunately the problem persists.

I must tell you that I am now using a new recently purchased HP laptop, whose main specifications are:

Model: 14-cm0026la

Name: LAPTOP-M9SUMFI7 

Processor: AMD A4-9125 RADEON R3, 4 COMPUTE CORES 2C+2G 2.30 GHz

Installed RAM: 4.00 GB (3.88 GB usable)

Operative System: Windows 10 Home (1903 version)

When I double click on ChessV.exe, a window pops up saying "Fatal Error. Directory of piece set graphics could not be found. Please re-install ChessV."

After re-downloading http://chessv.org/downloads/ChessV2.2RC2.zip and following the whole process to run it, I get the same outcome.

If I double click on ChessV.Engine, then it pops up a window with a black background, a blinking cursor and a header saying "C:\Users\Carlos\Downloads\ChessV2.2RC2\ChessV2.2RC2\ChessV.Engine.exe" 

What's going on?

I have posted a new version that will hopefully fix the issue with Windows 10:

http://chessv.org/downloads/ChessV2.2RC2.zip

Carlos, if you have a chance, can you please download, unzip and run ChessV.exe and let me know if it works?

Ok, I'll post an updated version tonight or tomorrow that fixes this problem.  Thanks to your error message I believe I know what the problem is.

Hi Greg:

Bad news. I followed your instructions completely but cannot run the app. Now the emerged window had a black background, no text and there was only a blinking cursor; the window header said:

C:\users\Carlos\downloads\ChessV2.2RC1\ChessV2.2RC1\ChessV.Engine.exe

Out of curiosity, I tried to do the same thing I did with Nebiyu, that is, to run it with WinBoard but the action was stopped.

It seems that I have no choice but to wait for the new ChessV version.

Thank you very much for all!

Hi Carlos,

This error message is helpful.  Try this: right-click on ChessV.exe and select Properties.  In the window that opens, there may be a button toward the bottom right that says "Unblock".  If so, click Unblock and click OK.  You may also need to do this on the DLL files.

I will upload a new version that fixes this, but I think this may get going for now.

Greg:

I reloaded ChessV2.2 again and, trying to run it, a window was opened saying:

System.NotSupportedException: An attempt was made to load an assembly from a network location, so the assembly would have been included in an isolated space from previous versions of .NET Framework. This version of .NET Framework does not enable the CAS directive by default, so this load can be dangerous. If this load is not going to include the assembly in an isolated space, enable the loadFromRemoteSources modifier. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

A smaller window said:

The program stopped working correctly due to a problem. Windows will close the program and notify you if a solution exists.

Then I loaded your program one more time by using another PC (also with Windows 10) and the result was the same error message.

So there is no doubt that whoever has the problem is me. And to think that I was so excited because  I was going to try Symmetric Chess vs an engine! 

ChessV 2.2 Release Candidate 1

It has been nearly two years since the last release, and that's far too long especially given all the improvements that have been made.  I've just been too unfocused, starting on adding more and more without fully testing and wrapping up.  Now things are mostly wrapped up, and, while I am not ready to make an official release, I am at least ready to relase it to the CVP community for a kick of the tires.  Although there are probably a couple of bugs, I fully expect this release to be pretty stable and it adds a TON of new stuff.  A partial list follows.

This pre-release version does not have an installer - just unzip and run the ChessV.exe.  It is built with .NET Framework 4.5.1.  It should run on any system with .NET Framework 4 or greater installed (emphesis on should - please let me konw if this doesn't work.)  This version of .NET is supported by Windows Vista and newer.  Thus, it will not work with Windows XP.  If there is demand, I might make one final release supporting .NET 2.0.  But even Vista is already end-of-life and Windows 7 goes EOL in two months.  Also, this should run under Mono so Linux users should be able to run it too although the UI won't look quite as pretty.

New Features/Improvements:

XBoard Engine – It is now possible to run the ChessV engine under Winboard or other compatible GUI.  Just run “ChessV.Engine.exe”.  This still requires .NET Framework 4+ or Mono.

Engine Configuration – The ChessV AI now has a couple of configurable parameters, for which you will be prompted when starting a game.  The “Variation of Play” option (“None”, “Small”, “Medium”, or “Large”) allows non-deterministic play.  Previous versions would always make the same move in the same situation.  “Small” should not weaken the engine at all while resulting in some variety – and the longer it thinks the more variety, at least to a point.  Medium may weaken play, I don’t know, but will lead to even more variety.  There is also a “Weakening” option specifically to weaken play so a human can have a fun game with a chance to win.  The size of the hash table is also configurable now.  These options are also exposed through the CECP (XBoard) protocol when running ChessV as a stand-alone engine.

Tools – A Tools button has been added to the main form that offers several functions (although without documentation.)  There is a Batch Mode that will allow ChessV to run lists of games in sequence with different parameters: different variants, different XBoard engines, different ChessV parameters such as Variation of Play, different time controls, and starting from different positions specified in saved game files.  Output is reported and can be configured to report in different ways depending on what is being tested.  For example, you can run gauntlets of ChessV against FairyMax and it will report win/loss statistics based on the engine that won.  But it can also run gauntlets between different Chess with Different Armies armies, and it will report the statistics based on which army won, not which engine was playing.  Sorry this isn’t really documented yet, but I will post example batches to demonstrate.  Some other tools are provided as well useful for testing, generating opening books, and documentation.

Scripting Language – This has seen a ton of improvement, and one can do a lot more.  It is basically possible to create games with new pieces, new combinations of rules, and even new board sizes.  But it is not yet powerful enough to create entirely new rules.  You can derive from existing games and just make changes, derive from abstract base classes by board size that offer useful features for that board size, or derive from generic and provide almost everything yourself.  See Duke of Rutlands Chess for an example of a game with a totally new board size and thus must define its own pawn double-move, castling, etc.  This version has 23 games defined by include script and, as development continues, more and more games will be defined in this way and not compiled internally unless there is a good reason.

New Games – Dozens and dozens.  We are now over 100 variants.  I’m not going to try to list them all, but here are some of the new and/or popular games now available: Symmetric Chess, Veteran Chess, Wildebeest Decimal Chess, Wildebeast9, Hectochess, Sac Chess, Frog Chess, Hannibal Chess, Xhess.

Performance Improvements – The strength of the internal engine has been significantly increased.

Bugs Fixed – Lots and lots.

DOWNLOAD: www.chessv.org/downloads/ChessV2.2RC1.zip

Oh thanks - I understand now. Other than bishops, I've never played with any piece restricted to a limited range of the board. I'm sure there are many such pieces, but unfortunately there is probably no existing catalog of "meta-color" bound pieces. Maybe something for me (or anyone) to work on for this year?

'Color' is just the square shade you can see on a checkered board, light or dark. The term 'meta-color' usually refers to another (hypothetical, i.e. not actually visible) coloring scheme using more than two colors in some other pattern, each meta-color indicating a set of reachable squares. E.g. a Dababba can only reach a quarter of all board squares, so that you can put four Dababbas on a board that could ever collide with each other, each on its own meta-color.

Just a little confused about some of this discussion: what is the distinction between "meta-color bound" compared to "color-bound"?

I think that trying to treat irreversible pieces like Pawns as color bound misses the point. E.g. a Xiangqi 'passed Pawn' (fsW) or a Dai-Shogi Evil Wolf (fsWfF) on a1 can reach the entire board. But that ignores that when they try that, they never can move back. Pieces like that have an ever shrinking accessible area, which is basically a property independent of color binding.

This is further complicated (or neutralized, depending on how you look at it) by promotion. Pawns in Chess do promote to pieces that can access the entire board. So they are not really meta-color bound. But in Makruk, where they are predestined to promote on a certain color to a color-bound Ferz, there actually are locations where they never will be able to go. That Pawns before their promotion can access only a limited part of the board is more comparable to (temporarily poor) mobility than to color binding.

Another issue is how to treat captures. As in general you cannot force survivable captures at will, capture moves are not very helpful for breaking color binding. It seems better to treat a non-promotable FIDE Pawn as having access only to the (forward part of) the file it is on, while interdicting access to some squares outside that area. Such attacks outside the meta-color to which it is bound can of course have consequences for its mating potential. Two mFcW on different square shade have no mating potential, so they behave pretty much as color-bound pieces as far as checkmating a bare King is concerned.

Do these "rules of thumb" work for the huygens chess piece? As far as I know this piece does not appear in any chess engines, but it could be a good exercise to test the robustness of any new code.

Thanks, that is an excellent idea.  Although I've never added the Huygens, it should work and consider the entire board to be one slice, since the Huygens has no color-binding.  It cannot move a single space directly, but since it can leap three forward, and then two back, it can effectively move a single space, and the recursive algorithm would find this.

That said, it seems that we have other problems.  I've had this algorithm for a while, but since it wasn't really used for much, any issues went unnoticed.  I now notice that we do, indeed, have some issues, and it is nothing so fancy as the Huygens.  The problems start with the venerable chess pawn...

A pawn placed on a1 cannot visit the whole board, only a little over half the board.  So it considers that triangular-shaped half the first slice.  (Nevermind that a pawn cannot even exist on a1, that's a whole 'nother problem.)  Since this did not find the whole board, it detects the second slice by throwing a pawn on b1 - but this only finds 7 more squares!  For slice three, throw a pawn on c1 and find 6 more squares ...  Obviously, this is not at all what we want to happen.  In fact, as far as the pawn goes, I'm not even sure what the theoretically correct answer is, although I'm quite sure this ain't it.  A slight improvement would be to ignore the pawn's capture-only moves on the grounds that it might never have the opportunity to do that.  This would leave each file as a separate slice.  There is some logic to this.  It might even be the correct answer to some questions.  But, for purposes of making a material hash table, to detect draws by insufficient material and probably do other groovy stuff as well, I believe we want to consider all pawns to be identical (although I'm not 100% sure of that either...)  So I guess the pawn just gets a special flag that tells the system to treat it as though it is not colorbound even though it really is.

The pawn also points out another potential problem with this algorithm.  It begins by visiting the "first" space.  This, for the pawn, was bad, but not truely terrible because it considered a1 to be the "first" space.  But what if pawns went backwards instead of forwards?  Now instead of considering the board to be split into 8 different slices, it would be split into 64 different slices!  Clearly, for asymmetric pieces, the choice of which square to visit first is very important.  I can see two potential ways to deal with this.  First, we can look at how the piece moves and then be wicked smart about which square to visit first.  This would be awesome, but I'm not sure how to determine this (it makes my head hurt, and, frankly, I'm just not that smart.) And I'm not 100% sure that there even is a best answer for all kinds of pieces.  The other possible solution is to leave it as-is, with the addition that when we are doing our recursive analysis to detect a new slice, if we happen to stumble across a square that we have visited while discovering a previous slice, we now need to consider this new traversal to be part of that original slice.  I think this approach is solid, although the algorithm is now becoming more complicated ...  But, well, that's why this particular project fascinates me so much.  The various interesting issues to ponder are practically never-ending.

Another potential issue, alluded to above - we probably only want to consider squares to which a piece can theoretically move.  It doesn't matter what a pawn on the first rank can do.  But for a better example, consider: Pocket Knight.  The knight "drop" is not really a normal move, so I think (although I'm not sure) that our fancy colorbinding-detector should not consider it.  Therefore, it should consider the knight to see the board as three separate slices (three different meta-colors) - the main board, White's pocket square, and Black's pocket square.  Groovy.  But what we don't want to happen is for it to then consider the bishop to also have three meta-colors, since the bishop isn't in the pocket and can't go there.  So this would be the next change to the algorithm - don't find the entire board when the game is created.  Only start this process when a piece is actually placed on a square and that square hasn't been visited yet (meaning it hasn't yet been segregated into any given slice.) Strangely, this is how the old C++ ChessV used to do it. I changed it because I thought I was simplifying things, when apparently I was breaking things :)

One final random thought ...  If a piece type has two meta-colors, you can NOT assume that it is equivalent to all other pieces with two meta-colors.  Example: Alice Chess.  In Alice Chess, both the Knight and the Bishop can see exactly 50% of the squares.  But their color-bindings are NOT the same!

Fun stuff!!!

Do these "rules of thumb" work for the huygens chess piece? As far as I know this piece does not appear in any chess engines, but it could be a good exercise to test the robustness of any new code.
 

The algorithm Greg describes seems completely robust, even for hex boards, or pieces with position-dependent moves.

Yup.  I try not to attack any problem unless I'm attacking it in a "universal" way.  Although, on further reflection, my algorithm will fail for Chess on an Infinite Board whereas yours would work fine :)

The algorithm Greg describes seems completely robust, even for hex boards, or pieces with position-dependent moves. And it is not that computation intensive, when you mark the squares you have already visited; it just requires running the move generator once on every reachable square.

@HG,

I assume more bounded pieces like the dababah or the elphant should be found by conditions on other parities like deltax and deltay separatly. The chiral knight is interesting. Any ideea on hex boards?

ChessV does this with a brute-force recursive algorithm.  It calls a recursive function to "visit" the first square.  This function marks that square as "found" and then proceeds to go through every movement capability that the piece has, finds the next square in that direction, and recursively calls itself to visit that square.  When this finally finishes every square you have visited is part of the first "slice" or "meta-color".  Are there any squares that weren't visited?  If so, do this whole process again starting with the first square that wasn't visited.  The results of this search will be the second slice.  Continue as necessary until the entire board has been found.  This should work for any board geometry.  It's a little computationally expensive, but is only performed once when a new game is being created.

I cannot really answer that for ChessV, but Pair-o-Max does it too, and it is quite rivial. You just check if delta_x + delta_y is even for every possible move. Sliding moves are just multiple moves of the basic step, so you only have to test the basic steps. I suppose ChessV does that likewise.

This of course only works on a topologically flat board. If you would have an odd-circumference cylinder, or helical board, it could be uncheckerable, so that there only is a single square shade,

I am not sure how you would determine the meta-color of a square, though. Especially in non-trivial cases like (say) right-handed chiral Knights, which distinguish 5 meta-colors. In principle every point-symmetric piece with 4 moves other than Wazir should have a form of meta-color binding.

How does ChessV determine colorboundedness?  Just by moving a piece around for a few moves?

Indeed, distinguishing pieces by (meta-)color is beneficial, and would also allow easy depreciation of end-games with unlike Bishops, like KBPPPKBP. I am not sure how that generalizes, BTW. End-games with unlike Ferzes did not seem particularly drawish. And logic dictates that the color binding should only be a handicap for the strong side, and not an asset for the weak side. So in KBPPPKXP it should not matter much if X is color bound or not. Yet when X=N this is not particularly drawish. The drawishness with X=B seems to be caused by the ability of the Bishop to stop large numbers of Pawns from crossing a diagonal.

Of course with multiple color-bound piece types mating potential can also critically depend on whether they are on the same or a different shade. Note that is Makruk it is beneficial to also consider Pawns as color bound, depending on the shade of their promotion square. KPPPK will be a draw if all Pawns promote on the same shade! It is a good question how to judge divergent pieces, such as the Berolina Pawn. My gut feeling is that you would have to judge them by their m component.

I have forgotten the exact number, but it surprised me how much stronger Pair-o-Max was than Fairy-Max. (I think over 50 Elo.) And this was just from recognizing Bishop pair and the drawishness. Where the latter was not even implemented through a material hash, so that I expected a significant slowdown from it. But the primary filter for the drawishness code is that the number of Pawns of the strong side should be <= 1, which is not the case throughout most of the game, and rather cheap to test. The largest overhead is actually keeping a count for each piece type (which probably costs less than updating a material hash key). Pair-o-Max doesn't recogize unlike-Bishop end-games, however, as these typically occur with many Pawns.

Ok, I think I'm now going to tackle these related issues of detecting draw by insufficient material and scaling down the evaluation of positions that are likely drawn due to the material present.

As a first step, I'm going to code a material hashtable so this detection won't be too slow.  Although the page on the chess programming wiki only describes tracking the number of each type of piece per player, it seems you also want to track colorbound pieces of each type separately...  KBBK is a draw if they bishops are on the same color, otherwise it isn't.  So it seems for these purposes, a black bishop on light squares should be considered a different type of piece from a black bishop on dark squares.  Fortunately, ChessV already detects which pieces are colorbound automatically, as well as how many different "colors" each has (which internally I call "slices" so as not to confuse the different meanings of colors.)

Yes, agree with all. There are some 7-men endings that engines can't play perfecty, such as the mate-in-546 position. I once plugged that position into a chess engine and it was pretty much clueless. Even with the 50-move rule, the side that could achieve the draw (by playing to 50 moves) sometimes lost the game. (Of course, these endings aren't seen often if ever in actual play).