Custom Search

Item Index Information

A Wizard for GAME-Code Generation is a game information page. It is categorized as: Orthodox chess, .

A Wizard for GAME-Code Generation. A tutorial on using the Play-Test Applet for automating Game Courier presets.

Other Information

The board used for this game has 8 row(s), 8 column(s), 64 cells/squares.
This game is a 2 player game.
Invented in the year 2020. [2019-2021]. [2015-2025].

Other Options

Browse items that also start with the letter A.
Browse items that also start with the letters A .
Browse items that also start with the letters A W.
Browse similar items.
Browse items with a similar board.
Add a comment or rate this item.
Skip to comments section.

Index Maintenance

[edit] [links] [associate image] [associate text] [info] [quick edit]

Group ID 'game-code-genera'

This site is supported by advertising and by donations. You can help out by making a small donation or by using this site's affiliate links when you shop at ebay.com or Amazon.com.

Credits

By H. G. Muller.

Comments

A Wizard for GAME-Code Generation. A tutorial on using the Play-Test Applet for automating Game Courier presets.

Fergus Duniho wrote on 2020-12-31 UTC

Just to be sure: I can use the word 'resign' as a string literal expression > operand without it being confused for a command? Like
if == resign thismove:
 resign
endif;

Yes, but you should include a semicolon after the second line. Without it, this code would result in an error.

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

Just to be sure: I can use the word 'resign' as a string literal expression operand without it being confused for a command? Like

if == resign thismove:
  resign
endif;

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

OK, thanks. This will make life easier, as indeed I would otherwise have had to break from several levels of subroutines.

Some explanation: the error message was from my own parsing routine. My code works by comparing the input move to all legal moves generated in the position before the move, and it needs a complete description of the move to do that. (Not only the basic move, but also optional freedrops or suicides that occur as (possibly mandatory) side effects.) So I don't rely on move parsing as it occurs when you feed a move primitive to GC through a MOVE: prefix, as this would also change the position, but wrote my own parser that extracts all square coordinates and piece labels from all primitives. Which again is called from another 'do everything' subroutine so that users only have to put a single subroutine call in the Post-Move sections. So if the parser doesn't see a hyphen in a move primitive, it exits through die without any of the primitives having been fed to GC.

Fergus Duniho wrote on 2020-12-28 UTC

What is the recommended way to handle resign (or drawn) in presets that have the checkbox ticked to not include moves in the code?

I don't believe the issue is with that in particular. In tests I just did with Extra Move Chess, resign and drawn worked as they should. Your code does some things differently, which I already mentioned below.

The GAME-code manual says that resign should not be used in code,

That may be a suggestion. I tried it directly in the code, and it did work. It made White resign as soon as he entered his first move.

but when I don't do anything about it, attempts of a user to resign will just draw an 'invalid move syntax' error message.

Is that the precise wording of the error message? Using multiple grep searchs, I did not find any text, PHP, or JavaScript file with code for that error message.

I can of course test for the input command to be 'resign' at the start of the ParseMove subroutine (and for efficiency reasons only do that test on the final move of the sequence, or even defer it to the point where it is rejected as a valid move). But what should I do then?

Yes, it may be a good idea to detect it before processing the move. If you are evaluating moves before playing them on the board, you want to evaluate resign and drawn moves differently. In Extra Move Chess, the code plays each move on the board before evaluating it. This is probably why it has no problem with resign or drawn.

Prefix thismove with MOVE: and offer it for execution?

That's what I would recommend. In general, you should be doing that for every move somewhere in your code.

And what happens to the control flow after that? Will it terminate execution of the remainder of the Post-Move code, or should I explicitly abort execution after it?

The resign, lost, won, and drawn commands all include return, which will exit the run_subroutine() function. This will end the current subroutine, and if the command occurs at the main level, this will end the entire GAME Code program. When moves are automatically included in the code, they are placed at the main level between the Pre-Move and Post-Move subroutine calls. But if you are executing the command from within a subroutine, it will exit only that subroutine, and program execution will continue from the point after that subroutine was called.

I have just modified these commands to exit the program entirely using the same method as the new exit command.

Incidentally, the end and stop commands are not particularly useful here. The end command works only on the main level, and the stop command just returns from the innermost call to run_subroutine(). ~~There is no command for halting program execution from within a subroutine.~~* The die command uses PHP's exit() function, which exits the whole PHP script, but that's overkill for naturally ending the game. Ideally, you should be using MOVE: at the main level, or when your subroutine comes across resign or drawn, it should exit the subroutine with an error code, and the following code should immediately check whether the error code has been given and take appropriate action at the main level if it has.

* I just added the exit command, which does exit the GAME Code program.

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

@Fergus:

What is the recommended way to handle resign (or drawn) in presets that have the checkbox ticked to not include moves in the code? The GAME-code manual says that resign should not be used in code, but when I don't do anything about it, attempts of a user to resign will just draw an 'invalid move syntax' error message. I can of course test for the input command to be 'resign' at the start of the ParseMove subroutine (and for efficiency reasons only do that test on the final move of the sequence, or even defer it to the point where it is rejected as a valid move). But what should I do then? Prefix thismove with MOVE: and offer it for execution? Put resign in the code after all? And what happens to the control flow after that? Will it terminate execution of the remainder of the Post-Move code, or should I explicitly abort execution after it?

As this seems a general problem with not including moves in the code, and resigning games seems a universal feature that should never be tampered with, I wonder if it wouldn't be a better solution to exempt resign from not being included in the code, and have Game Courier always recognize and execute it, irrespective of the checkbox setting.

List all comments and ratings for this item.

Add a comment or rating for this item.

Advertising Privacy

https://www.chessvariants.com/index/displayitem.php
First Created: Sunday, August 16th, 2020
Last Modified: Sunday, August 16th, 2020
[info] [links] [edit] [quick edit]