The Chess Variant Pages
Custom Search




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

Comments by H. G. Muller

Later Reverse Order EarlierEarliest
UPDATED! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-10-10
 By Daphne  Snowmoon. Nine elders (구로九老). (Updated!) Sittuyin + Shogi.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-16 UTC

No. Members can see submissions too, nowadays. You would not be able to see it if you are not signed in. It is not published.


Diagram testing thread[Subject Thread] [Add Response]
H. G. Muller wrote on 2020-10-15 UTC

Fairy-Max confirms the given position is mate in 4. It prefers a slightly different line:

d5c3 b1a1 e3c2 a1b1 c2d2 b1c1 c3d1

In general 3-vs-1 end-games are very easy once the bare King is trapped in a corner (say resticted to a1-b1), You just approach with your second piece, and position it for the kill. The 3-vs-1 checkmating applet discusses what the requirement for the pieces is to be able to make that final kill. In this case it is even easier than usual, because the Wazir-Maos are so powerful that there are already checkmate positions that do not even need the white King. (Like the one Fairy-Max ends up in.) These can provide additional threats next to the normal patterns.

The hard part is usually to get the King in that corner.


This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2015-03-16
 Author: H. G.  Muller. Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-14 UTC

Yes, HaChu was written by me, and yes, I am in practice the only WinBoard/XBoard developer. PM on WinBoard forum is not really a good way to reach me, as my inbox there is overflowing. TalkChess.com would be a better forum, but for private communication e-mail would be preferable. However, I usually prefer public over private communication; most things that are discussed tend to be useful for others as well.

The mnemonic pieces were indeed conceived from the wish to be able to play these horrendously large games with virtually no learning at all, because 95% of the piece symbols unambiguously indicates its move. So you only have to worry about a hand-full of (often very special and very powerful) pieces, such as Lions, Teaching Kings and Fire Demons.

It is great that you are working on a replacement for the 81Doju Chu-Shogi website. In practice it might be difficult to get the population of that website to migrate to yours, through, no matter how nice it is. Especially the Japanese players. Setting up a new site also means the loss of the database of all games that have been played so far. Perhaps it would have a better chance of success if you would just build a new client for the existing 81Dojo Chu server.


H. G. Muller wrote on 2020-10-13 UTC

@Alex - The mnemonic pics here were copied from WinBoard by taking screenshots, where I used a general-purpose drawing program to make the background transparent. WinBoard creates those images on-the fly, from components that represent the move in one direction (but i a way depending on the range in adjacent directions), plus a central dot. In order to draw an edge around that for the outline pieces, it creates a black image first, and overlays it with a slightly smaller white image, so that a black outline remains. The largest size is 33x33, though, and the images are not anti-aliased.

I remember having made a set of SVG images for each of the individual pieces, for XBoard, though. I am pretty sure this includes all the Chu-Shogi pieces, and probably also the Wa-Shogi pieces. I would have to dig that up; I could not find it on my website.

Interesting that there now is a new Chu-Shogi engine. How strong is it, compared to HaChu?

As to larger variants: I have a pretty strong engine for Tenjiku Shogi. (Not yet released; I am still planning to do that.)

I am not on Facebook.

[Edit] Oh, I see. The engine actually is HaChu. It is only the interface that is new.

[Edit2] I found the SVG pieces, and uploaded the whole project to http://hgm.nubati.net/Mnemonic-S.tar.gz .


This item is a reference work
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-06-16
 By H. G.  Muller. Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-12 UTC

It would be even nicer if instead of a button that shows you the GAME code so that you can copy-paste it, there would be a button 'Create Preset'. Which would send the HTML requests to the server (through AJAX calls) that are needed to open the preset edit page, and deposit the the code there as if the Save button was pressed. This should be technically possible, as the pages are on the same server.

Of course the user should then have to supply the name of the variant, and the name of the settings file first. But there could be text entries for those. The Wizard could in response display the link through which you can edit the created preset. Or perhaps open that preset in edit mode itself, in another browser window. The user would then only have to adapt the settings for the graphics (color, piece theme...).


H. G. Muller wrote on 2020-10-12 UTC

