TalkChess.com

In May a tournament of the chessvariant knightmate was covered here:
http://64.68.157.89/forum/viewtopic.php ... knightmate

But what about nightrider chess?
I have never read much about it.
Even though the nightrider is one of the most popular pieces in problems with fairy pieces.

My program Dabbaba can play that variant (with winboardf).

10 years ago it played two games against a human via email:
http://www.jens-musik.dk/BenjaminP5.TXT

Here is the start of a little amusing game Dabbaba played against itself.

1.d4 d5 2.Ne5 Bf5 3.Bf4 e6 4.e3 Bb4+!
white cannot play 5.c3, Bxb1 as the nightrider is much more worth than a bishop
5.Ke2 Bd6!
White loses a nightrider now (6.Nf3, Bg4).
But why couldn't Dabbaba play 6.Ng1 to save his nightrider?
Because of 6.Ng1, Bxf4 7.exf4, Bxc2! followed by 8.-,Bxb1
(8.Qxc2?, Nxd4+! - oh, yes, there was a nightrider on b8!).

I think nightrider chess deserves more attention.

Jens

Perhaps it does, but there aren't enough engines that can play it. Fairy-Max could, of course. Or perhaps not, as with Nightriders there are possibilities for both sides to continue checking each other indefinitely. This would crash Fairy-Max by stack overflow, as it extends all checks. I don't know how common such positions are in Nightrider Chess.

Perhaps it would be possible to play it under WinBoard_F as variant fairy.

But I consider Nightrider Chess a less interesting variant than Knightmate. Although the Nightriders are interesting pieces, worth more than a Rook (despite the fact that they have no mating potential), they don't add such an exotic flavor to the game as altering the royal piece.

I also enjoyed knightmate chess - especially because Dabbaba participated!

But I find the knights moving like kings a little boring because:
* they move so slowly
* They are slow to develop, so castling can be done
* they cover the weak points f2 and f7
* they give the attacker less power, but gives good help to the defender - and when the king has got more mobility, more positional games and draws between good players must be expected.

Perhaps the knights should have the ability to promote.
Or perhaps the knights should simply move like knights!

------

I doubt nightriders makes it more likely for checking each other indefinitely to occur.
(If Fairy-Max has a problem with that, I consider it as an error that should be corrected)


"But I consider Nightrider Chess a less interesting variant than Knightmate. Although the Nightriders are interesting pieces, worth more than a Rook (despite the fact that they have no mating potential), they don't add such an exotic flavor to the game as altering the royal piece."
Is this something you assume, or do you have any experience with it?
I have a little experience with it, and I find it attractive.


It is possible for Dabbaba to play nightrider chess under WinBoard_F as variant fairy.
(see the note in dabbaba.ini)

Jens

JensBNielsen wrote:I doubt nightriders makes it more likely for checking each other indefinitely to occur.

The problem is with positions like this (Knight symbols represent Nightriders):

[d]3rr3/3k4/8/4K3/8/2N2N2/8/8 w - - 0 1

where checks can continue indefinitely by moving the Kings between d5-e5 and d7-e7, respectively. By closing off all other escape routes for the Kings with other pieces, you can even make this situation forced.

This pattern has no counterpart in normal Chess. (In Xiangqi you can have something similar with Rooks versus Cannons.) Despite its contrived nature, in a full-witdth search it is bound to occur if the search is deep enough and the material is present in the root. I don't know how big the problem is in practice.

Fairy-Max would crash on this, and it is not easy to repair. Note that Fairy-Max is simply a micro-Max derivative with configurable move-generator table. And micro-Max was written to be the World's smallest Chess engine, rather than for code clarity and ease of change. To make it small almost every feature existing in ordinary Chess programs (like repetition detection of tree positions) has been cut out, to the point where intentionally the soundness of the program (w.r.t. crashes and time forfeits) was given up for size reduction, if the resulting crashes would not occur so frequently as to reduce Elo more than size. Fixing this problem is definitely outside the scope of Fairy-Max, as it would easily take more code than the complete engine is now. And my desire to play Nightrider Chess is not so great that I would consider writing an entirely new engine for it.

But it might not be a problem in practice; I did use micro-Max once (before the completely general Fairy-Max version existed) where I replaced the moves of white Rooks by those of Nightriders, in order to determine the value of the Nightrider in bullet games. I did not seem to have an insufferable number of crashes there. So perhaps I will set up a Nightrider match when I have more time.

A counter question: can you easily make Dabbaba play Capablanca Chess (on a 10x8 board, with Q, C and A present simultaneously)?

