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

It is possible to look up the game positions. But this usually provides no benefit at all, because engines are usually good enough to win won games on their own steam. Most gain comes from probing EGT in search when there still are more men on the board than in your largest EGT, to make sure you will convert to a won position, rather than a drawn one. This requires several hundred thousand probes per second. E.g. as a simplified example consider a KPPPKPP position, whith many possible ways to force conversion to KPK depending on where you start attacking with your King. If you only have a 3-men EGT for KPK, and no special knowledge of KPK, you would just randomly convert to one of the KPK positions. Pobing the game position would then just tell you "Oh, too bad, this is a draw". The search would not see that, as in KPK you can postpone a stalemate or repetition very long, to beyond the horizon. Only when you can see in the search which KPK positions you can convert to are wins and which are draws, you can make the right choice, and force conversion to the winning KPK position.

Thanks HGMuller for the very informative information.

I believe the Lomonosov EGT is based on DTM because it includes forced mates that go on for hundreds of moves without pawn moves or promotions. The longest I believe is a 546-move forced mate.

Many of my questions are from the point-of-view of seeking an engine which plays perfectly. Of course there's no prospect of anyone doing this in the near future. But the question of "how" is interesting to me.

As for using the existing Lomonosov tablebase for actual play, I believe it could be possible for anyone who has paid to use the resource. Although the database is huge, information related to the "position-at-hand" could be transmitted in packets. I would think the internet is fast enough to support a game with 90 min/40 moves (for example).

Nevertheless, you raise some very good points. Another interesting point is that in perfect play, most of the 7-man tablebase includes positions that may not even exist in a perfectly-played game. In other words, although the tablebase represents "perfect play", much of it may not be part of "perfect games".

It's interesting to think how chess is still so far from being solved, and yet people like you (Fairy-max), Greg (ChessV), Nicolino (Chess and a Half ), Aurelian (Enep), and others keep inventing stuff that is beyond chess!

An extra man both means that there are many more material combiations, and that each combiation takes far more storage and time (like a factor 64 or 32 times as much). If 7 men took half a year, 8 men will take about half a century.

A reason to do it again would be ownership; the 7-men Lomonov EGT are a commercial enterprise, and you have to pay for the use of it. The type of EGT could also be an issue; I don't know whether Lomonosov is DTM or DTZ50, but whatever it is, one could want to have the opposite type.

Note that the 7-men EGT are good for looking up positions from the actual game, but are virtually useless for guiding the search (which would need probing of about a million times as many positions). Their size is so large that current storage media on anything but a super-computer cannot hold them. So access must be through the internet, which is thousands of times too slow to be of any use. EGT up to 6-men can still be stored on a typical had disk (or better yet, a solid-state replacement), and thus be accessed in reasonable time, although this still causes significant slowdown of the search.

Note that use of 5-men EGT by Chess engines typically improved their play by about 0 Elo. For 6-men there seems to be a small positive effect, like 10-20 Elo. This is most likely due to the fact that the current top engines have been developed while 6-men EGT were already available, and thus have been designed to be fully dependent on them, andrather clueless in their absense. Engines are typically developed only for Elo, and the the rating lists test them in games that are adjudicated as soon as the 5- or 6-men stage is reached. So who cares if their engine is not able to win KQK or KRK, when they get the point for free by adjudication anyway?

@HGMuller,

As usual thanks for the info. I believe that there is only one institution that has produced a complete 7-man tablebase, and it required a few months using supercomputers in Moscow. I believe queries of the data can be made here:

Since this has been completed, there is no reason for anyone to do it again. But I've been curious how much work it would take to expand it to an 8 man tablebase. Doing it completelly is probably currently not feasible, but from your description I would guess some "shortcuts" can be used to gain some end-game results for a range of 8 (or more) end-game positions.

Again, this is for normal chess, so you and Greg have a lot of work to do.;)

@Greg: In WinBoard I distinguish two cases: official game end due to impossibility of help mate, and adjudication because of practical impossibility to force a mate against reasonable couter play. KNK and KBK (or more Bishops on the same shade) are official draws, KNNK, KBKN, KRKR are just impossible to win. For the latter type there usually are some tactical positions from where they could be lost (like mate in 1, or Rook capture in 3), so WinBoard does the adjudication (when enabled) only after a few moves. Note that FIDE rules also stipulate draws in some positions no engine or GUI would recognize, with impenetrable walls of Pawns separating the Kings and the pieces that could attack them.

