Check out Chess with Different Armies, our featured variant for July, 2024.


[ 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/Ratings for a Single Item

Later Reverse Order EarlierEarliest
A Wizard for GAME-Code Generation. A tutorial on using the Play-Test Applet for automating Game Courier presets.[All Comments] [Add Comment or Rating]
💡📝H. G. Muller wrote on Thu, May 9 07:11 AM UTC in reply to Daniel Zacharias from Sun May 5 08:43 PM:

Should I be able to use $dest to get the destination square before HandleMove runs?

I suppose not, because to work with betza.txt the preset has the "do not add moves" checkbox ticked, so that Game Courier does not handle the move itself before it invokes to the Post-Move code. And I suppose $dest would be set during GC's handling of that move.

I am not even sure this variable would be set after HandleMove returns. At some point HandleMove passes the move to GC with the aid of an "eval MOVE: xxx" statement, but I am not sure whether this is equivalent to latting the move be handled automatically.

But HandleMove has its own variables to describe the move: #ori, #desti, #moved and #victim, which will be set after HandleMove returns. And for side effects: #promo, #suicide, #freedrop and #dropped. When not applicable the first three will have value 0, and #dropped will be undefined if #freedrop is invalid.

Anyway, HandleMove true starts with calling ParseMove true. This extracts the values for all these parameters in so far these were explicitly specified by the move notation. Implide side effects are then derived by generating all moves of the indicated piece, and match those with the move parameters that were given in the input notation. If there is a match it then takes the additional parameters from the generated move (such as #suicide when the move was an e.p. capture).

So in a code section where HandleMove is not useful (e.g. because you are in the prelude), and you don't feel like parsing the 'move' that the player entered yourself, you could call ParseMove if the syntax of what the player was supposed to enter is compatible with that of normal moves.


Daniel Zacharias wrote on Sun, May 5 08:43 PM UTC:

Should I be able to use $dest to get the destination square before HandleMove runs?


Jean-Louis Cazaux wrote on Tue, Jan 2 02:46 PM UTC in reply to H. G. Muller from 09:02 AM:

Thanks HG. After all, there is no real need of a diagram at all in (what I call) page 2. So I have modified the cases which were showing a diagram with a wrong piece set. I have removed those faulty diagrams.


💡📝H. G. Muller wrote on Tue, Jan 2 09:02 AM UTC in reply to Jean-Louis Cazaux from 07:41 AM:

2) a page "play" for presenting the GC preset where some information is duplicated, and the diagram is often shown with wrong pieces as it uses default pieces, like this one;

I never tried to publish a GC preset, but it seems to me that the diagram that is shown on that page is entirely the responsibility of the user. So if it doesn't show the same pieces as what the actual preset uses, it is because you ordered it to show different pieces.

You could even use an Interactive Diagram on that page, instead of a static one from the Diagram Designer. I recall that I made such a substitution on several GC pages, for variants that only appeared to exist on this site as GC presets, without a real article describing the rules. (Matts Winther's variants are typically presented like this; the GC page links to his own website for the rule descriptions.)

I agree that in most cases this page is entirely redundant, and just an annoyance to the user. There might be a reason for it if the same variant has multiple presets with different piece representation, to give the user a possibility to pick the representation he prefers.


Jean-Louis Cazaux wrote on Tue, Jan 2 07:41 AM UTC in reply to H. G. Muller from Mon Jan 1 11:14 PM:

This is just a testimony. I'm not a champion in coding and sometimes I don't understand 100% of what I'm doing, but the Wizard is really very good to generate a game code for GC. I have done it for Bigorra, for Camel Decimal Chess and yesterday for Patchanka. The only difficulty I had is when I have several different promotions to manage. I had to use the "morph" instructions and this is not given automatically by the Wizard. I solved my difficulty by copying from the Bigorra's GC where that issue had been solved for me by someone else.

What I found strange in the full process of submitting a new game with "all features inside" is to write 1) a regular page for presenting the game (in which I now put the ID in the Setup section) like this one; 2) a page "play" for presenting the GC preset where some information is duplicated, and the diagram is often shown with wrong pieces as it uses default pieces, like this one; 3) the preset itself where the Wizard is helpful indeed, like this one.

Maybe the process could be simplifed a bit, for instance I'm not sure that the page 2) is really useful.

I do not discard also that I'm doing something not optimal. I have often the feeling that Fergus, HG you are doing your best to help us (and you do it very nicely and kindly) but you do not always realize how much things looking simple for you can be difficult for common people with no specific education in coding.

 


Bob Greenwade wrote on Mon, Jan 1 11:43 PM UTC in reply to H. G. Muller from 11:14 PM:

For generating the preset additional information would be required. Such as the name of the game. I suppose I could add a field where you could enter that, and a button for creating a preset of that name.

That could be done, or just take the text "Invoke the preset" and add "(click here to start)" or some such. The simipler the better.


