The site has moved to a new server, and there are now some issues to fix. Please report anything needing fixing with a comment to the homepage.



The Chess Variant Pages




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Earlier Reverse Order LaterLatest
The Sultan's Game. Variant on 11 by 11 board from 19th century Germany. (11x11, Cells: 121) [All Comments] [Add Comment or Rating]
Anders Jensen wrote on 2016-10-06 UTC

The game can be played at the website jocly.com under the name sultanspiel.

Here it is the rule for promotion that a pawn only can be promoted to a captured piece. Because of that a player who haven't had any pieces captured can't move a pawn to the last rank.

Another rule not mentioned here is that pawns who had made a single step move at their first move may choose between a singlestep move and double step move at their next move.


Greg Strong wrote on 2020-09-11 UTC

I have rewritten most of this page with updated information from Jean-Louis Cazaux's excellent new book A World of Chess, co-authored with Rick Knowlton. The previous version had the initial setup incorrect (both of a player's bishops on the same color) and incorrectly identified the author of a book on chess variants as the game's inventor. Additional historical information has also been added.

I still need to make a similar revision to The Emperor's Game


H. G. Muller wrote on 2021-05-08 UTC
files=11 ranks=11 satellite=sultan graphicsDir=/graphics.dir/alfaeriePNG35/ holdingsType=1 promoZone=1 maxPromote=1 squareSize=35 graphicsType=png lightShade=#FFFFCC startShade=#E8A800 rimColor=#804545 coordColor=#E8A800 borders=0 firstRank=1 useMarkers=1 promoChoice=*C*Q*M*A*R*B*N castleGap=-1 symmetry=mirror pawn::fmWfceFifmnDifmnH::a2-k2 knight:N:::c1,j1 bishop::::b1,i1 rook::::a1,k1 adjudant::BN:cardinal:h1 marshall::RN:chancellor:d1 queen::::g1 commander::QN:amazon:e1 king::KisO4::f1

The Sultan's Game


Greg Strong wrote on 2021-05-09 UTC

Ok, I updated this page in the manner I would propose for general usage. Everything seems to be ok, except that after you move one of black's pieces, the color of the dark squares changes to a gray and stays that way.


H. G. Muller wrote on 2021-05-09 UTC

OK, that looks good. Except for those with JavaScript switched off.

To cure that there should be a static image as alternative (screenshot?), in <noscript> tags. Perhaps together with a message that points out what they are missing):

<noscript>
<p>You can play against this diagram if JavaScript is on</p>
<img src="....">
</noscript>

And you can add display:none; to the style of the <div> conaining the interactive diagram; the betza.js script would make it visible when it converts the deinition to a board image, and it keeps the definition hidden when JavaScript is off.

The color change is by design. Should really happen on the first click already. This can be suppressed by using darkShade instead of startShade to set the color. Bright colors are often not ideal for playing, especially when colors were used for highlighting. But some diagrams use dark-blue squares, which even camouflage the 'black' Alfaerie pieces.


Greg Strong wrote on 2021-05-09 UTC

Changing startShade to darkShade does not seem to have worked.

I added the noscript section. Good call.


H. G. Muller wrote on 2021-05-09 UTC

Changing startShade to darkShade does not seem to have worked.

Because it has not been changed. Check through 'Show Page Source'. The caching is screwing up things.

[Edit] OK, with ?nocache=true it does seem changed, and indeed it does not work. I will check it out.

[Edit2] OK, should work now. It was interaction between the two diagrams (the one in the Comments is on the same page), where one remembered the 'realColor' of the other. Which was not reset, because startColor and darkColor were not both defined in this diagram. I moved the initialization of realColor to an invalid value from the globals to the routine that parses the diagram definition now.


Jörg Knappen wrote on 2021-05-10 UTC

There is a typo in the German book title, it should read "seine" in place of "siene".

Also, I read the author's name as "Tressan" in accordance with Google OCR. There is a clear bridge between the two stems on the upper part of the last letter of his name. Google search finds the name on several pages where it seems to be removed from the pictures (Probably from bottom lines for the bookbinder, called Bogensignaturen in German language).

I have found the book on Google books here: https://books.google.de/books?id=n64UAAAAYAAJ&printsec=frontcover&hl=de&source=gbs_ge_summary_r&cad=0#v=onepage&q=Tressan&f=false


Jörg Knappen wrote on 2021-05-10 UTC

P.S. Can we complete Peguilhen to Ernest-Frédéric von Lavergne-Peguilhen (1769–1845), recipient of the last letter from Henriette Vogel and Heinrich von Kleist? Life dates and occupation are fitting, and he also went simple by Peguilhen.


Greg Strong wrote on 2021-05-11 UTC

Thanks, Jörg! These corrections have been incorporated.


Jörg Knappen wrote on 2021-05-11 UTC

Thanks Greg. Can you update the Emperor's Game as well?


H. G. Muller wrote on 2021-05-11 UTC

I only notice now that these variants have weird castling rules, where the Rook doesn't end up next to the King. At the moment the diagram doesn't support that. Also for lack of a Betza notation for this. The On castling implies the castling partner ends on the opposit adjacent square.