To apply these rules to arbitrary fairy pieces requires kowledge that is not so trivial to obtain automatically, but usually easy to provide as part of the game definition. For orthodox Kings the possibility for help mates exists with single pieces that attack orthogonally adjacent squares, or any two pieces not bound to the same color. But for more general royal pieces it can be tricky. E.g. in Knightmate a Bishop superficially can cause a checkmate (Royal Knights on a1 and d4, Bishop on b2), but the position is unreachable from any 3-men position. To know if a mate can be forced would require generating a 3- or 4-men EGT. Sometimes you quickly see that the mate cannot be forced in general (such as with a pair of Knights or a Gnu), sometimes you have to calculate for many moves (e.g. KQKQ or Wazir + Ferz). But perhaps piece combinations where forcible mates can take many moves should never be adjudicated as draws.

@V.Reinhart: EGTs are always created by retrograde analysis. Doing this for a single 7-men end-game can take weeks. Each extra men basically drives up the storage requirement a factor 64 (32 if it is a color-bound piece), for standard 8x8 boards, and the generation time likewise. 4-men on 8x8 take only a second, however, and 5-men less than a minute, and can conceivably be done during a game.

There is a trick, however: these estimates only apply to pieces that have access to the full board, through reversible moves. Orthodox Pawns can only move forward, and the number of different Pawn constellations with 5 or 6 Pawns that are mostly blocking each other head to head can be surprisingly low. So in principle it should be easy to generate EGTs for Kings + 2 mobile pieces + a number of Pawns, even if the total number of men would be 6-10, during the game, provided the Pawns are sufficiently blocking each other. The point is that you only have to worry about the Pawn constellations that are still reachable.

Thanks Greg; I will try to provide a sample of the error message.  I should mention that I didn't see Review available when the computer was thinking (which is fine, as you had planned), but I had clicked on the "far back" and "far forward" buttons and that's when the error came up.

@H.G.,

Thanks for providing the heuristics.  I think I will implement this so it doesn't blindly trade it's way into a stalemate endgame thinking it is ahead.  It wasn't what I was thinking of though.  I'm wondering for which combinations of pieces the GUI should terminate the game and declare a draw.  Any combination of pieces that can't be arranged into a checkmate position even if the opponent walks his king into a corner would be a good start (and probably sufficient.)  But that could be hard to determine.  Probably would have to start with a simple piece property that specifies if that piece with just a king can checkmate another king (your Mating Minor property) and then only detect 3-piece forced draws.

@Jeff,

Thanks, I will look into this.  It's possible I didn't test with a completed game.  As a work-around, you could just do one "take back move" so that the game is no longer finished.  (First, be sure to uncheck "computer plays white" and "computer plays black" so it doesn't try to start playing when you take back a move.)  I'm also unsure why it would give you an error and crash during a game.  This was certainly tested.  Is the computer thinking when you try to go back?  That would certainly mess it up, although I think I put checks in place to prevent entering review mode when the computer is thinking.  When you get this crash, can you use the button on the crash dialog box to save out the error long and email it to me?

I should add that when loading a previously saved game - as long as the game was NOT finished, I was able to scroll through moves, but only in that particular instance (I think Review mode working on a finished game should be higher priority, my opinion)

Hi Greg, congrats on the release of Version 2.1!  It looks pretty good from what I've seen so far, but I did notice an issue on my end: I was trying the Review step-through option - both during the game and after the game.  During the game I would get an error message and crash, while after the game it would keep stating the results in a pop-up window (without being able to click through moves).  Was I doing something wrong or might this be a bug?

@Aurelian - Happy new year!

@HGMuller - Thanks for the detailed answer. I really appreciate it.

I'm not sure if you can answer this or not, but you mentioned retrograde analysis can be done "on the fly" instead of pre-calculated. Obviosly this saves storage space, at the small cost of more code.

Do you have any idea what is the most men on the chessboard that can exist where this strategy can be used? The reason I ask is that tablebases have been created for normal chess with up to 7 men, but the storage space required was immense.

Could some storage space have been saved by using retrograde analysis instead, or can the 7-men tablebase be effectivelly expanded by adding a retrograde analysis in front of it (thus getting info on 8-men positions).

Not sure if that would be easy to answer, but curious if you or anyone knows.

@V.Reinhart: there is a big difference between exactly knowing which positions of an end-game with a certain material composition are draws or wins in an unclear end-game (such as KPK), and knowing whether in general the material combination offers only very slim chances to be winnable (such as KRKB). (KBNK is always won, btw, if the initial position does not forcibly lose B or N bay shallow tactics.) To answer the first question you would need End-Game Tables. These can be built by retrograde analysis, starting from all possible checkmates with (subsets of) the given material. For end-games with 4 or 5 men, it would even be possible to do such analysis 'on the fly', instead of a forward search that engines use for normal play. They can also be pre-calculated, and stored on disk, so the engine can probe them.

Here we are talking about the simpler, and more general issue of recognizing the cases where the simplistic addition of piece values gives a misleading measure of the advantage. This typically occurs for positions without Pawns (or other pieces with decisive promotions). or with just 1 Pawn that can be destroyed by a sacrifice. E.g. KBPKN is pretty hopeless, because black can sac the Knight for the Pawn to convert to a dead draw.

In the Pair-o-Max fork of Fairy-Max I used the following general heuristic:

1. If the strong side has no Pawns, divide the score by 2
2. If in addition, his advantage in non-Pawn material is less than 350cP, divide the score by 8 instead
3. If the strong side has only a single Pawn, and will be less than 350cP ahead after the opponent sacrifices his weakest non-Pawn for it, divide the score by 4

These rules can be slightly modified by properties defined in the game definition:

• If the strong side has only a single piece, and it is color bound, it will be assumed to be worth less than 350cP for application of rules 2 and 3 , even if its normal piece value is much higher. (E.g. Bede (BD) or Adjutant (BDD))
• Pieces worth <350cP can be defined as 'mating minors', and the <350cP ahead rules will not be applied to a player that still has such a mating minor. E.g. Commoners (K) or Woody Rook (WD).
• Pieces can be defined as 'defective pairs', and having a pair of those and nothing else will be considered as worth less than 350cP. (E.g. Kight)
• Pieces can be defined as 'strong defenders', and then will be assumed to be able to hold a draw (dividing the score by 8) against a single Queen-class piece even through they are worth less than 350cP (so that the advantage of the Queen side can be >600cP). (E.g. Commoner)

Happy new year Vickalan :)!

