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.

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.

@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?

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.

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

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.
 

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

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.

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

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

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?

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

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! 

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.

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!

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.

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?

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?

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.

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!

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

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.

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.

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.