💡📝H. G. Muller wrote on Mon, Jan 1 11:14 PM UTC in reply to Fergus Duniho from 10:52 PM:

The Wizard generates GAME code. It does not create a preset.

For generating the preset additional information would be required. Such as the name of the game. I suppose I could add a field where you could enter that, and a button for creating a preset of that name.


🕸Fergus Duniho wrote on Mon, Jan 1 10:52 PM UTC in reply to Bob Greenwade from 09:57 PM:

Is it actually less important of a step than using the Play-Test Applet, which does have a link?

I never use this Wizard to generate presets, but I presume that using the Play-Test Applet is actually a step in using the Wizard, whereas starting with the default preset is no more of a step in this than having a blank canvas is a step in generating AI art.

Why not have a link here, where creating GC presets is already under discussion, than just assume that anyone would know where to look?

This page is about using a Wizard to generate a preset for you. It is not about making your own from scratch. For that, I would refer you to the Game Courier documentation and various tutorials.


Bob Greenwade wrote on Mon, Jan 1 09:57 PM UTC in reply to Fergus Duniho from 08:54 PM:

But it has nothing to do with the Wizard for GAME Code Generation.

Doesn't it? Is it actually less important of a step than using the Play-Test Applet, which does have a link?

Why not just look on the Game Courier page, where there is a link to it?

Why not have a link here, where creating GC presets is already under discussion, than just assume that anyone would know where to look?


🕸Fergus Duniho wrote on Mon, Jan 1 08:54 PM UTC in reply to Bob Greenwade from 07:45 PM:

But it has nothing to do with the Wizard for GAME Code Generation. Why not just look on the Game Courier page, where there is a link to it?


Bob Greenwade wrote on Mon, Jan 1 07:45 PM UTC in reply to Fergus Duniho from 07:37 PM:

That's precisely the link I was asking for. If H.G. would just (please!) put it into the article, I'd find this much, much easier.


🕸Fergus Duniho wrote on Mon, Jan 1 07:37 PM UTC in reply to Kevin Pacey from 07:12 PM:

