Ratings & Comments

@Kevin

I had played Arimaa. There is not anti-cheating policy besides just saying don't do it :)!

As far as I know until now it worked :)!

For cyborg games the goal should be that the human players should make the final decision based on huge amounts of properly presented raw data.

The human  part of the cyborg skills are not the same as sole human skills so I'm not sure if not establishing and elite in that setting plays any major part.

Today chess computing heads more and more towards machine learning.

And Kevin, one more thing about cyborg chess. I'm not sure how you would guarantee equal hardware usage. I guess you can make it a rule that everybody uses the same engine which is distributed very shortly before the competition starts so it won't be hacked. And it is also checked to be ok after each round. But this at first glance at least has the downside that everybody must use the same engine. I believe I can get around this but it's complicated to explain :)!

Why not? The back rank pieces are neat.

But your games do give me a feeling of more of the same.

Hi Aurelian

The back rank pieces are the same compound pieces I used for Sac Chess, plus a couple more compounds that I figure are both in between a queen and an amazon in value, on 8x10. However, I used all the compound pieces only once each, for this (Officer Chess) variant idea. The main issue I have is that the setup (the back ranks at least) is arguably rather ugly, but I had a reason to put just about every piece on those ranks where they are. Earlier I had tried to use each compound piece twice, on a 12x10 board, but the setup always had lots of pieces menacing towards the opponent's pawns right from the setup. With Officer Chess, that just happens with the edge pawns, though even that is worrying, if I want kingside castling to seem safe to the players much of the time.

For a while now I've run out of fresh ideas. One thing is, I don't have the technical skills (nor the burning desire to get them, if hard study required), say simply to be able to make a game with a random starting setup (e.g. on the back rank), nor how to make brouhaha offboard squares, for example (not that I have any clue on what new game I might ever use them for). Being able to have rules-enforcing presets for games would be good, as I suspect such games get played a lot more. However, again it's a matter of skill and not much desire to get it (there's also that I'd hate for a bug to come up if people played such a game of mine, if I wrote the preset, whether or not I was still coming to CVP website at such a time). Otherwise, I'd like it if Hannibal Chess and Frog Chess had rules-enforcing presets, for example. Meanwhile, more complex Ultima-style or wargame-style CVs are beyond my design imaginings right now, nor would I know how to upload any special graphics if necessary.

On a seperate note, I've sent you 6 personal GC invitations, if you haven't noticed yet, and care to accept any.

Too many super-pieces, too few minors, for my taste. IMO, if a chess variant contains an Amazon, it already sucks.

I just see a few useless pieces. 1 rook, bishop, and knight (the standard ones) are superfluous. You already have one of them and then a king compound of the same piece. And if you remove the amazon you can get rid of four and it may make it easier to slim the game down evenly (even if I do like the piece and would love to see it in there somehow if it can be done without resorting to a weird board shape). 

 

But other than that it seems fine. I'd just simplify it that little bit and probably put the king in the back to allow for some castling. Then it's a little more like regular chess, albeit with a compound of every piece. 

Edit: you can also replace the pieces. Alfils, a man, etc. Assuming you want the same piece amount and don't want to mess with that much.

Thanks for the replies guys, however critical. The theme I had in mind with this Officer Chess variant idea is basically the same as what I had with Sac Chess, namely the standard chess pieces plus the classic compound piece(s) (i.e. crowned or knighted versions of the standard chess pieces). For Officer Chess I added in two more compounds, each triple compound pieces, to try to logically complete the classic bunch of crowned and knighted compounds (plus standard chess pieces).

As I wrote earlier, I originally wished to have two each of all the compounds (not counting the queen by itself), but that didn't work out on 12x10. It could work out on 12x12, but as a rule I don't think that board size would be remotely attractive except when played online rather than on a physical board. Not only that, but on 12x12 the Ns have rather a short reach, and somehow I'd rather have more camel/wizard type pieces, as in Gross Chess, which is a fine game (for online at the least, indisputably in my eyes). Also, a game played of a 12x12 version of Officer Chess might last way too many moves on average if played well enough, I fear, if armies of 36 units each are used. Note that castling is possible, along the second rank, for the (8x10) Officer Chess idea I'm still contemplating, though my doubts are now increased. Substantially modifying it would take more thought and work though, and it would become a different variant idea altogether.

With Officer Chess I had some hope of doing something fairly quick and dirty, else just forget it (or modify after a taking a break). Note that the popular (10x10) Sac Chess has not one but two amazons per army. I thank H.G. again for putting together a software package long ago that included that variant, though perhaps he has had a change of heart since regarding the merits of that game. Fergus has favorited it on this CVP website, which I consider a considerable endorsement, especially as Fergus also has the customary inclination to avoid including amazons in any variant as a rule (at least such a powerful piece type is on a considerably large board, in the case of Sac Chess). Aurelian's support for the (8x10) Officer Chess is encouraging, if I have any lingering doubts about just junking the idea, which is basically Sac Chess on a somewhat smaller board (perhaps allowing for shorter games on average, which is a plus). I'm not afraid to use a lot of super-pieces, as in chess major piece middlegames and endgames are often very exciting, for both players and spectators - and may lead to more decisive games.