Happy New Year to all!

Correct me if I'm wrong, but since ChessV plays variants wouldn't it be a monumental task to understand, and then code the conditions for theoretical draws by insufficient material for a range of pieces more than the normal set of chess pieces?

As I understand, in normal chess KNB vs K can sometimes be a draw with perfect play, but playing it correctly is not easy for either side. It is also a rare ending. Coding this in normal engines would be a lot of work for an ending that is almost never seen.

It's hard for me to imagine anyone coding all possible endings, for a wide variety of variant pieces and for different board sizes.

But if anyone has started to do this for any one variant, or a range of variants, I'd love to hear about it!

(the ChessV upgrade sounds interesting, and hope to load it sometime this year)

I don't know how much of that ChessV is doing. E.g. does it know that KNK is a draw? Or KNNK?

No, sadly it does not.  The automatic draw by insufficient material is the one official chess rule not yet implemented.  It wouldn't be hard to implement the chess rule exactly, but I try not to tackle these things until I can find a general solution.  From that perspective, I think this is a hard problem.  How would it know if a King + WA vs. lone King in Chess w/ Different Armies should be an automatic draw?  (I assume it should.)  Or King + 2 WAs vs. King?  (This one I'm not even sure.)

Of course a GUI would have to know the exact rules, to correctly declare game end.

Yup, this is why I care (although not enough to hold off on releasing Makruk until I get around to it, which could be a while because in terms of things that interest me this is not high on the list.)

Just like it isn't useful for Chess engines to keep track of the 50-move count, I suspect it isn't very useful for a Makruk engine to keep track of the count. Usually the draw point wil lie beyond the horizon at the point of conversion, and once it is committed to a certain end-game, it should simply try to win in as few moves as possible, like it always does.

The counting rule does thoroughly upset which end-games are won, however. So I guess it is mainly the drawishness detection that would have to be adapted. I don't know how much of that ChessV is doing. E.g. does it know that KNK is a draw? Or KNNK? In Makruk, the counting rules would probably make end-games KRPPK drawish. The simple solution would be to strongly discount the score in end-games with a bare King, so that the engine will simply refrain from capturing a losig opponent's last piece.

Of course a GUI would have to know the exact rules, to correctly declare game end.

ChessV version 2.1 released

Happy new year everyone! To kick it off in style, I present a significant upgrade to ChessV. It offers:

• A much stronger engine AI. I was really surprised at how much I was able to improve it. It is now even stronger than the old C++ versions of ChessV.


• A ton of bug fixes. Thanks to Aurelian Florea for spending a significant amount of time testing and reporting issues! Hopefully all of the existing bugs have been fixed.


