Ratings & Comments

The Left General and Right General's text in the piece listing both say this:

The Drunk Elephant moves as a King except directly left.

Are the promotions right for those pieces, do they both promote to Shogun?

I'm just double-checking because a friend and I are currently working on digital implementations of all the large historic Shogi variants, and once those are finished and bug-fixed I'd like to include at least Suzumu, Hanten and Chushin Shogi as well :)

I wish I could use the Alfaerie icon for the Sergeant for the Maasai on ranks 3 instead of the one I used instead but I don't know how to do it.

I have added the Sergeant to the piece set with notation "st" but you can still use it with the current "t" notation.  Just add the following code to the beginning of the pre-game section:

setsystem groupsets array alfaerie-metamachy;
set mypieces ();
foreach label (a A b B c C d D e E f F g G h H i I j J k K l L m M n N o O p P q Q r R s S t T u U v V w W x X y Y z Z):
  setelem mypieces #label pieceimg #label;
next;
if == pieceset alfaerie-metamachy:
  set mypieces.t pieceimg st;
  set mypieces.T pieceimg ST;
endif;
setsystem pieces #mypieces;

You case see it in action here:

https://www.chessvariants.com/play/pbm/play.php?game%3DMaasai+Chess%26settings%3Dgs_test

Please note that after you change your preset, you will need to refresh the page or clear you cache before you see the game on the preview screen.  But if you start moving pieces, you should see the new graphics.

Perhaps this is a bit off-topic in this place, but just out of curiosity: can you elaborate a bit on this 'digital implementation'? Does this include an AI, and if so, is this an AlphaZero-type self-learning, or a conventional alpha-beta search (with NNUE or hand-crafted)? It would be very nice if you could create a strong player for games with promotion-on-capture and contageon, such as Maka Dai Dai Shogi, and its shrunken versions. As it is not clear to me what would be a good strategy for such games.

I Implemented a way to have both 1-step (O1) castling and castling that ends on the Rook square in the same variant. Both can be selected through clicking the Rook as destination of the King moves. This was already the case, and the diagram would perform the castling indicated in the move definition. But if this is ambiguous, it now request a third click for entering the King destination, and the square next to the King will then be interpreted as castling, rather than a normal move.

I am looking to delete my account and potentially create a new account as my current account is cluttered with a large amount of garbage from a couple years ago. Additionally, I created my account without understanding the user ID system, so my user ID is just random nonsense. However, I seem to have a glitched page linked to my account that prevents me from deleting it. Is there any way to resolve this, or should I just abandon the account altogether?

@HG,

I face the same issue with my new 12x12 games. There are quite tactical. I can see that but I'm not sure what a good strategy would be. I'm not sure if I'll ever be capable of writing an alpha-zero style program though.

This interesting variant featured some pieces for which no XBetza notation existed. Namely a lame Slip-Rook and Slip-Bishop, sliding only an odd number of steps. I now made the diagram understand notations jnAA, with A a distant leaper atom, as a lame rider with the given basic leap, with an elongated first step.

As many pieces promote, and only in an (optional) predetermined way, I used Shogi-style promotion for this diagram. As a result the automatically generated piece list to the right of the diagram does not list all pieces; it only lists the unpromoted forms, and shows the correspondin promoted forms after a second click. The images used in the article's original diagram for Gryphon and Anchorite were not available in the 35x35 set I used for this diagram. I used the standard image for Gryphon and a Rhino instead. The article did not specify any pictograms for the promoted pieces that are not in the start position, so I improvised there.

Greetings, Thanks for doing this website. I don't see Commander Chess or Cờ Tư Lệnh in Vietnamese. This is not to be confused with the Vietnamese Chess listed here for zillions of games. Commander Chess was designed By Colonel Hải Nguyễn Quí and released in 2010. I think it's been adopted as the official Chess of Vietnam.

It's a modern warfare, sort of XianQi variant. Uses tanks, aircraft, a navy. Here's a link to the BGG for it:

https://boardgamegeek.com/boardgame/191203/commander-chess

The Colonel has been trying to share his game with the world and I know for a fact they are about to release a new Commander Chess game set and online/mobile platforms to play online as well.

ChessV 2.3 Release Candidate 2

This is a pre-release of upcoming version 2.3. It corrects a few issues reported with Release Candidate 1. It also adds support for a new movement capability for bent riders: the ability for a piece to slide followed by a manditory step in a different direction. As such, Renniassance Chess is now fully supported.

Since it is not an official release, there is no installation program. Just unzip to a new directory and run ChessV.exe. The official release will contain an install program.

Download here:
/programs.dir/ChessV2.3RC2.zip

Please let me know if you run into any issues. Enjoy!

This game was once considered to be included in the book "A World of Chess". When you say that it has been adopted as the official chess of Vietnam, what source or element do you have to support this statement? I am interested to know.

I did not mean to propose hiding the table like the piece legend for the diagram is hidden by default. Or even have the diagram generate it 'on the fly' in the client's browser. (Noe that the diagram can make the piece table appear anywhere on the page, in a place of your choice, through the satellite parameter.) The problem with the latter is that it would not work for people that have disabled JavaScript in their browser.

