Each chess program needs same things like move generator,bitboards.
Can we create classes like class Move generator. So other programmers can use this class to create Move generator for their engine , without writing it from the scratch.
Creating classes in c++ for chess program
Moderators: hgm, Rebel, chrisw
-
Bill Rogers
- Posts: 3562
- Joined: Thu Mar 09, 2006 3:54 am
- Location: San Jose, California
Re: Creating classes in c++ for chess program
All that information is already for those who want to do a little research. You need to do more studying on your own. A great many programmers have made the source code to their engines freely available to the public.
How old are you? So many of your posting sould like a very young man with little or no experience in programming or chess in general.
Bill
How old are you? So many of your posting sould like a very young man with little or no experience in programming or chess in general.
Bill
-
nczempin
Re: Creating classes in c++ for chess program
There are some features of a chess engine that are the same for all programs, regardless of strength.
The move generator and board representation are not amongst those that make a lot of sense to be shared (in the form of a library, say), because those, as well as a few others such as evaluation function, are the most important differentiators from one engine to the next.
And one of the reasons some people write chess engines is the competitive nature of it (even if it is only at the level of the ChessWar Promotion tournament
). So I think it's unlikely that these features will or should be shared from one engine to the next. There is at least one open source program where the main developer has recently asked for assistance, so it would be possible to contribute to that project just like for any other open-source program (the engine I'm talking about is Toga). So if you want to work on an engine without doing all the nitty-gritty detail work, you could ask to join such a project.
Another reason why board representation is not easily shared in the form you propose is that it is usually very tightly coupled to the whole engine logic. Just ask anyone who has changed his board representation from one to another; since nearly everything uses the board, you have to change nearly everything.
There are some features where it would make a lot of sense to factor out a library or a framework: All that UCI and WB support, plus a few other details. For those there's really no principal reason why every new engine coder has to develop these from scratch; there's no potential for differentiating there. There are still some ugly dependencies in most people's code, but in principle one could separate the "interface" code from the actual engine (even the "actual brain" can be partially separated from the "engine", as there are some features such as time control that are separate from the pure chess algorithm).
In fact, I'm working on providing exactly such a library from my engine Eden (there are already two separate libraries used, they are just not yet ready for public release). It will come in one of the next releases. My engine (and thus the library) is in Java. There's no reason why something similar could't be done for C++ or C.
The move generator and board representation are not amongst those that make a lot of sense to be shared (in the form of a library, say), because those, as well as a few others such as evaluation function, are the most important differentiators from one engine to the next.
And one of the reasons some people write chess engines is the competitive nature of it (even if it is only at the level of the ChessWar Promotion tournament
). So I think it's unlikely that these features will or should be shared from one engine to the next. There is at least one open source program where the main developer has recently asked for assistance, so it would be possible to contribute to that project just like for any other open-source program (the engine I'm talking about is Toga). So if you want to work on an engine without doing all the nitty-gritty detail work, you could ask to join such a project.Another reason why board representation is not easily shared in the form you propose is that it is usually very tightly coupled to the whole engine logic. Just ask anyone who has changed his board representation from one to another; since nearly everything uses the board, you have to change nearly everything.
There are some features where it would make a lot of sense to factor out a library or a framework: All that UCI and WB support, plus a few other details. For those there's really no principal reason why every new engine coder has to develop these from scratch; there's no potential for differentiating there. There are still some ugly dependencies in most people's code, but in principle one could separate the "interface" code from the actual engine (even the "actual brain" can be partially separated from the "engine", as there are some features such as time control that are separate from the pure chess algorithm).
In fact, I'm working on providing exactly such a library from my engine Eden (there are already two separate libraries used, they are just not yet ready for public release). It will come in one of the next releases. My engine (and thus the library) is in Java. There's no reason why something similar could't be done for C++ or C.
-
Gerd Isenberg
- Posts: 2250
- Joined: Wed Mar 08, 2006 8:47 pm
- Location: Hattingen, Germany
Re: Creating classes in c++ for chess program
Concrete general objects for board, moves and such stuff are hard to realize imho - considering performance, the variety of tastes and all kind of implementation nuances. For instance one may keep a stack of boards-objects, or a single instance (per thread) of the pure piece-positions, but a stack of move50 counter, castle/en-passant states and other stuff handy to restore the piece-positions after unmake.
There are zillions of possible move-struct/class designs. Most "classial" board designs (mailbox or bitboards+mailbox) require only the from- and to-coordinates plus some bits for special moves (castles, en-passant, promotions) - a 16-bit move structure might be sufficient. During make/unmake one has to lookup the board-array to determine what pieces are on the from- and to-squares. for updating board and hashkeys. In pure (quad-)bitboard approaches - with no mailbox board at all - it might be smarter to generate disjoint sets of moves with complete information about the moving piece and the eventually captured piece. Some also keep additional information inside the move-object, e.g. material gain and/or history scores for sorting, eventually ambiguous SAN-information and whether a move gives check etc..
Not to mention acquisition of information for all kind of stuff like evaluation - issues like possible side-effects between move-generation and evaluation, incremental updated attack-tables versus on the fly calculation and so on.
Gerd
There are zillions of possible move-struct/class designs. Most "classial" board designs (mailbox or bitboards+mailbox) require only the from- and to-coordinates plus some bits for special moves (castles, en-passant, promotions) - a 16-bit move structure might be sufficient. During make/unmake one has to lookup the board-array to determine what pieces are on the from- and to-squares. for updating board and hashkeys. In pure (quad-)bitboard approaches - with no mailbox board at all - it might be smarter to generate disjoint sets of moves with complete information about the moving piece and the eventually captured piece. Some also keep additional information inside the move-object, e.g. material gain and/or history scores for sorting, eventually ambiguous SAN-information and whether a move gives check etc..
Not to mention acquisition of information for all kind of stuff like evaluation - issues like possible side-effects between move-generation and evaluation, incremental updated attack-tables versus on the fly calculation and so on.
Gerd