• Several important new features:
  
  
  • Review Mode - it is now possible to enter Review Mode and step back and forth through any game whether finished or still in progress
  
  
  • Edit Position FEN - it is now possible to view the FEN of the current position, as well as set up a new position by providing an FEN
  
  
  • Multi-PV Analysis - it is now possible to analyze a position to find multiple best moves with their associated evaluations
  
  
  • Crash Reporting - any program crash should now provide an option to save a log file which will help me to identify and fix the issue
  
  
• Support for new games:
  
  
  • Makruk (counting rules not yet supported)
  
  
  • Chess and a Half
  
  
  • Modern Shatranj
  
  
  • Roman Chess
  
  
  • TenCubed Chess
  
  
  • Hannibal Chess
  
  
  • Compound Courier Custom Chess
  
  
  • probably others I'm forgetting ...
  
  
  
  
• New external engine - now includes SjaakII by Evert Glebbeek in addition to Fairy-Max (External engines are only included in the Windows Installer version)

I think I can help with the formalization part too as I'm a decent programmer and my best math thinggie is set theory which could help (although I assume here more modern category theory would be better). I don't have formal education on set theory (my background is in mathematical engineering applied to electric, and then programming-machine learning as a career, not academical), but I think I'm good enough. I'll find time :)!

I will just conclude here with the observation that the ChessV approach is not that different from what I do in WinBoard. There 'engine-defined variants' also must mention a 'parent variant', from which they inherit the rules.

Interesting, I will need to look at this.  I'm really not familiar with WinBoard, although I should be.  I am familiar with Fairy Max's ini format, SjaakII's format, ZoG format, and Game Courier format.  Which reminds me ...

When I was mentioning the people and projects that have contributed to programmatic support for chess variants, I neglected to mention Fergus and Game Courier.  GC is significantly different from other programs in this space, having a somewhat different use-case.  It has no AI, but it does support an incredible amount of variants, including hexagonal, circular, triangular, 3-D, etc., and is pretty much the only program to do so (besides the now-defunct ZoG.)  So in addition to you, me, and Evert, Fergus also has vested interest and should be included if he's interested.

Let's touch base after the holidays.

Cheers,
Greg

OK, good plan. For after the holidays. I will just conclude here with the observation that the ChessV approach is not that different from what I do in WinBoard. There 'engine-defined variants' also must mention a 'parent variant', from which they inherit the rules. It is just that developments after that have made it possible to define more and more aspects of the rules from scratch, leaving less and less to be necessarily inherited from the parent. Apart from board size and initial setup, the piece-to-char table made it possible to arbitrarily alter the participating pieces, and whether these have Shogi-like promotions, and to what they then promote. Piece commands made it possible to assign arbitrary moves to each piece image, extensions to FEN made it possible to specify different kinds of shuffling, defining a holdings size can add drops to any variant, and the piece-to-char table can specify how pieces demote on capture. So the number of parent variants that is really needed gets smaller and smaller, as they become more flexible.

Having different ideas is good; agreeing from the start would have no added value.

Ok, I certainly can't argue with that :)  This is definitely an idea worth pursuing.  It would be great if there were a common "game definition format" that is accepted by multiple engines and GUIs, even if it didn't address the more exotic variants.  Of course, our programs could also support "internal" variants - special games handled at a lower level either because it is necessary, or simply because the engine could be stronger if optimized for the given game.

What I am afraid of with the game-definition format it to fall victim of the "maximum-flexibility-minmum-usefulness principle". The overwhelming number of Chess variants and fairy pieces are very simple, and it would be a pity to force an enormously complex description system on the user to describe these, just so that it would also be possible to describe something very complex that they are never going to need.

Indeed, I completely agree with this also.  It's a challenging problem, and a difficult balance to strike, but that's also what makes it so fascinating!  And that is probably why you and I have both spent so much time pondering this problem for well over a decade :)

And it is always possible to use a basically simple format, like Betza, but define some 'escape' symbol that allows you to use a Turing-complete programming language to define what you want.

Yup.  I also agree that this problem is best solved with a multi-level approach.  If you want to make a "modest" variant that should be very easy.  Recent example: Hanibal Chess - Chess on a 10x8 board adding two FAs.  But it should also be possible to handle more complex things.  Another recent example, same author: Wide Chess - this could have been simple, but made complicated by the fact that, when castling, the king can now pass over attacked squares.  And, ideally, it should be possible to address things like this without having to resort to resort to really low-level ugliness (by analogy, the equivilant of dropping from JavaScript to in-line Assembly.)  How do we best square that circle?  THAT is probably the single biggest thing we need to figure out.

