📝Greg Strong wrote on Sat, Dec 23, 2017 05:18 AM UTC:
What happened to Quaddrox? Did you integrate that in the new ChessV?
No, Quadrox is sadly sitting untouched. Would like to return to it some day. Quadrox is basically the polar opposite of ChessV. It's C++ with careful consideration on how to make it as computationally efficient as possible, but can only potentially play a very limited number of variants. ChessV is C#, inefficient as hell, and designed for almost maximum universality. (I did make some limitations so the inefficiency wouldn't be totally insane.)
A lot depends on your motivation for doing this at all: whether it is just the pleasure of doing it and the satisfaction of having created something wonderful all by yourself, or whether the main drive is to advance the state of the art of computer chess-variant programming as much as possible. In the latter case it makes sense to cooperate and standardize more. E.g. there seems little reason to develop a new opening-book format; Polyglot books, also used by WinBoard for all variants it supports, are an open format, and being
able to interchange books seems a useful feature from the user perspective.
My motivation is definitely the latter. I have no desire to re-invent the wheel, and want to standardize as much as possible, so long as such standards aren't too limiting. I will look into Polyglot books. I have some ideas about how to generate openings books. During generation, (automated and/or human writing), the books will exist in a text format that is easy for people to read and edit. But I envision them being "compiled" into a binary computer-friendly format that will probably be Polyglot format.
For scripting user-defined variants a commonly accepted move notation, such as Betza's, seems a good way to do it. It is still on my to-do list to change the game-definitions of Fairy-Max to a more user-friendly format; perhaps we should cooperate on developing such a format. Sjaak II seems to do this pretty well, btw.
This is something we're probably not going to agree on, but I could be wrong. What you're considering probably fits into what I would consider "too limiting." Simple table-driven engines aren't sufficiently universal. You are probably not going to be able to play Chess-and-a-Half, for example, or Odin's Rune, without implementing a full-on scripting language (which is what I have although it's certainly incomplete in its present state.) SjaakII format is flexible and nice, although some of the games SjaakII plays are "internal" and not derived from the configuration file because it is not flexible enough (for example, Omega Chess.) That said, I'm happy to support multiple approaches so users can use a clean format that doesn't require any understanding of programming for those games it can handle.
EGT generation could be cast in the form of an engine that can be shared between GUIs just like search engines can.
EGT is pretty far down my list, honestly. If we can have a standard format I'd love to support reading that database format. But, truthfully, I'm probably not going to get to writing the actual generator any time soon, if ever. What does interest me enough that I might start attacking it, though, is developing custom evaluation functions that allow it to play specific endgames better regardless of board size - KPK, KPKP, KRK, that sort of thing. There are so many chess programmers out there that understand this stuff and could help out. It's too bad almost none of them care about what we're doing :)
Implementing tournaments was surprisingly easy in WinBoard, if you already have the infra-structure for loading engines. It took me only about a week.
Indeed, this should be fairly easy for me too, so it will probably be implemented before too long.
No, Quadrox is sadly sitting untouched. Would like to return to it some day. Quadrox is basically the polar opposite of ChessV. It's C++ with careful consideration on how to make it as computationally efficient as possible, but can only potentially play a very limited number of variants. ChessV is C#, inefficient as hell, and designed for almost maximum universality. (I did make some limitations so the inefficiency wouldn't be totally insane.)
My motivation is definitely the latter. I have no desire to re-invent the wheel, and want to standardize as much as possible, so long as such standards aren't too limiting. I will look into Polyglot books. I have some ideas about how to generate openings books. During generation, (automated and/or human writing), the books will exist in a text format that is easy for people to read and edit. But I envision them being "compiled" into a binary computer-friendly format that will probably be Polyglot format.
This is something we're probably not going to agree on, but I could be wrong. What you're considering probably fits into what I would consider "too limiting." Simple table-driven engines aren't sufficiently universal. You are probably not going to be able to play Chess-and-a-Half, for example, or Odin's Rune, without implementing a full-on scripting language (which is what I have although it's certainly incomplete in its present state.) SjaakII format is flexible and nice, although some of the games SjaakII plays are "internal" and not derived from the configuration file because it is not flexible enough (for example, Omega Chess.) That said, I'm happy to support multiple approaches so users can use a clean format that doesn't require any understanding of programming for those games it can handle.
EGT is pretty far down my list, honestly. If we can have a standard format I'd love to support reading that database format. But, truthfully, I'm probably not going to get to writing the actual generator any time soon, if ever. What does interest me enough that I might start attacking it, though, is developing custom evaluation functions that allow it to play specific endgames better regardless of board size - KPK, KPKP, KRK, that sort of thing. There are so many chess programmers out there that understand this stuff and could help out. It's too bad almost none of them care about what we're doing :)
Indeed, this should be fairly easy for me too, so it will probably be implemented before too long.
Cheers!
Greg