Single Comment

In developing the preset for Storm the Ivory Tower, I had to use some new
techniques, and they're worth passing along to any GAME Code developers
out there. In previous games, I have normally separated the code for
checking the legality of a piece move and for checking whether a piece is
checking the King. For the latter, I normally checked various locations
where checking pieces might be. Because Storm the Ivory Tower uses arrows
on squares to direct the movement of pieces, this approach would not work
without some added complication. So I took a different approach. I wrote a
subroutine, called checked, which simply loops through the enemy pieces,
checking in turn whether each one can legally move to the Brain's current
location. This subroutine made use of the same functions I wrote for
checking whether each piece can make a legal move. Since these functions
were now being used to evaluate potential moves, not just past moves, I
had to replace the capture operator in some functions with something like
'cond empty #0 capture (not empty #1)'. This first checks whether the
origin space is empty. It will be empty for a past move but not for a
potential move. For a past move, it just uses the capture operator to
check whether a capture has been made. For a potential move, it checks
whether a capture could be made at the destination by checking whether the
space is occupied. 

In presets for other games, I have taken the shortcut in the checkmated
subroutine of checking for check only from the piece moved and possible
revealed checks through the space it moved from. With the inclusion of a
hopper piece, the Clodhopper, I couldn't take this shortcut. If I tried
to, it would become less of a shortcut, for I would also have to check for
revealed Clodhopper attacks through both the origin and destination spaces
of a moved piece. So I took a different approach. Instead of using
separate checkmated and stalemated functions, I eliminated the checkmated
subroutine, and checked for checkmate simply by checking for check plus
stalemate with the separate checked and stalemated subroutines.

The upshot of all of this is that this is a streamlined approach to
writing code for enforcing game rules. It might not be as fast for the
server to execute, though I don't have benchmarks on this one way or the
other, but it will be easier for a programmer to write. It means skipping
the code for separately checking for check and checkmate and including
only one function apiece for how each piece moves. For examples of what I
have been describing, here is a link to the include file used for Storm
the Ivory Tower:

/play/pbm/includes/ivorytower.txt