To maximize our chances of success, this should probably go beyond open forum discussion to something more formal... For example, find out who the interested parties are.  Then, before getting into details, come up with a formal statement of what the hell our objective is.  Then, we should each become at least somewhat familiar with the existing approaches we have already pursued or proposed to see the pros/cons of each.  The Betza 2.0 approach, for example, is *radically* different from the ChessV approach - which I will call the "inheritance" approach - where you define your game by picking the closest game, deriving from it, specifying only how your game is different.  (There are also abstract base "games" underneath everything, even Chess, from which you can derive.  Actually, there are several levels of abstract bases, each offering additional functionality, with configurable switches to deactivate and/or configure the new functionality.)  Our approaches are so different because of our backgrounds.  I'm a practitioner and true believer in object-oriented programming for about 25 years now.  You're not an OOP guy, so of course we think about these things completely differently.  Which is better?  Who knows.  Hopefully the best of both can hapilly co-exist.  Evert Glebbeek will be a valuable addition here since he has taken a middle-road.  He clearly understands and uses OOP, but hasn't gone nearly as far with it as I have.  Then there's yet another paradigm, Functional Programming (e.g., Lisp, OCaml, Haskall.)  I suspect this paradigm has a lot to offer in addressing this problem, but my brain just doesn't work that way, despite the fact that the University of Florida tried to teach me Scheme when I was 18 years old...  at the time, I probably wasn't open-minded enough and now, much later in life, I've tried but it's too late to start thinking that way.  Incidentally, the Zillions-of-Games definition language is basically Lisp, a Functional language, but theirs isn't a very good solution because they did not take a multi-level approach.  (NOTE: I do not mean to disrespect ZoG, they were the first people to ever attack this problem, and given that, what they were able to accomplish is nothing short of incredible.  It's a shame that they all completely disappeared.)  Sorry for the long-winded digression, what I'm getting at is that we should take some time to see what has been done and understand where we each are coming from before we get too deep into where we should be going.  A next logical step would be breaking it down into specific questions/ideas and studying those.  And what these questions/ideas should be won't be obvious until we've each looked into and thought about the work that you, I, Evert, and others have already accomplised.  Anyway, what I'm suggesting is that, to really accomplish this, we should have a process that is slow, deliberate, and formal.  Open-forum chaos isn't likely to grow the desired fruit.

What I would propose as a first step is to start a new thread on TalkChess (a more appropriate forum for chess programmers than this) proposing formation of a "working group" of interested people to work together to study this problem and work toward a solution.  This working group would, of course, include you, me, and Evert.  Possibly others who have worked in this area might be intersted, like Daniel Shawul.  We might also need to exclude people in the event that they want to jump in but have not worked in this area and have nothing to offer.  This will be difficult enough without disruptive influences.

Having different ideas is good; agreeing from the start would have no added value. What I am afraid of with the game-definition format it to fall victim of the "maximum-flexibility-minmum-usefulness principle". The overwhelming number of Chess variants and fairy pieces are very simple, and it would be a pity to force an enormously complex description system on the user to describe these, just so that it would also be possible to describe something very complex that they are never going to need.

Note that the Betza notation used by XBoard can describe Chess and a Half, although the side-effect captures of Cat and Star Cat no longer qualify as user-friendly. But a system that allows chaining of steps belonging to different Betza atoms, somewhat like the Betza 2.0 that I once proposed, would be a lot more user-friendly. Odin's Runes also doesn't seem to be out of the question. E.g. the Forest Ox just does igui + a Knight jump, which would be cK-bK-N, and that doesn't look very complex. In XBetza it becomes complex, because it forces all steps to be described by the same atom, which makes the Knight jump cumbersome (cabampafsK, where mpafsK is a kludgy way to express N in terms of two K steps, the first step made insensitive to blocking by allowing it to hop as well as move). So that is awfull, but the Betza 2.0 format seems acceptible. Activation by a friendly piece, like used for King, is already implemented in the Betza dialect used by the interactive diagram, as a move with a special 'x' mode of the activating piece, and would only have to be limited to a specified piece type (King). For which a general mechanism could be used, like I already did suggest for Betza 2.0. These are all things that are almost never needed, for which it thus doesn't matter so much that they are a bit complex.

And it is always possible to use a basically simple format, like Betza, but define some 'escape' symbol that allows you to use a Turing-complete programming language to define what you want.

What happened to Quaddrox? Did you integrate that in the new ChessV?

No, Quadrox is sadly sitting untouched.  Would like to return to it some day.  Quadrox is basically the polar opposite of ChessV.  It's C++ with careful consideration on how to make it as computationally efficient as possible, but can only potentially play a very limited number of variants.  ChessV is C#, inefficient as hell, and designed for almost maximum universality.  (I did make some limitations so the inefficiency wouldn't be totally insane.)

