The root folder of the source download should have the .sln Visual Studio solution file and associated project files (ChessV.vcproj).  You will need Visual Studio 2015 - the Community Edition is free.

The squares are identified by number, and they iterate first by file then by rank.  So adding 1 will go to the next file unless you are at the right edge of the board.  To advance one rank, add the number of files.

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

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

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.

Hello Greg,

Are the griffin and aanca easier to implement in chessV2?

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

Cool!

Thanks for including Butterfly Chess as an option, 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?

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

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

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

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!

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

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

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.

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

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.

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.

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

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

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

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

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.

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

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.

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.

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.

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

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

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)

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.

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

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)

Happy new year Vickalan :)!

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