Sam, your idea of having WinBoard force moves into an engine that refuses them by loading the engine with the position after the move works really great. I implemented in WinBoard now, under control of the option -forceIllegalMoves. In combenation with -testLegality false, this now allows me to completely autmatically play a Schoolbook-Chess match between ChessV and Fairy-Max. Now and then (about 10% of the games ChessV plays a non-standard castling, which then shows up in the PGN as Kf1h1 or Kf1b1, and Fairy-Max is simply restarted. It was a bit of a pain to implement it, because initially the engine will still think the opposite side is to move, and the WinBoard-protocol edit command (which Fairy-Max uses) does not alter that, and the commands that do are deprecated, so the side-to-move has to be flipped by playng a dummy move. But that works smoothly now.

In reaction to some earlier remark you made: there was no reason for hacking WinBoard to suppress the popup after a match: there is a command-line option that controls it (-popupExitMessage false/true), which is remembered in the WinBoard settings file. I use PSWBTM to play the match, in stead of the scripts you use, and this uses that option automaticaly.

I could not find the download on your web page nor in the Winboard forum.

This will make Schoolbook 2010 a lot easier to implement.

http://samiam.org/chessv

ChessV 0.95 Released

After many years, I am releasing an updated version of ChessV.  The previous version, 0.94 introduced a problem that actually greatly weakened playing strength from version 0.93.  This version corrects that issue and adds other speed enhancements which should make this by far the strongest version.

ChessV can be downloaded from my new domain www.chessv.org. There is no installation program.  Just download the correct version (32-bit or 64-bit), unzip, and run ChessV.exe.

Please note that, as some of you know, there is a new ChessV, version 2.0, rewritten completely from scratch that is forthcoming.  Hopefully I'll be releasing that in the near future too, but that isn't what this is.  This is a new version of the "classic" ChessV.  I don't know if there will be any further releases of the classic version, but since version 0.94 had issues, it didn't seem right to leave that unfixed.

Changes from previous version:

• Multiple bug fixes, including one that seriously impacted playing strength


• Addition of Late Move Reductions (LMR), an engine feature that will further enhance playing strength


• Added support for Enep by Aurelian Florea


• Fixed a problem with Ralph Betza's Chess with Augmented Knights that I only discovered while trying to use it as a template for Enep.  This has probably been broken for many versions.  Actually, this Betza invention is so obscure, I had to dig pretty deeply to find the chessvariants.com page for it.


• Updated the implementation of Joe Joyce's Modern Shatranj to reflect the new, simplified promotion rule.  Previous versions actually did support the complex rule, but it required a special class to implement it (I couldn't just use the standard class the other Shatranj variants use.)  This change allowed me to eliminate two files and over 100 lines of source code.  Thanks, Joe, for agreeing to simplify things :)

Please let me know if you have any questions or issues with this version.

Great news, and congratulations. It is a really good thing that you took the trouble to fix the bugs that were inadvertantly introduced in 0.94, because that had some interesting new variants not supported by older versions (such as Spartan Chess, and, IIRC, even Xiangqi.) Now you can terminate this ground-breaking project with a polished product.

