H. G. Muller wrote on Sat, Jul 25, 2020 12:42 PM UTC:
It seemed best to start an independent comment thread for this. The goal of this project is to develop GAME code that can be almost universally used for rule enforcement in Game Courier presets. The rules that will be enforced (piece moves, possible promotions, initial piece shuffling) will be encoded in some tables, which are then initialized in the Pre-Game section. These CV-specific tables can then be hand-coded, but also generated automatically through the Play-Test Applet, and copy-pasted in the Pre-Game section from there.
To not get ahead of ourselves, the project will be divided into several phases, where each phase would correspond to a functional preset, which will progressively allow less and less violation of the game rules. Phase 0 will test the basic method of handling the moves. To remain in full control over vetting and performing the moves, the preset will be created with the checkbox "do not include moves in GAME code" ticked. This means the preset would not do anything at all with entered moves, unless the Post-Game code tells it what to do.
The minimum requirement is thus to let the Post-Game code order execution of the entered move(s). This will already be done the way the finished project would do it: all code for handling a move will go into a subroutine HandleMove, and the only code in the Post-Move sections will be calling this subroutine:
gosub HandleMove false;
and
gosub HandleMove true;
where the Boolean parameter indicates whether the black player is making the move. The Pre-Game code for phase 0 will define the subroutine as:
setsystem maxmove 4;
ban commands;
sub HandleMove player:
eval join "MOVE: " thismove;
endsub;
This will order Game Courier to do what it would have done automatically if we hadn't ticked the checkbox: perform the move exactly as entered, "no questions asked". For now the input can consist of any combination of up to 4 moves, promotions, drops, etc.
In phase 1 the input move will be tested for syntactical correctness, before we allow its execution.
It seemed best to start an independent comment thread for this. The goal of this project is to develop GAME code that can be almost universally used for rule enforcement in Game Courier presets. The rules that will be enforced (piece moves, possible promotions, initial piece shuffling) will be encoded in some tables, which are then initialized in the Pre-Game section. These CV-specific tables can then be hand-coded, but also generated automatically through the Play-Test Applet, and copy-pasted in the Pre-Game section from there.
To not get ahead of ourselves, the project will be divided into several phases, where each phase would correspond to a functional preset, which will progressively allow less and less violation of the game rules. Phase 0 will test the basic method of handling the moves. To remain in full control over vetting and performing the moves, the preset will be created with the checkbox "do not include moves in GAME code" ticked. This means the preset would not do anything at all with entered moves, unless the Post-Game code tells it what to do.
The minimum requirement is thus to let the Post-Game code order execution of the entered move(s). This will already be done the way the finished project would do it: all code for handling a move will go into a subroutine HandleMove, and the only code in the Post-Move sections will be calling this subroutine:
and
where the Boolean parameter indicates whether the black player is making the move. The Pre-Game code for phase 0 will define the subroutine as:
This will order Game Courier to do what it would have done automatically if we hadn't ticked the checkbox: perform the move exactly as entered, "no questions asked". For now the input can consist of any combination of up to 4 moves, promotions, drops, etc.
In phase 1 the input move will be tested for syntactical correctness, before we allow its execution.