Happy new year Vickalan :)!

Happy New Year to all!

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

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

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

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

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

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

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

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

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

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

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

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

ChessV version 2.1 released

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

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


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


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

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

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

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

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

Let's touch base after the holidays.

Cheers,
Greg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers!
Greg

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

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

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

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

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

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

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

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

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

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

@Jeff,

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

@H.G.,

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

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

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

Jeff

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

Hi Jeff,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Regards, :)

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

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

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