[Edit] For now I solved this problem by allowing additional specification of the castling type through diagram parameters, rather than introducing new XBetza notation. For this I implemented a new parameter castleGap, default value 1, which corresponds to normal castling. The idea is that for castleGap > 0 the destination of the Rook will be that of the King, minus castleGap times the basic King step. For castleGap=1 the Rook would thus end up next to the King on the inside, while castleGap=2 would leave an empty square between R and K, etc. If castleGap < 1, however, the reference point  is the King's square of origin, instead of the destination. That means that castleGap=-1 gives the type of castling we want here: the Rook ends next to the square where the King started (just as the King ends next to where the Rook started, so that they move by an equal amount.)


Georgi Markov wrote on 2021-10-20 UTC

In fact, the rook - both here and in the Emperor's game - does end up next to the king. After Tressau's (and I believe this is the correct name, not Tressan: see Oettinger’s Bibliotheca Shahiludii) rules for the Sultan's game, K moves four squares towards R which lands on the adjacent square. Check the illustrative games in Tressau's book. I have a paper in press in the Board Game Studies Journal dealing with the Emperor's game and the Sultan's game which I hope will be published in 2022; will provide a link when it is.


Bn Em wrote on 2021-10-20 UTC

When saying ‘four squares’, is that counted inclusively or exclusively? In the former case, both king and rook moving ‘four’ squares each would in fact land next to each other, on the bishops and adjutant's squares on the queenside and the marshall's and knight's on the commanderside.


Georgi Markov wrote on 2021-10-20 UTC

K to b/j, R to c/i.


Bn Em wrote on 2021-10-21 UTC

Is that Tressau's interpretation? And do we know how much info the original sourcs gives on the matter?

After all if the latter does specify, as this article does, that both pieces move four spaces each, the Kc/i–Rd/h interpretation would make sense both in terms of preserving usual castling and lining up with the frequent use of inclusive counting (see also paragraph 4 of the Comments in Cazaux' page on Grant Acedrex)


Georgi Markov wrote on 2021-10-25 UTC

Tressau does not explicitly mention how many spaces the rook goes, but the landing square for R in the Sultan's game is obvious enough from the provided illustrative games: see mating position in game 1 (p. 87) and move 28 in game 4 (p. 89). [On move 20, White castles "to the right"; move 28 is Ri1-f1, or 119 to 116 in the original notation; that's the first R move after castling].


Bn Em wrote on 2021-10-25 UTC

Ok, having actually gone to find a copy online, I agree that Tressau specifies the Kb/j–Rc/i castle; in principle one could still object that the example games may not be played by the original rules (while he says they're real, rather than constructed, games, it could still be under the influence of a misunderstanding), but it seems upon a cursory reading that for the Sultan's Game in particular his book may in fact be the original source? The Emperors Game is cited in the Spielarchiv, but Tressau explicitly notes (p.80) that a game with a Marshal had been suggested there but not described, rather being rejected due to the necessary odd number of files being unwieldy (in particular due to either same‐colour bishops or transposition of one bishop but not the other with its adjacent knight).

Unfortunately a quick search for the Archiv der Spiele online appears entirely fruitless so I can't confirm that…


Georgi Markov wrote on 2021-10-25 UTC

Tressau modified the rules for the Kaiserspiel (e.g. castling rule is different in the Archiv der Spiele description) and practically developed the rules for the Sultanspiel himself based on Peguilhen's initial - but never fully developed - idea. Later sources are ultimately based on Tressau, with errors. Thus it's Tressau's rules that should be taken as definitive, the illustrative games were played by Tressau himself and after his own rules, so there is hardly any chance for a misunderstanding. There's a discussion of all that in my paper in press, I'll provide a link when it's published.


Bn Em wrote on 2021-10-25 UTC

Indeed, that was my impression from his book as well; I'd initially missed the detail of how recent this variant was and had assumed it significantly older (and I don't trust people to count like we do today(!)).

I enjoyed the other papers you posted here and look forward to reading this one too


Georgi Markov wrote on 2021-10-25 UTC

Thank you very much indeed!

Meanwhile, I realized I seem to have somehow misread your "search for the Archiv der Spiele" as "search within"; I hope this link works: https://books.google.bg/books?id=If5dAAAAcAAJ&printsec=frontcover#v=onepage&q&f=false


Jean-Louis Cazaux wrote on 2021-10-26 UTC

Like Georgi Markov, I confirm that I believe that the name of the cited author is Tressau and not Tressan. Maybe the text of this page should be corrected, also because my book is cited (thanks). In this book, we used Tressau.

That being said, the gothic script which is used for the original German book is not easy to distinguish an "u" from an "n".


Greg Strong wrote on 2021-10-27 UTC

Maybe the text of this page should be corrected, also because my book is cited (thanks). In this book, we used Tressau.

Yes, sorry, this was a mistake.  I changed the name on the Emperor's Game page when I updated it but overlooked making the same change here.  I'll get it corrected.


Jean-Louis Cazaux wrote on 2021-12-02 UTC

The rule of castling is not correct as far as the Rook is concerned. When castling, the king move four squares toward one of the rooks, and the rook jumps to the other side of the king.

This will be corrected in future editions of A World of Chess, by JL.Cazaux and R.Knowlton.

In addition, the name Tressan has to be corrected to Tressau on this page.


H. G. Muller wrote on 2021-12-02 UTC

When castling, the king move four squares toward one of the rooks, and the rook jumps to the other side of the king.

That definitely sounds more sensible. I had to add a special parameter castlingGap to the Interactive Diagram to support the weird way of castling that is described in the text. (I see the Diagram in the article has already been changed to castle in the normal way, though, unlike the one I first published in the comments.)


25 comments displayed

Earlier Reverse Order LaterLatest

Permalink to the exact comments currently displayed.