I clicked on the link for the 32-bit version, but I got the 64-bit version instead (which doesn't work on my computer). Am I doing something wrong?

Oops, it was linked to the incorrect file.  Thank you for letting me know, Jospeh.  It's been fixed.

Thanks, greg for adding Enep!

Greg,

I just watched an Enep game where the Enep knight has captured with an wazir move, this is not supposed to happen, could you please check?

You're right, something is definitely wrong with that.  Thanks for letting me know, I'll take a look when I get a chance.

Thanks!

Hello again Greg,

I contemplating writing code for my upcomming (still in testing phase) apothecary games, but I see the way movement is implemented, that there is no easy way of implementing the aanca and griffin.

The move info contains rank modification, file modification and maximum and minimum number of steps from what I understood. Nothing about a second legged move.

Am I correct? Do I miss something?

Hi Aurelian,

Yes, you are correct.  I never added Grande Acedrix because the Griffon move isn't directly supported.  This would be tricky to implement in a general way.  It's not just being able to generate the moves - that's not too bad.  It gets more complicated with the IsSquareAttacked function used for detecting Check.  IsSquareAttacked starts at the square and "backs up" in every direction the game uses until it hits a piece or leaves the board.  If it hits a piece, it determines if that piece can move that far in that direction.  To support moves with multiple parts, the logic in IsSquareAttacked would get pretty complicated.  To see if a square is attacked by a Griffin, as it is backing up in Rook steps, for each step, it would then need to back up one diagonal step each way and check for a piece that can move like a Griffon.  Then there is the problem of Static Exchange Evaluation (SEE).  This gets even more complicated, but ChessV allows you to just turn off SEE for specific games.  Some of the games already supported have to turn off SEE.  It's not really necessary, it just makes then engine faster.

All that said, it is possible to implement the Griffon in ChessV if you are really dedicated, but it is probably more trouble than it is worth.  You can override the GenerateSpecialMoves function of the Game class to add support for moves that the internal move generator can't handle.  Most of the pieces from Ultima work this way.  (Look at the implementation of Chess with Ultima Pieces for an example.)  Then you also have to override the IsSquareAttacked virtual function as well.

You could also look at Postduif by Evert Glebbeek.  It was designed to play Grande Acedrix.  In its move generator, every move has a step/leap component followed by a slide component (either one of which can be zero to skip it.)  It may have problems with some of the other pieces or rules for Apothecary though.  I haven't looked at it in detail.

Cheers,

Greg

In Fairy-Max I use the ultimate robust way for testing whether in check: just run the move generator for the opponent, and see if it captures King. But that is slow. A more general fast way for detecting attacks would be to not start from the board but from the piece list, and check for every piece whether is is alligned with the King for checking based on a lookup table indexed by the relative position to the King.

Thanks, Greg

I'll attempt to implement apothecary in chessV, hope to succeed.

Greg Strong wrote:

"...You can open one of the Chess presets, click Edit to modify it, and just erase all the code in the seven boxes at the bottom to stop it from enforcing any rules.  Then, in the first box, change the name from Chess to Asymmetric Chess, enter your user id and password, and click Save.  It will give you a link that you can then use to send out invitations to play..."

As an experiment I tried doing this procedure for making a preset with a simple chess variant of mine called "Throne Chess" instead (same rules as chess, except playing K to K8 is an extra victory condition, "Thronemate"). I had some success, but I saw nowhere that a little PBM green box icon symbol for a Throne Chess preset had been created, with myself credited as the author. There was created a default file for Throne Chess, stored under my user ID, in Game Courier's programmer's file log system. Throne Chess was not showing as having, say, 0 games played for it so far under "All Games" in the Game Courier Menu though. I edited the 'settings name' from default to be called Throne Chess, later, along with redirecting the default file version to it, too, but still no little PBM green box preset icon showing anywhere upon searching the website. I'm wondering if I have to do something rather complicated, or beyond me, instead of my doing what was recommended to Dmitry, to get a little PBM green box preset icon to come into existence (without having to play anyone a game online first).

Hi Kevin,

Yes, there's another step to get the preset entered into the site index.  First, make sure you are logged in.  Then, from the pull-down menu with your name, select 'Post Your Own Game'.  Don't fill out the form on the first page, instead click the Create Game Courier Preset link.  Then fill out the forms.  For the form on the second page, you'll need the hyperlink to the preset to put in the description.  If you've lost the hyperlink, go to the play.chessvariants.com domain, and select 'Your Game Courier Settings Files' from the menu with your name.

Please be aware that the new submission won't show up in the index until approved by an editor.

Cheers,
Greg

Good luck, Aurelian, that is ambitious.  Let me know if you have any questions.

For detecting Griffon/Aanaca attacks in IsSquareAttacked, I would not back up from the target square.  Instead, I would find all Griffons/Aanacas of the color, go through them one-by-one and step out from them to see if they reach the target square.  If they don't attack the target square, you can hand off to the base class implementation of IsSquareAttacked to handle everything else.

Thanks Greg!

Greg,

Well, there are two main reasons I'm doing this.

1. Implementing the correct promotion rule that fairy-max isn't able to do (i.e. promoting to a minor on 8th rank, also a rook at 9th rank and also a major piece (queen,griffin,aanca, archbishop,chancellor),at 10th rank)..

2. Adding the fool (imitator) that mimics the last move of the opponent.

Not sure how to do those now but I got hints for the second from the mimotaur implementation.

Technical question:

Where is the main and the .prj file? Both would help! I need the main to be able to test my creations.

Hello Greg,

I don't understand the board representation.

What does nsquare +1 mean? Does it advance ranks or files? How do I advance the other one? I am assuming nsquare+nfiles for the next rank or something like this.

Thanks for your help!

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)

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

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?

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)

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

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.

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

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

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?

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!

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.

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

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

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.

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

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

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

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

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

@HG,

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

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

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

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

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

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

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

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

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

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

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

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

Fun stuff!!!

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

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

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

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

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

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

ChessV 2.2 Release Candidate 1

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

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

New Features/Improvements:

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

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

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

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

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

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

Bugs Fixed – Lots and lots.

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

Greg:

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

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

A smaller window said:

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

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

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

Hi Carlos,

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

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

Hi Greg:

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

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

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

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

Thank you very much for all!

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

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

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

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

Hi Greg.

Unfortunately the problem persists.

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

Model: 14-cm0026la

Name: LAPTOP-M9SUMFI7 

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

Installed RAM: 4.00 GB (3.88 GB usable)

Operative System: Windows 10 Home (1903 version)

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

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

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

What's going on?

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

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

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

Then try running ChessV.exe again.

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

Congratulations Greg. You have done an excellent job.

Thanks again for all your support!

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

Carlos,

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

Aurelian,

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

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

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

Nice video!

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