💡📝H. G. Muller wrote on Thu, Jul 16, 2020 02:53 PM UTC:
OK, let me stress that I hardly know anything about GAME code. But I read somewhere that it is a Turing-complete programming language. I don't doubt that Betza notation is very far from GAME code, but it is also very far from JavaScript. And it wasn't all that hard to write a move generator driven by Betza notation in JavaScript. The Diagram script first compiles the Betza string into lists of 'move legs', where each leg can be either a leap or a slide in an absolutely specified direction, and specifies what must be at the square it ends on (friend / foe / empty). These lists are then interpreted at 'run time', i.e. when the Diagram needs to highlight squares, or the AI needs to generate a list of pseudo-legal moves for a given position. So my first thought would be to translate that move list to GAME code, plus a universal GAME-code routine that interprets the list in the context of a given position, just as the JavaScript routine does for the Diagram.
For the purpose of making a server the only tasks would be to determine whether an input move is pseudo-legal in a given position, and whether the royal is capturable in a given position. Both could be done by having it return TRUE as soon as it stumbles on a move that fits the description (i.e. matches a given destination, and in the case of an input move, also a given origin (and perhaps promotion choice or additional info, such as locust squares), which is (partly) guaranteed by only generating the moves for the piece at the origin, if an origin is given.
OK, let me stress that I hardly know anything about GAME code. But I read somewhere that it is a Turing-complete programming language. I don't doubt that Betza notation is very far from GAME code, but it is also very far from JavaScript. And it wasn't all that hard to write a move generator driven by Betza notation in JavaScript. The Diagram script first compiles the Betza string into lists of 'move legs', where each leg can be either a leap or a slide in an absolutely specified direction, and specifies what must be at the square it ends on (friend / foe / empty). These lists are then interpreted at 'run time', i.e. when the Diagram needs to highlight squares, or the AI needs to generate a list of pseudo-legal moves for a given position. So my first thought would be to translate that move list to GAME code, plus a universal GAME-code routine that interprets the list in the context of a given position, just as the JavaScript routine does for the Diagram.
For the purpose of making a server the only tasks would be to determine whether an input move is pseudo-legal in a given position, and whether the royal is capturable in a given position. Both could be done by having it return TRUE as soon as it stumbles on a move that fits the description (i.e. matches a given destination, and in the case of an input move, also a given origin (and perhaps promotion choice or additional info, such as locust squares), which is (partly) guaranteed by only generating the moves for the piece at the origin, if an origin is given.