Thank you for the explanation. I understand that the checks can be a problem - but it might be in a very few games.

I hope we will see more nightrider chess some day.

Are there only a few programs playing this variant?!

Dabbaba is very much designed to play on a 8x8 board. In my opinion chess is complicated enough on 64 squares, so I have never been interested in larger boards.

I have not done any C-programming for 10 years and doubt I can bring my old compiler to life again. Besides I am not interested in doing a lot of programming again.
I will make a few improvement to Dabbaba, and Jim Ablett will compile the source for me.

But perhaps someone else will try to make some major improvement to it some day. Although it is very stable, it might have some errors that reduce its playing strength seriously?!

Jens

Besides Dabbaba I don't know of any WinBoard engine that could play it. Some of the general variant-playing programs can be configured to play it, but of those I know (ChessV, Zillions of Games, Fairy-Max) only the latter is WB compatible.

If people are aware of other engines, please post here.

As things stand, the only thing we could do is play Dabbaba against instances of Fairy-Max with various time handicaps.

I've converted Faile to play Nightrider, but I don't see how to make Winboard-F play it without modification. Using /variant=fairy brings other fairy pieces into the game besides Nightriders or am I missing something?. Couldn't Winboard-F perhaps have dedicated implementation for it like does for knightmate (/variant=nightrider) ?

Jim.

The idea of variant fairy is that all pieces are available, so that you can paste in a FEN of whatever opening position you want. In variant normal, any FEN you paste is restricted to have only the pieces PNBRQK. In fairy you also have FWEMOUHACGS.

This seemed a good idea at the time, when the only engine that supported non-orthodox pieces was Fairy-Max, as WB uses these same letters in the FEN it transmits to the engine as in the FEN you paste into it, and fMax did understand EFWMHACG as piece types.

The problem, however, is that the other engines that now emerge to play variants do not use non-orthodox letters for non-orthodox pieces! Dabbaba, for instance, does not use H for Nightrider (the WB default) in Nightrider Chess, but N, and ArchBishop and Chancellor continue to be represented as Q in thir respective variants. In Knightmate, the Royal Knight remained K, rather than N (as you would use in diagrams limited to orthodox pieces) or U (=Unicorn, as WB would like), and the 'Knights' as N rather than K (for diagrams) or M (=Man, the WB default). This problem already surfaced earlier in Shatranj, where existing engines and ICC represent the Elephants as B rather than E, and the Ferz as Q rather than F.

Fortunately WinBoard_F allows redefinition of the letters used for the various piece bitmaps. Through the /pieceToCharTable="..." option you can assign any letter you want to a piece. I also made the defaults WB uses variant dependent, and made the default for Shatranj such that Elephant=B and Ferz=Q, obnoxious as that is. To play Knightmate I redefined the WB defaults through this option to assign K to Unicorn and N to Man/Commoner.

The problem which I had not foreseen when I first made WinBoard_F is that this only works if all engines agree on the piece names. Fortunately, in WB protocol, you hardly ever use the piece names, as moves are sent in long algebraic, not in SAN. The only place where piece names are used is in setboard / edit, to set up a position. If you refrain from doing that, it really doesn't matter if WB's idea of the piece indicators differs from that of the engines. In fact, all the variants Dabbaba knows could be played as variant normal, provided you switch legality testing off. The Chancellor in Chancellor Chess would then be displayed as a Queen, and WB would never know that it wasn't a Q, and the engine would never know that WB thought it was a Q. (And with font-based rendering you could even make the Q be displayed as a Chancellor.)

WB would only notice that this Q sometimes does illegal moves, but would perform them anyway, as legality testing was off. The ony problem might occur when writing the PGN, if two C could go to the same square, where only one of them could have gone if they were Q. The SAN would then need a disambiguator, but WB would not add it, thinking the move was unambiguous. A minor flaw, as normally you only have one C in Chancellor Chess. And who cares about PGN anyway? WB would still be able to read it back in, as it would also not realize that disambiguation was needed on reading.

So it seems that variant normal could be used to run all Dabbaba's variants. So why did I add variant fairy? The reason was that variant normal restricts you to using only 6 piece types in one game. You can replace a Q by a C (with WB still thinking it is a Q), but you cannot have Q and C both be present on the board. Variant fairy and the new piece types were added to WinBoard_F for allowing to introduce exo-pieces while all orthodox pieces are present as well (and allow legality checking). Note that Dabbaba cannot do this, it implements the exo-pieces in the variants it plays by redefining orthodox pieces, and thus remains limited to 6 piece types. E.g., Dabbaba cannot handle positions that have both orthodox Knights and Nightriders on the board. Fairy-Max can (although the number of piece types is limited to 15 there), and variant fairy was made for accomodating Fairy-Max (as I found it very annoying to have some of the Knights on the WB display move as Knights, and others as, say, Camels).