So I can see why you, and presumably many others, want such a list in your articles. So my proposal was actually: given the fact that the piece names / images / moves already have to be specified to create a diagram, couldn't we make life easier for the author by offering him as a free side effect the HTML for an (almost complete) table, which he just has to copy-paste into his article in the place where he wants it to appear? Most people would create the diagrams through the design wizard or the play-test applet, and would then copy-paste the provided HTML for the diagram into their article. They could do the same for a table with textual descriptions, which the design wizard would show in another text-box (or perhaps in the same box, after pressing a button "Piece Table".

And it doesn't matter whether the descriptions for complex pieces like Lions or Hook Movers would be inaccurate, clumsy or missing; there will be only few of such pieces, and the author can edit their description by hand after he copy-pasted the table into his article.

That is a genius idea. I would love to see something like that.

As to the format of the table - What I meant was this:  In the article above you use the piece names in the first column. E.g. "King", and then the text says "The King moves one step in each direction". Mentioning "King" twice here is redundant; you could have said "Moves one step in each direction", because people already know it pertains to the King from the first column. But I think it would be better to keep the piece name in the move description, as you had, and replace the name column by an image column. Presumably you did not do that because it is a lot of work to write all the HTML image tags with the URLs of the images. But when generated automatically that would not be an issue. It would also not be an issue to attach a handler to the table cells so that clicking on them would evoke some response (for those with JavaScript enabled). E.g. like opening/closing a normally hidden able row right below the one clicked, which by default would be empty, but which the author could use to provide a hand-made move diagram.

Actually, the reason I did the table the way I did for this game and Taishin Shogi rather than using the format I used for my smaller shogi variants (the piece images and the name in a column within the cell) is because of the size limit for the HTML editors. There is an actual limit programmed into the HTML editors on the site for how big a HTML script can get, and using the format for my smaller games exceeded that limit for both this game and Taishin Shogi because the piece list was so big. However, when I took out the images, it worked just fine, so I decided to just leave the images out. Automatic table generation is a good idea, but the size limit might make it unfeasible with images, depending on the size of the script.

I also wanted to keep the format between my Shogi variant pages as consistent as possible. Indeed, making the list is a lot of work, but a consistent format across pages makes it much easier by letting me copy-paste the text for each piece into the appropriate cell.

Also, the redundency may not actually be a bad thing. I've seen quite a few CVP articles by other people that have the piece name in both the image and the move description.

The Castle is lacking the Alfil move in the diagram.

Oh, I had forgotten. I am sorry!

Ai, sloppy. I did check the moves, of course, but I really thought it was moving this way. Now that I read back the description, I cannot imagine why I thought that...

I see that the diagram was already put in the article by an editor, so I cannot fix it myself.

I would like to make some extensions of XBetza notation. But not all of those would be backward compatible. So I want to poll opinions on how bad this would be.

W*, F*

Now that I defined the n modifier on stepper/slider atoms as generating e.p. rights, the rule that a 'flexible range' like fW* would always generate e.p. rights has become counter-productive. When this is wanted it could be described with fnW*, and the rule prevents use of the flexible range for pieces that cannot be e.p. captured. (Such as the Ninja Pawn of Hadean Chess.) So I would like to drop it. Problem is that there might be many diagrams around that rely on this rule for their Pawn moves.

The j modifier

I 'overloaded' the j modifier to mean a double step size on the first step of a sliding move, so that jB can be used to describe a Ski-Bishop. I would like to generalize this to all rider moves, with the understanding that on larger leap the modification of the first leap would turn it into the corresponding step (W or F). So that jAA could be used to describe a 'Skip-Bishop', visiting the odd squares on the diagonal (and not blockable on the even squares). The official (legacy) meaning, however, would be repetition of an Alfil leap that must jump over an occupied square. But it seems to me that no one uses, or would want to use such a move.

Flexible and free castling

Currently flexible castling has to be specified through a separate O atom for each possible King step. This because, in contrast to other atoms, a range on O indicates an exact range, rather than a maximum. This because that is usually needed for a castling. But not so for flexible castling, which on a very wide board then can lead to cumbersome notations like isO1isO2isO3isO4isO5. Perhaps it would be an improvement to extend the normal syntax of Betza notation, and allow specification of a range with the aid of a hyphen: isO1-5. A second problem are alternative castlings where the Rook does not end up adjacent to the King. The move definition would then not only have to specify the distance travelled by the King, but also where the Rook ends. Perhaps it is an idea to specify this as a 'decimal fraction' in the range: isO2.1 could mean that the King moves 2 steps, but that the Rook would not end next to the King, but keeps one empty square between the two. Then isO2.0 would mean the same as isO2.

The diagram on the page has been corrected.

AA repeats alfil moves, so it would move on even squares, not odd.

For now I disabled automatic W* -> nW* interpretation on all pieces except the first. (As I think other diagrams would only use it for the first defined piece = Pawn.) This enabled me to define the Ninja Pawn as non-e.p.-capturable. The dependence of moveon the board half is taken care of a customized WeirdPromotion() routine, which promotes Ninja Pawns to 'Ninjas' (represented by the same image) when they enter the opponent half.