Check out Balbo's Chess, our featured variant for October, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Single Comment

Interactive diagrams. (Updated!) Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]
💡📝H. G. Muller wrote on Sat, Jan 21, 2023 04:26 PM UTC in reply to A. M. DeWitt from 03:20 PM:

The NewClick entry system is based on the AI: it uses the move generator of the latter to create a list of moves, and then after each click eliminates the moves that do not correspond to the clicks received so far, until only a single move is left. So getting it done in the AI's move generator is all that is needed. But indeed this does not use the 'clicks' array, as during thinking no one is clicking.

The AI's move generator uses a routine StackMove() to add a move to the list, and this calls BadZone() to vet the move for user-supplied restrictions on the Betza notation. This StackMove() gets the origin and destination squares passed as arguments, but not the locust squares. These are 'passed' as global variables: 'kills' indicates how many locust squares there are, and arrays killX[i] and killY[i], 0 <= i < kills contain the coordinates of these squares. For backward compatibility killX[0] and killY[0] are passed to BadZone(), but not any additional locust squares.

BadZone() can access these global variables just as easily as StackMove() does it, so you could base your move vetting on those.

A complication is that e.p. squares are also passed in the kill array (a variable 'eps' indicates how many of the kills are e.p. squares). But I guess that you won't have any e.p. capture in Shogi variants, so you won't have to deal with that.