The Play-Test Applet indeed adapts the default King move to the board width, by making the castling end as usual w.r.t. the corners. Identifying the castling partners is a bit tricky, though. Originally the Interactive Diagram allowed castling with corner pieces and Rooks (which in some variants start closer to the King). For the AI this was not acceptable, so I added code to scan the board to locate the piece that can castle, look how wide the rank is that it is on (the board could be irregular, or have holes, e.g. Omega Chess), and defines the extreme squares as 'corners'. If those squares are empty, it scans the rank towards the King to find a piece. Later I implemented the j modifier to explicitly shift the castling square inward (so the AI could also do Omega Chess, where the square behind the Rook is not empty).

In the Wizard Tutorial I state that if you are not interested in the FEN, you can just put one piece of every type you need on the board. I realize now that this is wrong: You need to put the someting at the edges on the King rank to get the correct castling partners. I guess I should alter the Diagram script to entirely rely on the j (and board holes, if any) for identifying the castling partners, irrespective of whether these are empty in the initial position. That makes the generated GAME code less dependent on the initial setup. The King would still have to be in the right place, though.

I am glad you like it. For variants with less-typical rules, such as the Jumping Chess, one still has to write GAME code. But often that can be limited to code to implement the non-standard rules. I try to make this as simple as possible, though. Confinement to board zones (at the pseudo-legal level) can now be enforced by just defining a single function for vetoing moves based on the square coordinates of those. I am not entirely happy with that yet, because it does not pass the location of any hopper mount. So it cannot be used to implement the Janggi rule that Cannons cannot jump over Cannons. In the Diagram hops are treated transparently, though: you don't have to indicate the mount when entering the move. As a consequence there can be an arbitrary number of them. Perhaps I should have the move generator remember what was the last piece hopped over, and also pass that to the user-supplied routine.

For larger flexibility I guess it would be good to allow a user-supplied callback for the move generator, so make it easy to call it for your own purposes. Like testing whether there exists a move that is mandatory (by whatever criteria you want).


H. G. Muller wrote on 2020-10-11 UTC

Well, the JavaScript in the wizard page that flushes the GAME code uses this line for generating the promotion array:

        if(choice[i] != 3) psupply += ' ' + ids[i] + ' ' + ids[i].toLowerCase();

The array ids[] contains the piece IDs. It does not take them directly from the promotion string you typed; this just determines the content of the array choice, encoding what type of promotion this is (e.g. to captured pieces only). Only the second occurrence is forced to lower case, and if the IDs already where lower case, the first one stays that. Normally the Diagram takes the IDs as first letter of the name (when not explicitly given in the piece definition), capitalizing it. But in the Play-Test Applet you then in general change the name and the ID (and move). So the likely explanation is that you typed a lower case ID when altering ID / name and move for Wolf and Eagle.

I suppose I should just write ids[i].toUpperCase() for the first occurrence, to exclude this. Or perhaps already convert the ID to upper case in ids[] when you alter it.

I looked at the code in the preset, and I still see one issue: the castling partners do not seem to be defined correctly (e1 e1 e12 e12) instead of (a1 l1 a12 l12). I don't know how that could have happened. This game has castling, does it not? The Interactive Diagram made by Aurelian defines the King move as KisO3.


This item is a reference work
It belongs to categories: Orthodox chess, 
It was last modified on: 2017-08-11
 Author: Fergus  Duniho. Game Courier Developer's Guide. Learn how to design and program Chess variants for Game Courier.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-11 UTC

So, I added some documentation for it in the area you quoted from.

To make sure I understand this: the formal parameters of the function will have to be written at the end of the function, each prefixed with '=', in the order the corresponding actual parameters will appear in the function call? And the function call will then 'eat away' always that number of parameters from the stack, whether they are used or not? So I could write something like

def BadZone == 9 rank #destination =origin =destination =locustsqr =dropsqr =droppedpiece;

to get a function called with 5 parameters, and only testing if the second is on rank 9?


H. G. Muller wrote on 2020-10-11 UTC

How sure are you that you changed it back to what it was? Did you safe the old version, and moved it back?

This kind of thing usually happens to me when I accidentally made some unintended changes (e.g. drag-drop something because of a mouse glitch without noticing it, or leaning on the keyboard), and then reverting the intended changes then of course doesn't help. Under Linux I now use git for version control, so there I can always revert to any previous version. (And more importantly, just look at the diff with such a version, to see if anything untoward happened.)

I am afaraid that debugging it again is the only alternative.

[Edit] It could also be that FireFox was updated, and is not so forgiving as a previous version anymore. I know that I initially had uploaded the JavaScript for the Interactive Diagram with a PNG extension. This worked for a long time on FireFox, but at some point it stopped working, and it would only consider scripts in a .js file.