So variant fairy allows all pieces on the backrank to be of different type, and the use of non-orthodox bitmap representations, and thus could be used to play many variants even with legality testing on, as WinBoard_F knows the move of the more common fairy pieces. It can be seen as a kind of FRC with fairy pieces. But, like FRC, it is necessary to provide an opening position, which WB has to load into the engines. And in the current logic this only possible f the engines use the same names for the pieces. And Dabbaba uses N for Nightrider, and Q for Archbishop and Chancellor, and it would be very unfortunate if this became the standard for these particular fairy variants. (Because of the overloading of Q, for instance.)

So let me propose the following:

Given the internal limitations of Dabbaba, it would not suffer if we changed its FEN reader (or edit menu, I am not sure if it is a protcol 1 or 2 engine) to understand H and M as being synonymous to N, U synonymous to K, and A and C synonymous to Q. Other engines that implement variants by having one of the orthodox pieces play the role of a fairy piece could use a similar mapping. Engines that do have separate internal representation of exo-pieces (like Fairy-Max) would of course map H,A,C,M,U to the corresponding representations, distinct from those of N,Q or K. WinBoard_F could then always use its defaults piece indicators, so they end up in the PGN file according to the standard. It would not have to create confusing by using Q for Chancellor in the PGN, which would not be acceptable in Capablanca or Seirawan Chess, where Q and C occur next to each other, and would thus support PGN compatibility between Seirawan Chess and Chancellor Chess.

To accomodate deviating engines, I should allow options to change the piece-to-character mapping on a per engine basis, independent of the mapping used externally. So add options /firstPieceToCharTable="..." and /secondPieceToCharTable="...", which are then only used when writing a FEN to the respective engine during setboard. But I really would like to prevent the emergence of deviating engines as much as possible...

Another thought:

I remember that you implemented the exotic variants in Dabbaba to be triggered by setting the variant to fairy, and then having Dabbaba look in a configuration file what variant it should actually choose.

Would it be possible to defer the choice of variant until Dabbaba receives a setboard command? The occurrence of exo-pieces in the FEN could then be used to identify which variant Dabbaba should actually switch to. E.g. for Nightrider Chess it would receive
rhbqkbhr/pppppppp/8/8/8/8/PPPPPPPP/RHBQKBHR w KQkq - 0 1,
for Janus
rnbakbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBAKBNR w KQkq - 0 1,
and for Chancellor Chess
rnbckbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBCKBNR w KQkq - 0 1.
The internal variant it would have to switch to would betray itself by the H, A or C appearing in the FEN. If none of those occurred, it could set the variant to, say, kingfreeze. The letters D and E could be used as other N synonyms to indicate the variants with augmented Knights (Dabbaba and Alfil Chess), although these pieces are not really provided by the current WinBoard_F. (But you could still represent them as Cannon or Elephant, playing with legality testing off.)

hgm wrote:Another thought:

I remember that you implemented the exotic variants in Dabbaba to be triggered by setting the variant to fairy, and then having Dabbaba look in a configuration file what variant it should actually choose.

Would it be possible to defer the choice of variant until Dabbaba receives a setboard command? The occurrence of exo-pieces in the FEN could then be used to identify which variant Dabbaba should actually switch to. E.g. for Nightrider Chess it would receive
rhbqkbhr/pppppppp/8/8/8/8/PPPPPPPP/RHBQKBHR w KQkq - 0 1,
for Janus
rnbakbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBAKBNR w KQkq - 0 1,
and for Chancellor Chess
rnbckbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBCKBNR w KQkq - 0 1.
The internal variant it would have to switch to would betray itself by the H, A or C appearing in the FEN. If none of those occurred, it could set the variant to, say, kingfreeze. The letters D and E could be used as other N synonyms to indicate the variants with augmented Knights (Dabbaba and Alfil Chess), although these pieces are not really provided by the current WinBoard_F. (But you could still represent them as Cannon or Elephant, playing with legality testing off.)

Hi Harm,

Thanks for your reply/answers.
I found a bug in my Dabbaba version. Nightrider wasn't working in winboard. I fixed this now, (the fix actually defers the variant change until just before the 'new' command) and am currently running test games against Faile with Winboard-F running in normal mode with legality checking off.
It's working ok like this, only no special bitmap graphic for the knights. An upside down knight seems to be standard for this.

I post link to the engines later after some more testing.

regards,
Jim.