A lot depends on your motivation for doing this at all: whether it is just the pleasure of doing it and the satisfaction of having created something wonderful all by yourself, or whether the main drive is to advance the state of the art of computer chess-variant programming as much as possible. In the latter case it makes sense to cooperate and standardize more. E.g. there seems little reason to develop a new opening-book format; Polyglot books, also used by WinBoard for all variants it supports, are an open format, and being
able to interchange books seems a useful feature from the user perspective.

My motivation is definitely the latter.  I have no desire to re-invent the wheel, and want to standardize as much as possible, so long as such standards aren't too limiting.  I will look into Polyglot books.  I have some ideas about how to generate openings books.  During generation, (automated and/or human writing), the books will exist in a text format that is easy for people to read and edit.  But I envision them being "compiled" into a binary computer-friendly format that will probably be Polyglot format.

For scripting user-defined variants a commonly accepted move notation, such as Betza's, seems a good way to do it. It is still on my to-do list to change the game-definitions of Fairy-Max to a more user-friendly format; perhaps we should cooperate on developing such a format. Sjaak II seems to do this pretty well, btw.

This is something we're probably not going to agree on, but I could be wrong.  What you're considering probably fits into what I would consider "too limiting."  Simple table-driven engines aren't sufficiently universal.  You are probably not going to be able to play Chess-and-a-Half, for example, or Odin's Rune, without implementing a full-on scripting language (which is what I have although it's certainly incomplete in its present state.)  SjaakII format is flexible and nice, although some of the games SjaakII plays are "internal" and not derived from the configuration file because it is not flexible enough (for example, Omega Chess.)  That said, I'm happy to support multiple approaches so users can use a clean format that doesn't require any understanding of programming for those games it can handle.

EGT generation could be cast in the form of an engine that can be shared between GUIs just like search engines can.

EGT is pretty far down my list, honestly.  If we can have a standard format I'd love to support reading that database format.  But, truthfully, I'm probably not going to get to writing the actual generator any time soon, if ever.  What does interest me enough that I might start attacking it, though, is developing custom evaluation functions that allow it to play specific endgames better regardless of board size - KPK, KPKP, KRK, that sort of thing.  There are so many chess programmers out there that understand this stuff and could help out.  It's too bad almost none of them care about what we're doing :)

Implementing tournaments was surprisingly easy in WinBoard, if you already have the infra-structure for loading engines.  It took me only about a week.

Indeed, this should be fairly easy for me too, so it will probably be implemented before too long.

Cheers!
Greg

Still to do: hexagonal variants, variants with drops, 3D variants, support for vector-graphics pieces, more sophisticated engine functions like opening books, endgame databases, and multi-threading, improving the scripting language for user-defined variants, functionality for running tournaments, etc ...  Basically enough to last the rest of my life :)

Yeah, I know the problem. Life is just too short. And now there is AlphaZero, and we should perhaps learn to do things in an entirely different way...

What happened to Quaddrox? Did you integrate that in the new ChessV?

Implementing opening books is pretty easy; the problem is how to create them, in absence of huge databases of human quality games. A lot depends on your motivation for doing this at all: whether it is just the pleasure of doing it and the satisfaction of having created something wonderful all by yourself, or whether the main drive is to advance the state of the art of computer chess-variant programming as much as possible. In the latter case it makes sense to cooperate and standardize more. E.g. there seems little reason to develop a new opening-book format; Polyglot books, also used by WinBoard for all variants it supports, are an open format, and being able to interchange books seems a useful feature from the user perspective. For scripting user-defined variants a commonly accepted move notation, such as Betza's, seems a good way to do it. It is still on my to-do list to change the game-definitions of Fairy-Max to a more user-friendly format; perhaps we should cooperate on developing such a format. Sjaak II seems to do this pretty well, btw. EGT generation could be cast in the form of an engine that can be shared between GUIs just like search engines can. Implementing tournaments was surprisingly easy in WinBoard, if you already have the infra-structure for loading engines. It took me only about a week.

Even if a single person would occasionally use it the hosting company would shut you down.

That depends on your hosting.  Obviously, you'd need a dedicated server to do this.  I made the (possibly incorrect) assumption that server-side was what Jeff was talking about, because anyone who wants client-side can just download ChessV.  But .NET can run client-side also, just as Java can, so that could also be accomplished from the ChessV code-base without needing to mess with any of the code for the engine or game logic.  Granted, JavaScript has the advantage that you don't need .NET installed.

