Tamerlane Chess

[Evert]

Having the engine direct the GUI is contrary to my primary approach - the GUI knows everything and enforces everything. I've spent literally years coming up with the best object-oriented architecture I could devise to make addition of new variants as simple as possible. Pieces, boards, rules, are practically plug-and-play (or as close as I can get.) Adding support for the overwhelming majority of variants should take a matter of minutes.

That said, adding all variants isn't likely to happen, particularly really strange ones, so allowing it to go the other way, (the engine knows the rules and gives low-level directions to the GUI), makes sense as an alternative. I will need to add some sort of "alien mode" for supporting arbitrary variant the GUI doesn't know about. This isn't likely to be in the first version, though. All the winboard-automation code is ported from CuteChess, which wasn't designed with this kind of communication envisioned, although the CuteChess code is super object-oriented and well-designed (which is why I chose it) so it should't be too bad.

At some point you have to draw the line and limit yourself. You can't design something that will play everything.

For SjaakII my design decisions and limitations were

• Up to 16 ranks or files, boards with up to 128 squares
• Up to 16 piece types (later expanded to 32)
• Indeterminate number of royals
• No build-in preconceptions of piece types
• Allow drop moves
• Pieces are leapers, sliders or steppers (=restricted WF sliders), or compounds
• No location-dependent move options and restrictions, with one possible exception per piece (to accommodate pawn pushes and castling moves)
• Flexible promotion zones
• Different rule options can be activated independently (repetitions allowed/not allowed, drops allowed/not allowed, pawns can be dropped to give mate or not...)
• All information needed to make a move must be encoded in a 64 bit integer

This is sufficient (with appropriate rule options) for it to play Chess, Shogi, XiangQi, Capablanca, Makruk, Shatar, Seirawan and a host of historic and modern variants, including Omega Chess (which needs a trick to make work because a naive implementation needs a 12x12 board). There are things it cannot do though, which I think is a good thing.

[kbhearn]

Question - what development environment do guys use for your C/C++? I'm using CodeLite at the moment, and it is acceptable. It's a big step back from Visual Studio though (the only Windows program I really miss.) I tried Eclipse but that thing was way too big and slow. Just scrolling would cause refresh jitters and I'm on a modern i7. I also tried Code::Blocks but the ctrl+tab document switching doesn't behave correctly and that was a deal-breaker for me right there; I use that constantly...

Qt Creator is another option if you're looking for the usual IDE candy, works fine for non-qt c++ projects as well. I've never used visual studio too heavily to know what i might be missing but they always seemed to be comparable from what i've seen.

[Evert]

For reference, I had a number of things in mind that I wanted SjaakII to be able to do:

• Play western Chess and trivial variants
• Play XiangQi
• Play Shogi and Shogi-variants
• Play Sittuyin
• Play Shatar
• Play Makruk, but it can do this already if it can technically do the above
• Play Capablanca, but again it can do this if it is technically capable of the above
• Play games where the board has holes/is not rectangular, like Troitzky Chess
• Be configurable for the user

The last point is non-trivial, but to me it was very important. The only variant it plays that you could not define in a configuration file is Omega Chess, and that is because this requires quite a bit of post-process hacking to make its internal 12x10 board behave as the 12x12 Omega board. I may expose this at some point because I like the option for things like Citadel Chess.

By contrast, I wrote Postduif with the following goals:

• Play Grande Acedrex (a full 12x12 board)
• Play Tamerlane Chess (a weird 11x10 board with 2 bonus squares)

As a bonus, it can also play Shatranj, and then there is nothing preventing you from playing Courier Chess as well. I could actually make it play Makruk as well with only minor modifications, but I don't think I want to go that far. It does not play Orthochess and it is not user configurable, and I have no real plans to change either of those.
Unlike SjaakII, it is a mailbox program (Postduif means Carrier Pigeon). Conceptually all pieces have a two-step move: a leap (which may be 0) followed by a slide (which may again be 0 and which may optionally skip a number of squares), but in the move list I distinguish pawns, kings, pure leapers and pure sliders from leap/slide combination pieces. I use this information for slightly more efficient move generation.

[Evert]

What I would really like to have for SjaakII is a "variant designer" where you can graphically edit the board, tick boxes for rules and define how pieces move. I'm not sure what the best way to do that is though.

I think it's technically possible to open a window to do those things in in response to a button press in the engine options dialog (I would add a button "Design variant..."), but then I would need to somehow manage the window, and do it all in a platform-neutral way (there is no way I am going to maintain separate Windows GUI code).

[hgm]

In principle the XBoard Engine Settings dialog should be designed so that the engine can redefine it. (This has never been tested, though.) The idea was that the engine could clear the GUI's option list for it by sending feature done=0, and then send a new option list. The origial idea was that this would be done in response to a -reset option, which would be a button of which the GUI would be aware that when you press it, all option settings it has buffered could have been changed. But I guess there is no harm in allowing an engine to do this at any time. So that it basically can implement a multi-page settings dialog, using 'Next'/'Previous' buttons to navigate from one page to another.

