Ratings & Comments

First I'm not sure why my original title for the subject has not held.

Anyway Jeffrey thanks a lot for discussing it.

Yes, I mean a new game indeed with more formal time controls (which we can establish), but the crux of the matter was to design a game with that in mind along with other features which should define nextchess. The disadvantages of "classic" bughouse is exactly what has got me into this. But the concept of a 2vs2 seems intriguing to me. It is just poorly executed here.

Ladybug is the name of a  supposed to be a variant, or more likelly a class of variants, as I think new bughouse should be (it's just my taste though), but more female friendly (hence the "lady" part)

. I think ladybug is a small insect.

Because it is a difficult task I decided it's better to make it a team effort. Ex-president Kenedy was not there for no reason either.

Short story I strongly believe that the computer almost AI era needs a reformation in what we call chess.

I think it's cool that you want to make it more female-friendly, but I'm not sure that the name change and having teammates sit across from each other is necessarily enough (or apparent enough to cater to female players).  Nevertheless I do still like those two ideas.  It's a nice combo of "lady" and "bughouse."

I'm not too concerned about specific time controls as much as move order rules.  I'm not sure what other bughouse variants there are, but my understanding of the present form is that two games are running on their own time, and each player just suddenly receives the captured pieces from their partner's game, available to drop.  Without a specific move order it's a lot of wild and crazy luck and/or waiting strategies (unless I'm missing something about the normal bughouse rules).

I will add that I like the 8 stone chess idea.  Maybe the 8 stones (or however many you use) can be the job of the teammates.  One person gets the pieces, the other gets the stones.

I tried again, and said 'yes' to making a move it had marked as illegal (my castling). After that, I was allowed to castle. So, apparently no fix to the preset is absolutely necessary.

I see 12 moves and only 5 cards. How are moves distributed on each card ?

Hi Aurelian, there are 16 move cards (frog and rabbit are on different cards, same for horse/ox, goose/rooster, eel/cobra), but only 5 are selected for each match. I will clarify this, I see now that my presentation was a bit vague

Hi, H.G.  It's good to hear from you and to hear that you are working on another engine to help test these things!  I got distracted on other things and never got around to following up.  I have far too many different projects that attract my attention - usually chess variant stuff, but sometimes other things as well.  I found this programming language for writing interactive fiction (think Zork) where source code reads like English called Inform7.  I would not have thought it possible for a real programming language to be a subset of English.  Wild stuff.  But yeah, anyway, I get sidetracked a lot :)

First, I did complete the FIDEs vs. Nutters test with the FIDEs given added incentive to move forward through the PST.  This helped a tiny bit, but not much at all:

Nutty Knights: 261
Fabulous FIDEs: 84
draw: 55

My next thought is to reduce the value of the knight and bishop when facing off against the Nutters.  This will give the FIDEs a strong desire to trade off and the Nutters will have to limit their options to prevent that.  Once the minor pieces are traded off I think the FIDEs are fine.  I don't believe a charging rook is better than a normal one, although a colonel may be a little better than a queen.

I have recently switched back to trying to get the next version of ChessV out.  I have several new features that are mostly done that just need to be closed out.  (Of course, I don't always finish a feature before starting on the next ...)  The most siginificant of these is that I have added a stand-alone ChessV CECP engine so it can be run without the GUI.  This code is all written but almost completely untested.  I admit I've been procrastinating on that.  In the whole scope of this project, there is nothing that is less appealing to me than trying to plan/code/debug for inter-process communication.  The other side of the coin - ChessV's ability to host other XBoard engines is not 100% bug-free either, although it is certainly good enough to be usable.

The material hash is something else I've added but am not making much use of yet.  It is implemented as you describe, and will handle binding of any kind such as your even/odd file example.  I think it was here I described the recursive algorithm I used to find all the different 'slices' of the board for any given piece.  (I'm calling them slices rather than colors because colors becomes confusing when different pieces have different bindings - the knight in Alice Chess being a wacky example.)  It will be interesting to see what scientific testing determines colorbinding bonuses/penalties should be for multiple color-bound pieces.  Currently, ChessV starts discounting the value of pieces heavily starting with the second piece bound to a slice if there are no pieces on a complimentary slice.

Regarding enabling CwDA for inter-engine play, yes, I am definitely interested in figuring out how we can do this.  I am certainly of the opinion that both our GUIs and all our engines should be as inter-operable as possible.  I will post some thoughts about this shortly.  (I'll start a new thread for it.)

That is purely a Fairy-Max problem. It has a pretty sloppy CECP parser, which doesn't bother to recognize most commands that require no processing (e.g. accepted, rejected, computer). 'Result' is also a no-op for an engine that doesn't implement learning. A GUI should not worry if an engine complains against non-essential commands. I think WinBoard only reacts to rejection of time/otim commands (concluing that it must be ealing with GNU Chess, and refraining from sending these commands for the rest of the game), and 'analyze' (informing the user that the engine doesn't support it, for the benefit of WB v1 engines that haven't announced this in advance through a feature analyze=0).

Ok, good to know that I don't need to worry about that.  I was wondering because I have been experiencing some stalls when running ChessV vs. Fairy-Max games in batch mode and it only happens when Fairy-Max declares a draw and then only sometimes.  I don't think it's related to this issue though.  So I'll have to keep digging.

Regarding playing CwDA through CECP, this game presents some interesting challenges, most notably army selection.  Given the current state of affairs, there are two obvious approaches, but neither is great...

1.  We could consider each army match-up to be a different variant - FIDEs vs. Rookies is one variant and Rookes vs. FIDEs is another.  This is a little cheesy and leads to variant explosion.  Essentially CwDA becomes two to the power of the number of armies different variants.  That said, this is probably the easiest.  I think ChessV can do this now with no modifications to the code at all.  We could always start here and be up-and-running in no time and just back out these "dummy" variants later.

2.  We can do what you are doing now - have engine paramters for army selection.  This is arguably better, but I don't love this option either.  We are adding engine-level settings for things that only apply to one game.  This is somewhat cheesy, unintuitive, and doesn't scale well.  What if we have a different variant that also has army selection but different armies for choices?  What happens when we start adding configuration parameters to other variants?  (ChessV already has configurable game-specific options for other things, such as the castling rule in effect in Capablanca variants.)  I don't mind altering ChessV but when I add things I always try to add them in a general way.  I'd rather not add code just to "hack" this one specific variant.

I think what we want - ultimately - is a new concept.  ChessV has "game variables" which are configuration options that apply only to specific games.  Conceptually, this is exactly what we are trying to accomplish.  Ideally, CECP would be given a new feature which engines could declare support for.  If an engine announces support for game variables, the GUI could then ask it, for any given game, what options it supports.  But I realize that this requires significant changes to XBoard/WinBoard, and it is probably no small undertaking.  But I think it's something worth striving for in the long term, and would pay dividends down the road.

Actually, we might be able to get there with the first step just being naming convention.  If we make "cwda" to be the Chess with Different Armies variant, maybe the options could be named like "@cwda:White Army", for example.  At first, WinBoard could just treat them like any engine options.  But in future, it might parse the option name to understand that it only applies to variant "cwda".  Just thinking out loud here ... haven't considered it deeply.

Fairy-Max currently also uses approach (1), which doesn't require engine or GUI to be aware that there is some relation between the 'sub-variants'. It uses the general 'engine-defined variant' mechanism for this, where it can just make up any name it wants and tell to the GUI that it plays it, after which the GUI makes it available for selection by the user. And when it gets selected the engine sends details like board size, pieces and moves to the GUI. Before that it did something similar by using 'fairy' as wildcard variant, where an engine-defined option then could select what 'fairy' actually meant (and a similar flow of rule info to the GUI when it got selected). Like you, I am not very happy with the resulting variant explosion. (Although this is not so bad as you say, just N^2 instead of 2^N.) Even with the 4 'standard' armies it overflows WinBoard's New Variant dialog with 'FIDE-Nutters' and similar variants. So I put them at the end, and kept in the old selection mechanism through an option.

So for the new engine I try to find something better. For an engine dedicated to CwDA the per-player option for army selection is a logical choice. But, like you say, if it really is a general multi-variant engine, it could lead to an explosion of options meaningful in only a single variant. I also found it quite annoying in practice that I have to set the option on both engines, when doing engine-engine games.

An explicit method for defining variant-dependent options like you propose would be a possible solution. An even more general case would be where options presented to you by the GUI would depend on the setting of other options. Processing the option definitions that the engine sends at startup in XBoard was not limited to the handshake phase, but originally it was not possibe to redefine or remove an option once it was defined, as newly received option features were always appended to the option list. But to make this behavior useful I made it such that receiving 'feature done=0' clears the entire list of options for that engine in the GUI. So an engine can redefine its options at any time. The application I had in mind was that engines could send a minimal set of options by default, including a button 'Advanced', and when receiving the activation signal for that option, resend a more extensive list of options (perhaps including a 'Minimal' button to switch back to the minimal set). Or even have several 'submenus' selectable by buttons from the base dialog (e.g. Eval Parameters, Search Options, EGT Options) each with a button in them to return to the basic list. Other applications would be 'collective' options that alter the setting of other options (e.g. 'Restore defaults'); the engine could then resend the option list not with different option names, but with different defaults, to make the GUI aware of the new settings. Main problem with this in the GUI is that the settings dialog gets redefined while it is open in such cases, which I think I tentatively solved by simply closing it (not sure anymore). If a change of option list occurs due to selection of another variant, that problem would not exist, as the settings dialog would be closed at that time.

Now from a protocol point of view this is a rather inelegant solution. But it is very general, and it works. A multi-variant engine at startup can only declare its general options (e.g. 'Resign Threshold'), but on reception of a 'variant' command resend those (starting with done=0) plus all options specific to the specified variant. If the user would then open the settings dialog he would see the new options. The engine would have to be smart enough to suppress resending of the option list if the variant did not really change, though, to prevent that clearing the list would make the GUI forget the previous setting of these options. Or be smart enough to make the previous setting the new default when it resends the list. (Not entirely trivial, as the 'new' command formally switches you back to 'variant normal' at the start of every game. So it should remember the argument of the latest 'variant' command, and on reception of a new variant command compare with that, and redeclare options only if there is a change that would lead to a change in options.)

It also seems CECP is in need of a mechanism for engine-defined options that work on both engines. Normally the corresponding features would be controlled by standard options, which might even use a different syntax (like 'feature memory=1' to set the hash size). But for features the GUI is oblivious of this cannot be used. But if the engine could define an option as 'slave', the GUI could send any change of the value to the other engine as well (provided both engines declared it). You could then change their value in the dialog of either engine, while the GUI would guard the consistency of the settings.

The castling issue is a good example of the different design philosophies that are possible, so let me respond to that first. If an engine supports Capablanca Chess, it is unlikely to support flexible castling. The only reason why the author would care to support such castling is that he is aware of Scholbook Chess, and wants the engine to be able to play that too. But if he wants that, why would he want the user to alter the start position (through setboard) and the castling rules (through an option) separately? It would be much simpler, for him as well as the user, to just add Schoolbook as an additional variant the engine can play. If there are other 10x8 variants that use flexible castling, but have a different start position from Schoolbook, these could then be played as sub-variants of Schoolbook (through setboard). Variants without castling are sub-variants anyway, as you can simply specify a start position without castling rights.

Having a castling option is a step towards defining the variant for the engine through option settings. If you have an option for castling, then why not one for how the super-piece moves (Queen / Chancellor / Archbishop)? Or options for how any piece moves? Or how large the promotion zone is? Or what you can promote to? (To play Janus as sub-variant of Capablanca.) This would all be possible, of course; it would converge on a design where the GUI manages all game descriptions (be it hard-coded or through a configuration file that the user can edit), and then instructs an engine how to play it.

This is not how existing multi-variant engines such as Fairy-Max, Sjaak and Nebiyu work, however. These manage the file with game definitions themselves. Which seems the logical way to do it, as then the file can also contain engine-specific info. (Like which pieces have mating potential, value of pair bonuses etc.)

Because of the way XBoard started (as merely a graphical front-end for an already complete ASCII-based user interface) things tend to be 'engine-centered' in WB protocol. From the early days on XBoard could already be used to play variants (as long as they were 8x8 with no more than 6 piece types, such as Shatranj) by switching legality testing off. (In fact in the earliest version it could not even be switched on, as legality testing was not implemented at all. Even when I first started working on WinBoard myself in 2008 it did not know about castling rights, and would always accept any castling.) Historically it was up to the engine to refuse moves it considered illegal, on which the GUI would retract the move and relay the info to the user. Downsite of this is that the GUI cannot indicate target squares of a move when pieces might move different from normal, and that it will generate crappy SAN (with missing or redundant disambiguation, but which it would still understand itself on reading it back).

I generalized the 'legality off' capabilities a bit by attaching a meaning to some otherwise unused combinations of mouse clicks; e.g. any sideway move of a King by more than 2 spaces is now interpreted as an attempt to castle with the corner piece in that direction (whatever it is), while dragging the King on top of the corner piece would be castling with it where the King steps one. (In all cases the corner piece ends up on the other side of the King.) Unless Fischer castling is specified by a GUI option (which by default is set for FRC and CRC), then capturing an own backrank piece with the King indicates castling with that. This covered all cases I was aware of, so the GUI doesn't really have to know the game rules to interpret the user move; assuming that what the user tries is legal, it will interpret it correctly. The engine watches over the latter, by forcing the GUI to take back whatever illegal thing the user might have done.

For better GUI performance w.r.t. SAN and target-square highlighting, however, it is essential that the GUI is also aware of the rules. Logically there are 3 ways to accomplish this:

1. Both the GUI and the engine are programmed / configured for the same rules independently.
2. The Engine transfers the rules to the GUI
3. The GUI transfers the rules to the engine

Your castling option is an example of the latter; through engine-defined options any info can in principle be transferred in this direction, but some standardization would have to be developed to make it possible for the GUI to do this automatically (rather than having the user decide on a per-engine basis what is necessary). For the start position the protocol has the setboard (or edit) command. For case (2) I extended the protocol with a 'setup' command as a reverse setboard, (plus a list of participating pieces) and 'piece' commands for defining piece moves.

Fairy-Max and Sjaak || use method (2); their game-definition file specifies how castling is to be performed, and (if this is non-standard) they inform the GUI of it as part of a King-move definition, e.g. "piece K KisO4", where the isO4 is the XBetza notation of a castling where the King moves 4 squares. Through this info XBoard itself can then already refuse any attempt of the user to move the King other than 1 step or slide it 4 (if still virgin etc.) without first consulting the engine. (And does this by not even highlighting other King destinations, and in general refusing any move to a non-highlighted square.)

I guess we agree that method (1) is undesirable; this was basically the situation that existed before introduction of the setup and piece commands, where the user had to provide a FEN (and even in an indirect way, as a .fen file with a GUI option referring to it) and a -pieceToCharTable option to specify the FEN's meaning, and switching off legality testing when standard glyphs were used to represent exotic pieces not in the standard set. For the case of castling it seems to me that method (2) is more direct than (3). In all cases the engine would have to announce something to the GUI at startup, either that it has a castling option that features 'flexible' as a choice, or just that it supports Schoolbook. In the case of the option the GUI will have to recognize it, look up in a list of known variants which variants would need any of the available settings for that option, and enable selection of those variants by the user (if their other requirements are also satisfied). In the other case it can just enable selection of 'Schoolbook' without having to worry about anything, or even know what 'Schoolbook' means. When the user decides to select Schoolbook, in the case of the option the GUI would now have to set the castling option in the engine to the value it knew to be required for Schoolbook, as well as enable that type of castling in its own move generator used for legality testing / square highlighting / SAN parsing and generation. In method (2) it would just configure its move generator likewise because the engine tells it so through a piece command. Again, it did not need to have any pre-programmed knowledge for that. The 'piece' command can be considered in this case just as a (somewhat cryptic) command to set a GUI option for the type of castling. This is much less of a hassle for the GUI.

I am perfectly happy with XBoard being a 'dumb' GUI, which leaves the engine in charge. But if you want ChessV to be a GUI that knows about many variants, and makes conclusions about which variants not explicitly supported by the engine can still be played as sub-variant of some other, supported variant, method (2) would still allow you to do it. In all cases the GUI would look which variants the engine supports, and what aspects of variants the engine allows to be changed in general (startposition by setboard, possibly other options), and then can run through its list of known variants to see which can be run as sub-variant. It doesn't really matter if a 10x8 variant has to be run as Capablanca + setboard + castling=flexible or through Schoolbook + setboard. If you want the GUI to have intrinsic knowledge of what Schoolbook is, it can simply ignore setup or piece commands the engine sends to specify start position and castling type.

As to the selection of armies:

We definitely agree that it is useful to have options that are common for both engines. Putting some common prefix, and perhaps an agreed-upon special sysmbol in front of a set of option names is always possible, and doesn't interfere with any interface that would not treat it as special.

The main thing I worry about is that army selection in CwDA, and even more clearly selection of the 'guest pieces' and where they have to go (as replacement or through gating) in Superchess and Musketeer Chess, setup of the super-pieces in Metamachy, are all really parts of game play. According to the official rules of those games there is a prescription for how the players negociate an initial position. In the XBoard implementation of Superchess I dodged that problem by implementing it as a shuffle game; my justification for that was that this 'game prelude' is really a work-around for human-human games, where there is no third party that could make the decision for them in an unbiased way. When a computer is involved, it might as well make the decision for them. If they don't like the proposed setup for a human-comp game they can just keep pressing 'New Game' until they do. If comp-comp games need a specific start position you just play them as games from a setup position, and provide the desired FEN to the GUI that runs those games. Jocly, OTOH, takes these game preludes seriously, which makes the implementation of the mentioned variants enormously more complex, involving a lot of non-standard code. (Where other variants are implemented by simply giving a list of piece properties and their start location.)

For CwDA the issue is a bit more subtle, as there are potentially so many armies (even the Wikipedia lists many armies I had never heard of) that it is impossible to give the pieces a unique 1-letter ID. So which army the engine has to play with cannot be unambiguously specified through the FEN in a setboard command, even if the GUI would make the army selection at random.

Historically WB protocol contained a feature that would allow user-engine dialogs as needed in a prelude: the askuser command. This is equivalent to a single string option: in response XBoard will pop up a dialog where the user has to enter a text, which will then be sent to the engine on 'OK'. In the latest XBoard I tried to expand the possibilities by allowing the engine to request opening of its entire settings dialog (as defined at that time) 'spontaneously'. So it could redefine its option list to define a dialog for the purpose, starting with feature done=0 (to temporarily remove its normal options), and end with done=2 (the forced popup request). This could have two comboboxes in it for the available armies, or (for Musketeer chess) comboboxes for selecting piece types and the files at which they would gate, etc. Problem is that such things would not work in automated engine-engine games unless the GUI itself would be able to set the presented options. But in WB protocol the engine can know if the opponent is a computer, and then refrain from requesting the popup, and use the default values, or the values previously given for those options.

Things are really ugly if the rules for the prelude require the players to take turns on selecting things; in a human-comp game you would then have to go through a sequence of dialogs where the engine each time says "I did this, now what is your next step?", before we can actually start moving pieces. And what if it makes sense for the engine to really think hard about its decision? Should its clock be running?

I got the impression that you would like to have a separate dialog for setting the variant-specific options of the engines, which perhaps pops up automatically after you selected the corresponding variant. This would be feasible for CwDA, but in view of the above I wonder if it would be sufficient in general.