This item is a reference work
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-06-16
 By H. G.  Muller. Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-11 UTC

Yes, you did that right; it is supposed to work that way. But I had not implemented setting of e.p. rights by a W* move in the betza.txt include. (Which needs other code than that for setting the rights on a lame leap, which sets them on jumped-over squares rather than visited squares.) In fact I had not implemented the W* at all, yet. The Betza compiler encodes this special case by specifying a range of -1, but the interpreting GAME code should then of course recognize this special case, to recalculate it as the distance of the fromSqr to the board middle. I quickly added the code for that yesterday evening, when I saw you would need it.

I added the code for setting the e.p. squares now, and tested it in the preset you made.


H. G. Muller wrote on 2020-10-11 UTC

Are you sure you saved the code twice, after you moved the gosub GameEnd from the Initial-Moves section to Post-Game2? Very often changes become only effective after the second time. I have had to go through dozens of times through the sequence Play - Bug manifests itself - Menu - Edit - Fix the bug - Save - Menu - Play - Bug still manifests itself - Menu - Edit - (Inspect code, bugfix is already there) - Save - Menu - Play - Bug no longer manifests itself. If you saved only once, chances are that the preset still thinks the gosub is in the Initial-Moves section, even though the Edit function does no longer show it there. With Game Courier, what you see is not always what you get.


H. G. Muller wrote on 2020-10-10 UTC

That is weird. It also says:

And for general reference, here is the complete list of moves:

1. gosub GameEnd true;

So it thinks the GAME code in the Post-Game2 section is a move?! That surely explains why it complains about the move syntax. It baffles me how it could ever start to parse its own code as if it were a move. Perhaps Fergus has an idea how this can happen? I suspect the presence of this in the Initial-Moves section did some persisting damage to the entire preset.

It is midnight here now; if the problem still exists tomorrow I can look at it further.


H. G. Muller wrote on 2020-10-10 UTC

You pasted the call to GameEnd for black in the "Initial Moves" section, instead of the Post-Game2 section.