You could have a 'Design' button that then completely alters the Engine Settings dialog, and shows you all the checkboxes and spins that parametrize the variant.

Of course you could only make that available when the user first selects a variant 'design', which defines all pieces in the pieceToChar, and as initial position creates a 'palette' board with all pieces present once. People could then easily switch to Edit Position mode, and set up the desired initial position in the upper-left part of the board (which presumably is bigger than he wants).

Did you ever see my Interactive Diagram design wizard? It is invoked when you press a button near the end of the page at http://www.chessvariants.com/index/msdi ... ractivedia , which describes the diagram. This seems very similar to what you want. In fact, it is my intention that the Interactive Diagram that is designed this way will one day also become an engine that plays the variant (in your web browser). So far it is only a GUI. (which, f.e., could be used in a turn-based server).

[Evert]

In principle the XBoard Engine Settings dialog should be designed so that the engine can redefine it. (This has never been tested, though.) The idea was that the engine could clear the GUI's option list for it by sending feature done=0, and then send a new option list. The origial idea was that this would be done in response to a -reset option, which would be a button of which the GUI would be aware that when you press it, all option settings it has buffered could have been changed.

So you could have a Design button that then completely alters the Engine Settings dialog, and shows you all the checkboxes and spins that parametrize the variant.

Can that be done entirely on the fly?
Say I select a piece in a list of pieces and then its value appears in the appropriate input box without needing to close/open the dialog box? I currently do the "done=0/resend features/done=1" in response to changes in some of the options that affect the variant list.
If that works it could indeed work as a suitable alternative.

Did you ever see my Interactive Diagram design wizard? It is invoked when you press a button near the end of the page at http://www.chessvariants.com/index/msdi ... ractivedia , which describes the diagram. This seems very similar to what you want. In fact, it is my intention that the Interactive Diagram that is designed this way will one day also become an engine that plays the variant (in your web browser). So far it is only a GUI. (which, f.e., could be used in a turn-based server).

Yes, that's pretty much exactly what I want.

[hgm]

Can that be done entirely on the fly?
Say I select a piece in a list of pieces and then its value appears in the appropriate input box without needing to close/open the dialog box? I currently do the "done=0/resend features/done=1" in response to changes in some of the options that affect the variant list.
If that works it could indeed work as a suitable alternative.

Well, I intended it to work that way. So if it doesn't, I can still fix it for 4.9.0. The original idea is that you could let the engine normally show a dialog with only the most basic options, plus a button 'Advanced', which would then switch you to a much more elaborate dialog.

But XBoard would have to close and reopen the dialog to redesign it, when the option list changes, rather than just the values of the options. I am not sure it does that now. But it would be trivial to implement: on reception of the done=1 feature it should call a RefreshSettings function in the front end, which would check if the settings dialog is up, and if it is, pop it down and then up again. Tricky thing might be to know if the option list stayed the same or not; if it did it would be more quiet to just update all settings in the dialog controls. Perhaps we should have the engine tell that, by sending done=2 ? It might be a good idea to allow the engine to force the settings dialog to appear anyway, even if it wasn't up before. (A modern version of the "askuser" command, as it were.) So done=2 could mean "refresh all option values", while done=3 could mean "pop up new dialog" (which as a side effect would always pop down an existing dialog).

About the pieceToCharTable: I have now arranged it such that ^L is equivalent to what before would just be a +, except that at the same time it pairs the piece with another piece that has L as ID. So each promotion partner can now explicitly specify which base piece it is he promoted version of. And there is no need for either to be in any specific part of the table. By default the first 11 pieces are paired with the second 11, though, for backward compatibility; using ^ prefixes just overwrite these links.

I also made it that *L means that the current piece has L as ID, but that its promotion partner is Tokin, even though the Tokin might not mention that.

Now that I am liberated from promotion constraints, I want to reorder the pieces behind Lion in the pieceToChar string, so that the more useful are more to the front. How about the following ordering:



?

The pieces rendered in black can in principle be independently defined, but aren't in the default theme. (This was to make a Prince (+E) in Chu Shogi distinguishable from a King, so you could use different kanji pieces for those.) I added non-special duplicats of Amazon and King. (The piece right of Tokin should really be a Shogi +N, with a moon on the turban.)

I might also allow digits in the pieceToChar string, used in the same way as in FEN: 8 would mean eight periods.

[Evert]

Can that be done entirely on the fly?
Say I select a piece in a list of pieces and then its value appears in the appropriate input box without needing to close/open the dialog box? I currently do the "done=0/resend features/done=1" in response to changes in some of the options that affect the variant list.
If that works it could indeed work as a suitable alternative.