Anyway, I have no plans to write a web version.  Or a version for mobile phones.  For a single person working in his spare time, the project is quite ambitious enough without targeting other platforms.  Hopefully some day other programmers will want to help out but, although there are a lot of people who like to write chess engines, there are very few who care about chess variants.

Still to do: hexagonal variants, variants with drops, 3D variants, support for vector-graphics pieces, more sophisticated engine functions like opening books, endgame databases, and multi-threading, improving the scripting language for user-defined variants, functionality for running tournaments, etc ...  Basically enough to last the rest of my life :)

@ Greg: But you would not want to run something as CPU intensive as a Chess engine server side. Even if a single person would occasionally use it the hosting company would shut you down.

@ Jeff: indeed, for having a demo of a variant that gives realistic counter play, but is ot unbeatable for a novice, JavaScript should be good enough. This would be the use case for powering the Interactive Diagram with an engine. Not to provide GM-class analysis of user-provided positions.

@Jeff,

Yes, it does allow you to load a position by specifying an FEN.

@H.G.,

Yes, rewriting the engine in JavaScript would be hard, but it's not necessary.  ChessV is .NET which will run server-side on web servers just fine, even Linux servers using either Mono or Microsoft's own .NET Core.

Greg, that sounds great!  Thanks for the latest info.  Looking forward to V 2.1.  Does it allow you to setup a position and go from there, without playing through the game to get into that position?

H.G. you mentioned javascript vs. other languages' strength.  I guess that's a good point; it's probably silly to focus on computer strength for online engines anyway, since web games are mostly designed for human vs. human gaming.

Jeff

It would be quite difficult to convert an existing engine to JavaScript.It is still my plan to add an engine to the interactive diagram, but I am not sure that a JavaScript engine running in a browser could compete in strength with C/C++ or Java engines. (And besides, I am a bit distracted by other things, such as Alpha Zero and programming a retro computer.)

Hi Jeff,

ChessV is indeed still in development.  I will endeavor to get the next version (2.1) out by the end of the year.

The new version DOES have a "Review Mode" that allows you to easily step back and forth through games. It does not have any support for playing in a web browser.  The code is fairly modular, so it would be possible for someone to use all the code for the engine and game logic and possibly even some of the graphics for a web version, but that's not something I'm focused on.

In version 2.1, very significant improvements have been made to the strength of the internal engine.  There are also a few new features, a few new games, and a ton of bug fixes.

Hi Greg, I just wanted to see how development was going on your latest iteration of ChessV, which I'm guessing would be called Version 3.0?

If it's still in the works (or not officially planned) I just wanted to throw out some questions/comments about it.  If anyone already has a response for me, feel free to chime in if I missed something that already exists in V2.0

- Any ability to move foward and backward through the moves within the built-in GUI?  This would make playout of a game easier to analyze (or record for demo videos, etc.)  Animation preferred, but I could understand how that might be a hassle.

- Would a more univeral web-based version of ChessV be possible, or is that too much time/effort with javascript etc.?  I ask because the Jocly site has a lot of good web-based games, but their engines still seem very weak.

Anyway, this is coming from non-programmer - just some thoughts on possible improvements.  So far I think ChessV is proving to have the best engine for variants - especially those with altered rules.

I just installed chessV and I already really like it a lot! It uploads quickly, and installed with no problems. It seems like an awesome program. I like how games are categorized, making it easy to find games, and includes an index with each game's history.  Great work! I'm gonna really enjoy using it!

(I also saw Aurelian's Enep on it too!)

They are distinct programs.  Historically, chess "engines" have almost always been separate programs that run from a command prompt and communicate only by sending text in and out of the terminal.  The graphical user interface (GUI) is a separate program that provides a nice front-end to the engines and can control different engines because they communicate with standard protocols.

ChessV is a little different because it has an engine built-in, but starting with version 2.0 it can also control external engines, such as Fairy-Max, if they communicate with the XBoard/WinBoard protocol.  Note that most engines do not play chess variants, and even those that do will not support all the variants that ChessV does.

OK, thanks for answering. In a few weeks I might try ChessV.

I noticed the package includes Fairy-Max. Does ChessV and Fairy-Max share any code, or are they distinct programs?

Regards, :)

Unfortunately, I don't know of any such analysis, but it may exist.  I think Marseillais has been widely played.  Probably letting ChessV crank at it for an extended period is a reasonable place to start.

I have considered making a version of Cataclysm that has double-moves based on the restrictions of Extra Move Chess.

As an aside, ChessV doesn't do Extra Move Chess yet because of a couple of complications, the most notable being that the second move is optional and I have no user-interface for 'Pass' yet...

