I am wondering whether I should make hop-restrictions a standard feature of the Interactive Diagram. This could for instance be done through the captureMatrix parameter. That already has a symbol for 'capture forbidden' (the !), that can be used to outlaw captures of one specific type by another. A symbol ^ in the location of AxB could mean that A is not allowed to hop over B, and a 0 that it can neither hop over nor capture B. A ban on hopping could also be applied to locust capture.
Of course the capture matrix for a game like Suzumu Shogi would be horrendously large. But most rows could be left empty, as most pieces neither hop nor locust-capture, and there are no bans on normal captures.
As to freezing: a much faster way to do implement that is to have NewMakeMove() and UnMake() keep track of the Tetrarch locations (which I understand are the only freezers). This could for instance be done by having arrays next[] and prev[] indexed by square numbers, that link all Tetrarchs of the same color in a doubly-linked list that is also accessible by square number. To remove a Tetrarch on square sqr from the list (because it moves away or is captured) you would just do
Most moves would not move or capture a Tetrarch, so the overhead is limited to testing if they did. But it would allow you to quickly loop through the Tetrarch locations by following the next[] links starting at next[-1] (and the other color would use next[-2]). Most of the game the list would be empty anyway (i.e. next[-1] = -1). You could do that at the start of move generation, and when you find a Tetrarch, replace every adjacent enemy piece by a dummy without moves to freeze them. You would of course have to undo that immediately after move generation.
[Edit] I now implemented piece-type-selective exclusion of hopping through the capture matrix, using ^ (for outlawing hopping for that piece combination) and $ (outlawing both hopping and capture, like for the Cannon in Janggi). This can also be done independently for friendly and enemy pieces.
I am wondering whether I should make hop-restrictions a standard feature of the Interactive Diagram. This could for instance be done through the captureMatrix parameter. That already has a symbol for 'capture forbidden' (the !), that can be used to outlaw captures of one specific type by another. A symbol ^ in the location of AxB could mean that A is not allowed to hop over B, and a 0 that it can neither hop over nor capture B. A ban on hopping could also be applied to locust capture.
Of course the capture matrix for a game like Suzumu Shogi would be horrendously large. But most rows could be left empty, as most pieces neither hop nor locust-capture, and there are no bans on normal captures.
As to freezing: a much faster way to do implement that is to have NewMakeMove() and UnMake() keep track of the Tetrarch locations (which I understand are the only freezers). This could for instance be done by having arrays next[] and prev[] indexed by square numbers, that link all Tetrarchs of the same color in a doubly-linked list that is also accessible by square number. To remove a Tetrarch on square sqr from the list (because it moves away or is captured) you would just do
To place a Tetrarch (because you moved it there or promoted to one) you would do
Most moves would not move or capture a Tetrarch, so the overhead is limited to testing if they did. But it would allow you to quickly loop through the Tetrarch locations by following the next[] links starting at next[-1] (and the other color would use next[-2]). Most of the game the list would be empty anyway (i.e. next[-1] = -1). You could do that at the start of move generation, and when you find a Tetrarch, replace every adjacent enemy piece by a dummy without moves to freeze them. You would of course have to undo that immediately after move generation.
[Edit] I now implemented piece-type-selective exclusion of hopping through the capture matrix, using ^ (for outlawing hopping for that piece combination) and $ (outlawing both hopping and capture, like for the Cannon in Janggi). This can also be done independently for friendly and enemy pieces.