Well, I intended it to work that way. So if it doesn't, I can still fix it for 4.9.0. The original idea is that you could let the engine normally show a dialog with only the most basic options, plus a button 'Advanced', which would then switch you to a much more elaborate dialog.

But XBoard would have to close and reopen the dialog to redesign it, when the option list changes, rather than just the values of the options. I am not sure it does that now. But it would be trivial to implement: on reception of the done=1 feature it should call a RefreshSettings function in the front end, which would check if the settings dialog is up, and if it is, pop it down and then up again. Tricky thing might be to know if the option list stayed the same or not; if it did it would be more quiet to just update all settings in the dialog controls. Perhaps we should have the engine tell that, by sending done=2 ? It might be a good idea to allow the engine to force the settings dialog to appear anyway, even if it wasn't up before. (A modern version of the "askuser" command, as it were.) So done=2 could mean "refresh all option values", while done=3 could mean "pop up new dialog" (which as a side effect would always pop down an existing dialog).

That sounds workable. I'll try to do a quick test to see if done=0/done=1 indeed does a "hard-refresh" of the dialog box while it's up, hopefully tonight.

About the pieceToCharTable: I have now arranged it such that ^L is equivalent to what before would just be a +, except that at the same time it pairs the piece with another piece that has L as ID. So each promotion partner can now explicitly specify which base piece it is he promoted version of. And there is no need for either to be in any specific part of the table. By default the first 11 pieces are paired with the second 11, though, for backward compatibility; using ^ prefixes just overwrite these links.

I also made it that *L means that the current piece has L as ID, but that its promotion partner is Tokin, even though the Tokin might not mention that.

Now that I am liberated from promotion constraints, I want to reorder the pieces behind Lion in the pieceToChar string, so that the more useful are more to the front. How about the following ordering:



?

The pieces rendered in black can in principle be independently defined, but aren't in the default theme. (This was to make a Prince (+E) in Chu Shogi distinguishable from a King, so you could use different kanji pieces for those.) I added non-special duplicats of Amazon and King. (The piece right of Tokin should really be a Shogi +N, with a moon on the turban.)

That looks good. I'm not sure I understand what you mean by "The pieces rendered in black can in principle be independently defined, but aren't in the default theme."? Do they normally just alias other pieces in the list? I'm confused because the black narrow queen (piece 16, "grasshopper") appears normally when used in the default theme (for instance in Crazyhouse, where it represents a promoted pawn). Is it correct that there are three duplicates for the king?

I might also allow digits in the pieceToChar string, used in the same way as in FEN: 8 would mean eight periods.

Ah, good idea: that would be helpful, I think. On the other hand, setting up a piece-to-char is a bit tedious, but ultimately it is not very hard and it only needs to be done once per variant.

[hgm]

I'm not sure I understand what you mean by "The pieces rendered in black can in principle be independently defined, but aren't in the default theme."? Do they normally just alias other pieces in the list? I'm confused because the black narrow queen (piece 16, "grasshopper") appears normally when used in the default theme (for instance in Crazyhouse, where it represents a promoted pawn).

What it means is that they have an extra step in the fall-back cascade, and that what is shown above is already the first fallback. E.g. for the King it would first try to read WhitePrince.svg. But when that is not present (as in the default theme) it then tries King.svg for it. This to solve the problem that Chu Shogi players that use kanji pieces get really upset when a King obtained through promotion of an elephant has King written on it in black, rather than Prince in red. Same for the Queen and Lion; they want those obtained by promotion to be written in red.

Of course I could just have provided a Prince.svg in the default set that was a copy of King.svg, but it seemed easier to just solve it with a primary fall-back table. Otherwise people designing alternative themes, but who do want the King and Prince to look the same, would also have to duplicate the King images.

The narrow crown first tries Crown.svg, and then falls back on Princess.svg. In the default theme it does the latter. This was done for the benefit of Wa Shogi, to make a Fox obtained through promotion look different from a primordial Fox.

Is it correct that there are three duplicates for the king?

Yes. The last one is the normal King. The one rendered in black is the Prince (promoted Elephant). And because I added a second spear glyph as non-Pawn version that could be used for Amazon, I figured it might also be good to have a similarly non-special King glyph (which XBoard would not consider royal), which you could use in games without check. (E.g. extinction chess.)

Ah, good idea: that would be helpful, I think. On the other hand, setting up a piece-to-char is a bit tedious, but ultimately it is not very hard and it only needs to be done once per variant.

True, but it gets more annoying as there get more and more piece types. And it is a quite trivial change.

[Evert]

Ok, I tried re-building the engine options dialog. I found the following:

• The engine does not receive a notification of changed values until the dialog box is closed with "Ok", so it cannot modify values in response to value changes.
• Sending "done=0/variants=.../done=1" updates the variant list for the engine (which I already knew).
• Sending "done=0/feature option/done=1" adds the option to the existing option list, so sending all options again duplicates the dialog.