UPDATED! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-10-02
 By Peter  Aronson. Jumping Chess. (Updated!) Pieces capture by jumping. Board has extra edge squares making it 10x10. (10x10, Cells: 100) [All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-10 UTC

Zone confinement now also works for the highlighting, with the aid of the 'user-supplied' BadZone function. And I have implemented non-final-leg e.p. capture in the betza.txt include file now, so that works too.

Only remaining imperfection is that when an edge capture is mandatory it still highlights other moves.


This item is a reference work
It belongs to categories: Orthodox chess, 
It was last modified on: 2017-08-11
 Author: Fergus  Duniho. Game Courier Developer's Guide. Learn how to design and program Chess variants for Game Courier.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-10 UTC

The highest numbered placeholder should not exceed the number of different placeholders that you use. So, for example, if you use #4 as a placeholder, you should also include #3, #2, and #1.

I have just been waging a battle with this rule. This really is an extremely troublesome property of GAME code; is it really necessary to treat functions so sloppily? I understand that you somehow have to know how many arguments a function call has to delete from the stack. But why does it care if the earlier arguments are actually used to compute the function result? It should be able to just ignore them.

I have an application where I want to make it possible for a user to supply a function that could veto a normally valid pseudo-legal move generated by the library code, e.g. because it lands outside a confinement zone as in Xiangqi, or captures a piece type it should not be able to capture (e.g. the Jianggi Cannon x Cannon ban). To this end the library code has to call that function from some appropriate place, and it passes all the available information about the move to it, because there is no telling what kind of conditions the variant imposes. So it passes origin, destination, optional locust-capture square all to the function. But in individual cases the decision might require one some of the items (e.g. just the destination). It is really inconvenient having to include dummy operations on all the unused arguments. It completely mystifies a function that a user of the library would have to supply (and is bad for efficiency). Currently I work around it by writing something like

def BadZone cond 1 fn Edge #1 join #0 join #2 join #3 #4;

where the entire join club is just there to produce a dummy result that is never used (but cannot even be parenthesized to suppress its evaluation, as then the trick doesn't work anymore).

 


H. G. Muller wrote on 2020-10-10 UTC

With 'captured' Jose might not refer to $lastcaptured, but to the places displayed next to the board. I understood that GAME Courier just calculates those as the difference between initial and current pieces, irrespective of how the missing pieces disappeared. That would confirm the reported behavior of empty. But it seems to be intended.


UPDATED! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-10-02
 By Peter  Aronson. Jumping Chess. (Updated!) Pieces capture by jumping. Board has extra edge squares making it 10x10. (10x10, Cells: 100) [All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-10 UTC

OK, that should simplify highlighting of legal moves. But the rule that (some) captures are mandatory actually is another global rule that creates a difference between legal and pseudo-legal. In Losers Chess this rule has lower priority than the checking rule, here it seems to have higher priority, even when the checking rule would be employed. Pseudo-legal highlighting will be easy here. It will still require me to put a 'hook' into the general code with which a user can interface his own code for the zone confinement; I will make this a function call that passes the full move (fromSqr, toSqr, locustSqr, dropSqr and droppedPiece), which returns whether the move is pseudo-legal, but for efficiency will only be called when a global flag 'zonal' is set.) Besides confinement, such a user-supplied function can also be used for enforcing restrictions what peiec types can capture each other.

It has been useful to attempt this, because it made me discover that the Diagram code had suffered a regression: the Betza compiler used to flag which pieces are inversion-symmetric, so that the GAME-code generator in the wizard page could draw on this to decide whether separate table entries should be made for white and black pieces. This code had disappeared!

I am now thinking how the general GAME-code in the include file could be enhanced in order to interface with variant-specific code. Rule enforcing is in general easy, as when there are extra global rules that outlaw some pseudo-legal moves, you can just test for compliance to these independently of the normal code (e.g. before you call the latter), and 'die' if they are violated. But legal-move highlighting requires such a compliance test to be called from somewhere deep inside the standard code, after the MakeMove of of every pseudo-legal move. Normally the code only does a check test there, and pushes the moves to the legal list when it doesn't expose the King.

The problem with mandatory capture is that you have to know in advance whether such a capture is possible to judge whether a non-capture (or in this case also a non-mandatory capture). An obvious way to do that would be to first make a list of all moves that are legal ignoring the rule, and then test whether there is a mandatory one amongst these. If there is, all non-mandatory moves should be purged from the list. This could be done entirely after the standard code. If I would know how to revoke a previous setlegal command.

@Fergus - What would be the best way to manipulate the $legalmoves array, if I want to remove some moves that in hindsight must not be highlighted after all? Would the following code work?

set tmp $legalmoves;
setsytem legalmoves array; // clear the legal list
for m #tmp:
  if fn SomeTest #m:
    setlegal m;
  endif;
next;

I have another question about GAME-code syntax. In

if fn F X or B:

would this be read as if( B || F(X) ) or as if( F(B || X) )?


H. G. Muller wrote on 2020-10-09 UTC

This is a quick approximation:

https://www.chessvariants.com/play/pbm/play.php?game%3DJumping+Chess%26settings%3Djumping&submit=Edit

It enforces the rules (except that e.p. capture does not work, but this would have to be solved in the included library file). It doesn't properly highlight legal moves, though.

It is not clear to me whether this variants employs the check rule; the explanation of mandatory capture suggests it has not, as it talks about capturing the King. An alternative would be to consider the position a checkmate, as you only can do the capture with the edge piece, and it does not resolve the check.

The betza.txt library should have some feature similar to the BadZone hook for the Interactive Diagram, where the user can define a function to enforce confinement of pieces to zones. When such a function is defined each generated move should call it to check whether the move obeys the confinement rules.


H. G. Muller wrote on 2020-10-09 UTC

Well, the idea was of course to let the GAME-code wizard do most of the work, starting from an Interactive Diagram made through the Play-Test Applet. It took a few minutes to create this with the Applet:

files=10 ranks=10 promoZone=2 promoChoice=QNBR graphicsDir=/graphics.dir/alfaeriePNG/ squareSize=50 graphicsType=png pawn:P:ifmnDfmWfceamfF:pawn:b3,c3,d3,e3,f3,g3,h3,i3,,b8,c8,d8,e8,f8,g8,h8,i8 knight:N:mNcafsmK:knight:c2,h2,,c9,h9 bishop:B:mBcafmB:bishop:d2,g2,,d9,g9 rook:R:mRcafmR:rook:b2,i2,,b9,i9 queen:Q:mQcafmQ:queen:e2,,e9 king:K:mKcafmKisjO2:king:f2,,f9

which does take care of the piece moves. (But not of the zonal confinement / mandatory capture.) Which has one defect, though: the e.p. capture does not work when specified on a non-final leg. At least in the move generator used for highlighting, the AI could be more accurate. I recall encountering this issue many times during programming the stuff, and each time I thought "a locust e.p. capture? Nah, that will never be needed." Obviously I was wrong. So I might have to shape up the move generator here and there, also the one I wrote in GAME code. The move tables the Betza compiler generates for this are OK, but the code that interprets them unjustly assumes an e.p. leg always is the last leg of the move.

Enforcing the rule that non-captures cannot go to an edge in the GAME code is pretty trivial; the mandatory capture is more tricky, though. In particular in combination with legal-move highlighting. I guess it would be useful to extend the move generator in the GAME-code include file with a task that would test whether there exists a legal or a pseudo-legal capture, very similar to how it checks whether there exists a legal move. Perhaps the existing code can be used for that, by introduction of a global flag that tells it to ignore non-captures. The Post-Move code for the latest move of the game could then start calling the move generator for this task for all pieces on the edge, if the move in question was a non-capture or did not start from the edge. Existence of a capture from the edge would then make the move illegal. In other cases the mandatory-capture requirement is fulfilled, and the standard procedure (which doesn't take it into account) can be called.

BTW, the Diagram's AI does think the Knight is worth more than a Bishop. For each capture target the Knight also has two possible final squares.


UPDATED! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-10-11
 By Aurelian  Florea. I-Chess. (Updated!) Large board variant that adds two more piece types: the wolf and the eagle.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-09 UTC

It doesn't matter much in which language they are, as the lettering is too small to read anyway.

What intrigues me, though, is that the left document has the map of Netherlands / Belgium / Luxemburg as a logo (in the colors of the Belgian flag).


H. G. Muller wrote on 2020-10-08 UTC

But the Interactive Diagram does allow one to play it here, against the AI...


H. G. Muller wrote on 2020-10-08 UTC

But that is a pretty big IF, I would say... And it might actually make it illegal to publish the game here at all.


H. G. Muller wrote on 2020-10-08 UTC

A (non-capturing) move up to half-way the board is fmW* in the Diagram. You could make that an ifmW* if it is only from the initial position. A Pawn with such a move would also have been in stock, as 'omega pawn'. On such very deep boards the e.p. capture would not completely work, though, as the Diagram handles at most two e.p. squares. (The AI should do it correctly, though.)


This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2018-07-27
 Author: Fergus  Duniho and Jean-Louis  Cazaux. Janggi - 장기 - Korean Chess. The variant of chess played in Korea. (9x10, Cells: 90) (Recognized!)[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-08 UTC

Isn't it a bit strange that we rely on (old and disagreeing) western sources, while in this age of the internet it should be easy to get feedback directly from Korean players? Discussing disagreements between Gollon, Murray and Pritchard might be interesting in an article reviewing their books, but mistakes they might have made do not deserve to be mentioned in a rule description of the game. I never mention the 'Murray Lion' in the Chu Shogi article...

The Fairy-Stockfish developer has included Janggi in his engine now, and claims to have received a lot of feedback during its implementation from Korean amateur and pro Janggi players. I believe him. Which means I consider the current rule implementation in Stockfish to be reliable. Notable point in this are:

  • Turn passing is always unconditionally allowed, not just when it is forced.
  • The Bikjang rule for King facing is not applied in every tournament. If it is not, King facing is legal.
  • If it is, but is declined, it has (indeed) no effect on the possibility to win later for either player.
  • The point-counting tie breaker is not applied in every tournament.

So there are actually four sub-variants, bepending on application of Bikjang and point-counting rule.

It also seems wrong to describe Bikjang as "the Generals checking each other". Check is an imminent loss because of King capture. There is neither loss or King capture here, just a draw offer that can be accepted or declined. The whole idea that King facing is a check seems to be contamination by Xiangqi concepts.


UPDATED! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-10-11
 By Aurelian  Florea. I-Chess. (Updated!) Large board variant that adds two more piece types: the wolf and the eagle.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-10-08 UTC

I think the problem is that no royal is explicitly defined, so that the Eagle is taken to be royal. This somehow tickles a bug in the Diagram, as I run into the JavaScript error message 'aSide' undefined. So it somehow wasn't able to locate the castling partners because of this royalty issue.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.