-
Notifications
You must be signed in to change notification settings - Fork 0
02 Engines
During the development of Chessly I researched a lot of different chess implementations - mainly Java based. Many of them use external UIs like XBoard, WinBoard, UCI, etc. (see Protocols).
Looking at these I did not like that they actually take over tasks from the engine to make sure the engine does not need to understand any context and to simply get the next move by sending all relevant information to the engine when asking for the next move. E.g. time used, time remaining, board, which color, etc. Also this makes it necessary for the engine to implement a complex protocol to support the UI which adds a lot of code not essential for the engine. E.g the engine needs to send statistical data to the UI regularly (node per second, PV, etc.) instead of being observed by the UI
The engines in Chessly are aware that there is a Player and a Game and therefore can query certain information from them. E.g. time used, total time, game over, game stopped (during calculation), etc. But Chessly engines do not need to send anything to the UI as the UI watches the engine if it chooses to do so. This is much cleaner in regards to MVC.
See also [Chess GUI Issues](http://chessprogramming.wikispaces.com/GUI#Chess GUI Issues)
I might refactor this in the future - at least I could make the engine unaware of the Player and Game by accepting all necessary data via the getNextMove Call. Also I could then implement an EngineWatcher who would actually send infos via protocol to above mentioned UI. I would still not want the engine to contain code to send info to the UI. And even less I want the UI to represent part of the model or even decisions which should belong to the engine.
I have implemented a complete object oriented chess engine when implementing the Game module. Using this object-oriented code for the engines proved to be way too slow. Especially object creation during the recursive minimax search takes its toll.
My research has shown me a very nice idea to not use objects but pseudo objects basically using integers for representing objects like fields, pieces, moves, etc.
I especially liked the approach Phokham Nonava uses in his Pulse and Flux Java chess engines. I therefore initially used his Pulse Engine code to implement an engine for Chessly. I have adapted it to the Chessly model and also enhanced it with various features - some from his Flux engine some from other sources and some from myself. Later I have discarded this approach and wrote an new engine on my own still heavily borrowing from Phokham's ideas. See below under Omega Engine.
Pulse and Flux from Phokham Nonava
Uses the Game move generator and always selects the first move in the generated move list. This is the most minimalistic Chessly engine.
public class AdamEngine implements Engine {
@Override
public void init(Player player) {
// empty
}
@Override
public GameMove getNextMove(GameBoard board) {
return board.generateMoves().get(0);
}
@Override
public void setGame(Game game) {
// we don't need a game
}
@Override
public void setNumberOfThreads(int n) {
// empty
}
@Override
public void getVerboseInfo(String info) {
// empty
}
}
Uses the Game move generator and selects a random move from the generated move list. This is a very minimalistic Chessly engine.
@Override
public GameMove getNextMove(GameBoard board) {
List<GameMove> moves = board.generateMoves();
if (!moves.isEmpty()) {
int move = (int) Math.round((moves.size() - 1) * Math.random());
return moves.get(move);
}
return null;
}
This was an engine using the Game code for move generation and a negamax recursive search. It worked well but was way to slow for the reasons mentioned above. I did not bother to maintain it further as it simply was no fun :)
TO BE UPDATED