I noticed that ChessV plays two multi-move variants (Marseillais Chess and Doublemove Chess).

Does anyone have a good record of played games for either of these (either human play or computer play)? It seems the games are usually very short. I was wondering what the average length of play would be for games of these variants.

I've been thinking of trying a game of "Chess on an Infinite Plane" where double-moves are allowed, or maybe only double-moves of pawns, or pawn plus one other piece. A link to the game is here):

If anyone has info on analysis (computer or otherwise) for multi-move games I would love to learn about it!

Well done Greg!  It's interesting to play through different scenarios and even watch computer vs. computer for each variant.  I imagine people with their own large board variants are thrilled to see their variants here, since unusual board sizes aren't easy to find in physical form.

ChessV was around a long time ago, but I am new to it.  I haven't found many similar/reliable programs out there.  I've seen a couple variant mobile apps, but they all crash very easily, and the interface on them is difficult to use.  ChessV 2.0 has an easy and straightforward interface.  If I had to make one suggestion, it would be the ability to move forward and backward through the moves within the program itself (unless I'm missing the method of using other GUIs to do this).  Nevertheless, it is a lot of fun. Apologies to the CV administrators for rating this here, if I wasn't supposed to rate programs...

ok, thanks greg, when you say no griffin it is actually no griffin , yet!

1. If you create a new text file with a .cvc (ChessV Code) extension and throw it in the "Include" sub-directory, the game will be available.  There's no documentation in this but you can look at the samples, and the ChessV Source Code Documentation will be somewhat helpful as the interpreter is just a thin layer that dynamically finds c# members and functions in the underlying objects and routes calls to them.  It probably won't do what you're looking for, though.  You can make new games by deriving from an existing game that is close.  You can then change game variables and add/remove piece types, but you cannot implement new rules.  You can make new piece types, but only so long as the moves are supported by the internal move generator (so no Griffin.)

2. Not sure.  You're not giving me much to go on.  The installation program doesn't do anything except extract the files and create an icon on the start menu.  Try this: first, delete the Fairy-Max subdirectory of Engines/XBoard and try to run it.  If that doesn't work, delete the entire ChessV2 folder and re-run the installation.  Let me know how that goes.

Thanks,
Greg

Hello again Greg,

I have 2 questions:

1. How do I use the scripting language you mention?

2.I tried to install the program over what I have previously unzipped from what you gave me . It exited. What happened?

Thanks for including Butterfly Chess as an option, Greg.

Cool!

@Mats:

Actually, it does have this piece.  It's used in Grand Shatranj called the Jumping General.

@Aurelian,

Yes.  I will be adding support into the internal move generator.  It already supports chains of single steps/leaps, such as the Falcon.  I want to add a compound move that is a single step/leap followed by a slide.  That should handle Griffin, etc.

Hello Greg,

Are the griffin and aanca easier to implement in chessV2?

Mastodon jumps one or two spaces orthogonally or diagonally?  If so, that's easy, but I don't think I currently have anything using it.  It could be easily added with the scripting language.

Is the Mastodon/Pasha implemented? It is a very suitable piece for big boards. /Mats

ChessV 2.0 Release Candidate 2

After many years, ChessV is back with a new version, completely rewritten from scratch!

Version 2 has many improvements over previous versions, including:

• A vastly improved user interface with better graphics and more features


• In addition to providing an AI you can play against, ChessV 2 can also be used as a GUI to control other engines that support the XBoard protocol


• The program is now a .NET Framework application, allowing better cross-platform support. It can run on non-Windows operating systems, such as Linux, using Mono


• ChessV 2 is far more universal, allowing support for many more types of games. Here are some of the features with examples of games that are now supported:
  
  
  • Games with multiple boards (example: Alice Chess)
  • Games with multiple moves (examples: Marseillais Chess, Doublemove Chess)
  • Games with multi-path pieces (examples: Falcon Chess, Grand Shatranj)
  • Games with larger boards (examples: Gross Chess, Omega Chess)
  • Games with unusual symmetry (example: Viking Chess)


• A scripting language, providing limited support for defining custom variants without needing to recompile ChessV itself. This feature is in early development and subject to change. For examples, look in the Include directory. The following games included with ChessV are implemented through the scripting language: Almost Chess, Butterfly Chess, Enep,Janus Kamil Chess, and Latrunculi duo milia et septum

The trade-off for all these improvements is that the internal engine is not as fast as original ChessV and the playing strength is somewhat weaker. For really deep analysis, use of the old version, for games that it supports, may still be preferable.

Please visit the ChessV website for the latest downloads