Kevin if you want to play against me (Officer Chess)  Invite me.  I'd be glad to run prototypes (tests).

 

 

Thanks for the offer, wdtr2. I'll try to get around to making an unofficial preset for my (8x10) Officer Chess idea when I'm a bit less tired and also have more time.

Here's another version of my (10x8) Officer Chess variant idea, which I may have rejected too fast - I'll study it at my leisure. It might be called (12x12) 'Brawl Chess', and again is a kind of extention of my popular (10x10) Sac Chess variant. Castling would be done on a player's second rank with either unmoved rook, with the unmoved king going 3 squares sideways. Pawns would move as in Omega Chess, i.e. initial double or triple step allowed (as are en passant capture possibilities). Pawns would promote on the last rank, to any piece type in the setup (except for king):

[edit: 22-Nov-2019 {edit: may be too harsh on this CV idea here}: Currently I don't like this idea much, as I think games might take way too many moves on average, if well played, and in any case it might take awhile in a game before the two sides begin to really come to grips in earnest. edit2: besides the 2 diagrammed ideas shown here, and in my previous post in this thread, I have 12 other variant ideas I'm still looking at now & then - these I mentioned in an edit to a posted comment about the Chess Variant Inventors page.]

[edit: 23-Dec-2020: J-L Cazaux has since invented a 12x10 CV {Very Heavy Chess} that uses the same piece types as in the above CV idea]

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.

For what it's worth, here's a link to a CVP page showing games invented by one of the (possibly few) female members of CVP. Granted, the games may not reflect what the vast majority of female chess variant players might wish for in CVs that they would often play:

https://www.chessvariants.com/index/mainquery.php?type=Any&orderby=Type&displayauthor=1&displayinventor=1&inventorid=CBagleyJones&usethisheading=Items+Invented+by+Christine++Bagley-Jones

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.

Sorry it has taken so long to get back to you on this.  A lot to chew on here.

First you mentioned engine-defined variants the GUI doesn't understand but still allows to be played.  ChessV doesn't do this, and it's not high on my list of things to do, but there is certainly some value to it so it would be best if whatever we settle on supports this.

Then you mention my game variables concept and the more general concept of allowing engines to suppy additional options as things change (variant selected, other options selected, option buttons clicked ...)  Certainly the more general concept has value, but I also think there is value in being able to specify that an option is a game-specific variable.  This would make clear that, not only does the option only apply to a specific game, but that the option affects the rules of the variant being played and not just the internals of the engine AI (although it could certainly do that too.)  This tells the GUI that, in order to play, both engines must support the same options, and both should be automatically set to the same values after the user selects them.  And I think it makes sense that these options should be presented differently because they are an essential part of selecting what game is being played.  In ChessV when you select Chess with Different Armies, the first thing you get is a dialog box to pick your armies with random armies pre-selected.  (The same thing happens if you pick Fischer Random Chess - you get a dialog with a random position number selected, with a preview, but you can change it if you want to play a specific position.)  I think game variables can offer a better user experience - if you don't care about, or even don't understand hashtable size, etc, who cares, but you better understand what the armies are.  Picking the armies is part and parcel of picking what variant you want to play.  And, also, some engines might play CwDA and offer extra armies that others do not.

Another thing I like about game variables it the potential they offer to allow an engine to play variants it wasn't specifically designed for.  ChessV has some understanding of this now.  If the user selects Corridor Chess, it is smart enough to offer as options any engine that supports both orthodox chess and the setboard option.  Likewise, if it offers variant capablanca and has setboard, it will be offered as an option for Modern Carrera, but not for Schoolbook because of the flexible castling.  (You did propose a clever workaround for this but I haven't got around to implementing it.)  But engines that support flexible castling should offer the "Castling" option of "Flexible" in variant capablanca.  Then, even if they don't know Schoolbook, Grotesque, or Ladorean, they can still play them, along with new variants that meet the same rules.

10x8 is popular, in the sense that there are lots and lots of variants, but almost all use one of a few castling rules, which I have named "None", "Standard", "Long", "Fexible", "Close-Rook", and "CRC".  Likewise, on a 10x10, there are only a handful of castling rules, and a handful of rules for the pawn's multi-step moves that cover most games.

About a year ago you mentioned working towards a standard for defining variants so you don't have to configure Fairy-Max in one way and SjaakII in another.  I think this is also worth pursuing - it would be awesome if we could acheive it, but this is a steep mountain.  I respectfully suggest that this would make a good first step.  This is the low-hanging fruit...

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.