This is not something that can be achieved in just a few weeks. But yes, I have been working on it. (Sadly interrupted by an emergency that we have to move the TalkChess server before the end of the month, because the current one will get off line then.) I have started a kind of blog on it on takchess.com, to report the progress, and occasionally receive feedback.
The plan is to write a compiled C program that, when started by the user, installs itself as a HTTP server, so that you can surve to it through the browser. The Interactive Diagram on a page you view on this server could then request moves from it, instead of using the JavaScript that is running in the browser. I have already tested out this setup, by using the MicroSoft model program for a TCP/IP server, and adding the code needed to serve ordinary files from the directory it was started in. The idea is to define one filename (say "engine") as special, and not treat it as a file, but as a command to run the engine code, and output a move.
I am still busy designing a sufficiently powerful engine. I could have just translated the existing JavaScript code to C, counting on the larger speed, but the JavaScript AI has many design characteristics that would also slow down a C program. For that reason, as well as to make the project interesting, I wanted to try a completely different design:
Every piece would get all its potential moves tabulated. That is, every leg of a move would get the squares it visits (indicated relative to the piece) put in a table when the variant is initialized, with the maximum length it could have on a board of the given size. (So on 8x8 a Rook would get 4 moves, each consisting of 7 squares.) During play these tabulated moves will get associated with a board square, depending on where the piece stands, or, for a continuation leg, on where that leg starts.
This data structure takes the place of a conventional move list; retrieving captures from it will be done via the square they are associated with. This way you only have to change the moves of the pieces that were involved in a move (re-associating or deleting their moves, and those of pieces that were discovered / blocked), while most pieces will keep the same moves. That becomes particularly advantageous in large variants.
This is not something that can be achieved in just a few weeks. But yes, I have been working on it. (Sadly interrupted by an emergency that we have to move the TalkChess server before the end of the month, because the current one will get off line then.) I have started a kind of blog on it on takchess.com, to report the progress, and occasionally receive feedback.
The plan is to write a compiled C program that, when started by the user, installs itself as a HTTP server, so that you can surve to it through the browser. The Interactive Diagram on a page you view on this server could then request moves from it, instead of using the JavaScript that is running in the browser. I have already tested out this setup, by using the MicroSoft model program for a TCP/IP server, and adding the code needed to serve ordinary files from the directory it was started in. The idea is to define one filename (say "engine") as special, and not treat it as a file, but as a command to run the engine code, and output a move.
I am still busy designing a sufficiently powerful engine. I could have just translated the existing JavaScript code to C, counting on the larger speed, but the JavaScript AI has many design characteristics that would also slow down a C program. For that reason, as well as to make the project interesting, I wanted to try a completely different design:
Every piece would get all its potential moves tabulated. That is, every leg of a move would get the squares it visits (indicated relative to the piece) put in a table when the variant is initialized, with the maximum length it could have on a board of the given size. (So on 8x8 a Rook would get 4 moves, each consisting of 7 squares.) During play these tabulated moves will get associated with a board square, depending on where the piece stands, or, for a continuation leg, on where that leg starts.
This data structure takes the place of a conventional move list; retrieving captures from it will be done via the square they are associated with. This way you only have to change the moves of the pieces that were involved in a move (re-associating or deleting their moves, and those of pieces that were discovered / blocked), while most pieces will keep the same moves. That becomes particularly advantageous in large variants.