I have wondered if a blank GC preset page (or Settings File) exists or can be created (page not being quite the right word for it, though I don't know what is, other than just calling it a preset, period).

There is no blank preset, but there is a default one with only default values. Just go to https://www.chessvariants.com/play/pbm/play.php without a query string.


Bob Greenwade wrote on Mon, Jan 1 07:36 PM UTC in reply to Kevin Pacey from 07:12 PM:

That's probably the easiest route currently. But if a blank one isn't possible, maybe the link can go to a preset for orthodox chess.


Kevin Pacey wrote on Mon, Jan 1 07:12 PM UTC in reply to Bob Greenwade from 06:14 PM:

I have wondered if a blank GC preset page (or Settings File) exists or can be created (page not being quite the right word for it, though I don't know what is, other than just calling it a preset, period). Except for the first one ever made, after Fergus made Game Courier, when there were zero presets. I have always just altered a preset made by someone, including myself, to begin making a preset for a CV of mine.


Bob Greenwade wrote on Mon, Jan 1 06:14 PM UTC:

This page really needs a button or link (somewhere in the last two paragraphs before "Alternative code for handling the mouse") to send to a blank GC preset page in a new window.


💡📝H. G. Muller wrote on Sun, Dec 3, 2023 07:29 AM UTC in reply to HaruN Y from 12:09 AM:

I was aware of Duck Chess, but because this needed an alternative search routine in the AI of the Interactive Diagram, I just hardcoded the rule there. And the generated GAME code would not work anyway, as it is a multi-move game. (And it is a 'never happens' case there anyway.)

In the ID the obvious way to specify it would be staleMate=loss. In the GAME code I could make it configurable through staledraw = -1, and make the Play-Test Applet generate that when it was specified in the ID. There would have to be a pull-down menu on that page for configuring the stalenate result then; a checkbox would no longer be enough.

BTW, the only practical consequence of this rule seems to be that some KPK end-games with edge Pawn can now be won. Usually not even the strong side cannot force the weaker opponent to stalemate him, and having stalemate a draw is already enough deterrent for the strong player not to do it. Losing Chess is of course an exception to this, as even a weak player can force a lot because of the mandatory capture.


HaruN Y wrote on Sun, Dec 3, 2023 12:09 AM UTC in reply to Daniel Zacharias from Sat Dec 2 10:39 PM:

Chaturanga, Misère, Anti-chess, Codrus Game, Take Me Chess, Duck Chess, couchtomato's variants shared in Discord at 14/11/2021 & 23/04/2022 (these 2 might be a mistake tho), Quinquereme Chess, Teutonic Knight's Chess, Mainzer Schach, Ghostarelay, etc.


Kevin Pacey wrote on Sat, Dec 2, 2023 11:22 PM UTC:

The Duke of Rutland's Chess is one CV where stalemating the opponent results in losing the game:

https://www.chessvariants.com/historic.dir/rutland.html

P.S.: It may be an interesting idea for this CVP website for members (and/or editor[s]) to tag games where stalemate is either a win for the player giving it, and/or a loss for the player giving it. Baring an enemy king seems to be always a win if opponent cannot retaliate next move (if not a drawn case like for some chess endgames), and a tag for such might be considered too [edit: Losing Chess is close to being an exception].


Daniel Zacharias wrote on Sat, Dec 2, 2023 10:39 PM UTC in reply to H. G. Muller from Fri Dec 1 02:43 PM:

Is this needed?

Not really. I was just looking and thought it should have been there. I don't know of any games that actually use it though.


💡📝H. G. Muller wrote on Fri, Dec 1, 2023 02:43 PM UTC in reply to Daniel Zacharias from Thu Nov 30 02:42 AM:

Is there a way to make stalemate a win for the stalemated player?

Currently not. Is this needed? It would not be difficult to add. Unfortunately not in a backward-compatible way that is also logical, as currently the stalemate result is controlled by a GAME-code variable staledraw, shich by default is set to 1, and specifies a draw for any non-zero setting. When set to 0, it makes stalemating a win. I could make it suche that setting it to a negative value makes stalemating a loss.


Daniel Zacharias wrote on Thu, Nov 30, 2023 02:42 AM UTC:

Is there a way to make stalemate a win for the stalemated player?


💡📝H. G. Muller wrote on Wed, Nov 8, 2023 06:16 AM UTC in reply to Fergus Duniho from Tue Nov 7 10:41 PM:

It should be fixed now; it had to do with the betza.txt script treating normal capture of a piece that could be e.p. captured also as e.p. capture, which removed the victim before the destination square was examined for its occupant. I now made sure the destination square is never included in the e.p. squares, when e.p. rights are created.

This makes the problem go away, but it would still not 'recruit' an e.p.-captured Pawn (where the destination square is empty). So we need to expand the code appended to the Post-Move sections a bit, by having it start with the line:

set victim cond #imp p #victim;

This makes the victim a pawn (p) for any move with implied side effects. (Which here are only e.p. captures.)


🕸Fergus Duniho wrote on Tue, Nov 7, 2023 10:41 PM UTC in reply to H. G. Muller from 09:22 PM:

it prints @, both for #victim and space #desti:

If space #desti is @, then victim will be set to @ no matter whether #desti and #ori are the same, because the cond statement will evaluate to @ either way.

But how can space #desti be @ on d4-e5 if the preceding move was e7-e5? I would have expected a Pawn there. The checkbox "Do Not Include Moves in Code" is ticked in this preset, so the Pawn should still be there.

Since your automatically generated code runs mainly in the Post-Game section, it works very differently than the code I usually write. I think Conquer would be simple to program in the usual way with the fairychess include file, but maybe it's not as simple for your automatically generated code.


💡📝H. G. Muller wrote on Tue, Nov 7, 2023 09:22 PM UTC in reply to Fergus Duniho from 05:44 PM:

But since you don't have check, maybe putting the piece back on the board will not affect the evaluation of which moves are legal. In that case, it may not be essential to deal with it during the simulation of potential legal moves.

Indeed, this is exactly why it is sufficient to just do this at the very end of Post-Move. The preset was automated through the betza.txt include, not by fairychess.txt, so it needs different code to do that from what you give.

I run into a problem that I don't understand, though. The code I suggested, which Gerd put in the preset, relies on the variable 'victim' to contain the captured piece. But printing it shows it is always equal to @ at the end of Post-Move. Even when I print it directly after the only place in betza.txt where it is set:

  set victim cond != #desti #ori space #desti @; // no self!
print . #ori . , . #desti . , #victim;
print space #desti;

it prints @, both for #victim and space #desti:


d2,d4,@
@
e7,e5,@
@
d4,e5,@
@

But how can space #desti be @ on d4-e5 if the preceding move was e7-e5? I would have expected a Pawn there. The checkbox "Do Not Include Moves in Code" is ticked in this preset, so the Pawn should still be there.


🕸Fergus Duniho wrote on Tue, Nov 7, 2023 05:44 PM UTC in reply to Gerd Degens from 05:25 PM:

It would look like a simpler form of what Shogi does, as it would move the piece to an already identified space.

if capture:
  set mynewpiece flipcase realname alias $old;
  add #mynewpiece $origin;
endif;

This should work if you're not using aliases:

if capture:
  add $old $origin;
  flip $origin;
endif;

It looks like the code for Shogi omits doing this in the stalemated subroutine, as moving a captured piece off-board does not affect whether the move leaves the King in check. If your game had check in it, you might have to deal with this in the stalemated subroutine. But since you don't have check, maybe putting the piece back on the board will not affect the evaluation of which moves are legal. In that case, it may not be essential to deal with it during the simulation of potential legal moves.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.