🕸📝Fergus Duniho wrote on Sat, Mar 12, 2022 06:04 PM UTC:
Besides using the fairychess include file, the new Shogi preset uses its own fairyshogi include file. Here I'll go over some of the new features in this include file.
Besides using -Range functions to indicate the range of movement of a piece, this include file uses -Drop functions to indicate which spaces a piece may be legally dropped on. The stalemated function uses a foreach-next loop to go through all empty spaces on the board, and it tests each space with the Drop function for the piece to be dropped. The simplest Drop function looks like this:
def Unrestricted-Drops #0 or true;
This just returns true, and it gets copied to every piece that can be dropped to any empty space like so:
foreach notation array r R b B g G s S:
set funcname join const #notation "-Drop";
copyfn Unrestricted-Drops #funcname;
next;
Lances and Knights have slightly more complicated Drop functions:
def White_Lance-Drop onboard where #0 0 1;
def Black_Lance-Drop onboard where #0 0 -1;
def White_Shogi_Knight-Drop onboard where #0 0 2;
def Black_Shogi_Knight-Drop onboard where #0 0 -2;
Instead of testing for specific ranks, these use onboard and where to test whether there is a space on the board one or two spaces ahead of the location the piece might be dropped on. This works better with boards of different sizes than naming specific ranks would.
The Pawns have the most complicated Drop functions:
def White_Shogi_Pawn-Drop allfalse lambda (== const space #0 White_Shogi_Pawn) merge ray #0 0 1 ray #0 0 -1 and onboard where #0 0 1;
def Black_Shogi_Pawn-Drop allfalse lambda (== const space #0 Black_Shogi_Pawn) merge ray #0 0 1 ray #0 0 -1 and onboard where #0 0 -1;
Beginning at the end, these first make the same test as the Lance's Drop functions do. Next, they test whether there is another Pawn on the same file. This is done by passing allfalse a lambda function that takes as its input an array of all the spaces in the file except the one the Pawn may potentially drop to. Whether this is an actual or a potential move, this space does not need to be tested. For an actual move, the Pawn will already be there before the test is performed, and for a potential move, a drop there would not be considered unless this space were already empty. To test the other spaces, the code uses the codename for the type of Pawn being checked. This is to prevent the function from being dependent on specific notation for a piece.
This function does not test whether a Pawn drop will checkmate the King. This last test is done within the stalemated subroutine after temporarily dropping the Pawn.
Because not all piece labels are entirely alphabetic, it now uses haslower and hasupper instead of islower and isupper to identify which side pieces are on.
Because functions are normally global, the stalemated and matedbypawn subroutines do not define functions within themselves. Instead of defining the friend function, they set the variable friend to a lambda function that gets called by fn #friend. Instead of defining the friends function, they set the friends variable to an array of all pieces on the same side. Unlike functions, these are kept local to the subroutine they were created in, allowing matedbypawn to use some of the same variable names as stalemated without messing up the assignments stalemated has made to variables with the same name.
Besides using the fairychess include file, the new Shogi preset uses its own fairyshogi include file. Here I'll go over some of the new features in this include file.
Besides using -Range functions to indicate the range of movement of a piece, this include file uses -Drop functions to indicate which spaces a piece may be legally dropped on. The stalemated function uses a foreach-next loop to go through all empty spaces on the board, and it tests each space with the Drop function for the piece to be dropped. The simplest Drop function looks like this:
This just returns true, and it gets copied to every piece that can be dropped to any empty space like so:
Lances and Knights have slightly more complicated Drop functions:
Instead of testing for specific ranks, these use onboard and where to test whether there is a space on the board one or two spaces ahead of the location the piece might be dropped on. This works better with boards of different sizes than naming specific ranks would.
The Pawns have the most complicated Drop functions:
Beginning at the end, these first make the same test as the Lance's Drop functions do. Next, they test whether there is another Pawn on the same file. This is done by passing allfalse a lambda function that takes as its input an array of all the spaces in the file except the one the Pawn may potentially drop to. Whether this is an actual or a potential move, this space does not need to be tested. For an actual move, the Pawn will already be there before the test is performed, and for a potential move, a drop there would not be considered unless this space were already empty. To test the other spaces, the code uses the codename for the type of Pawn being checked. This is to prevent the function from being dependent on specific notation for a piece.
This function does not test whether a Pawn drop will checkmate the King. This last test is done within the stalemated subroutine after temporarily dropping the Pawn.
Because not all piece labels are entirely alphabetic, it now uses haslower and hasupper instead of islower and isupper to identify which side pieces are on.
Because functions are normally global, the stalemated and matedbypawn subroutines do not define functions within themselves. Instead of defining the friend function, they set the variable friend to a lambda function that gets called by fn #friend. Instead of defining the friends function, they set the friends variable to an array of all pieces on the same side. Unlike functions, these are kept local to the subroutine they were created in, allowing matedbypawn to use some of the same variable names as stalemated without messing up the assignments stalemated has made to variables with the same name.