The release of Nanook Chess v0.2 has been postponed due to professional reason until september or october.
I need to finish the attack board for a better position evaluation, and to implement rules to manage ending game before to be able to release this new version.
Nanook chess - UCI Engine
Nanook Chess is an UCI Engine developed by Julien Gonçalves.
Monday, July 18, 2011
Thursday, May 26, 2011
Nanook v0.2 will be released in June or July
I'm planning to release Nanook v0.2 in June or July: I implemented almost all the functionalities I wanted to add (I will describe them later), but I still have a lot of work on testing and to improve the board evaluation.
Even with a bad evaluation function, v0.2 won 100% of the 10 games they played against v0.17 (5 minutes/side for each game), so it seems to play much better. As soon as I will have an evaluation working correctly, I will test it against other chess engine, and try to estimate the elo gain since last version
Even with a bad evaluation function, v0.2 won 100% of the 10 games they played against v0.17 (5 minutes/side for each game), so it seems to play much better. As soon as I will have an evaluation working correctly, I will test it against other chess engine, and try to estimate the elo gain since last version
Monday, May 23, 2011
Nanook v0.2 : a first release soon of the C++ chess engine.
I finished a basic version of Nanook chess v0.2 (C++) using alpha-beta algorithm, quiescent search / zobrist keys, with a very basic evaluation function. I tested against last version of Nanook and the engine seems to be working well, very stable.
I was working for 1 week only with the code optimization (Board / Moves generator), and now this part of the code is much quicker than previous version v0.17 (reaching around 1.000.000 nps for now - should go slower with move ordering implementation), before to release a first version of this new engine developed from scratch, I need to implements the following points :
- Ordering moves (mixing killer/history/static)
- Evaluation function at least equal to the previous version
- managing opening/final positions
- time management
- Performing alpha-beta
I have some more ideas to do after adding they tasks, but I will implement it after a first release.
I was working for 1 week only with the code optimization (Board / Moves generator), and now this part of the code is much quicker than previous version v0.17 (reaching around 1.000.000 nps for now - should go slower with move ordering implementation), before to release a first version of this new engine developed from scratch, I need to implements the following points :
- Ordering moves (mixing killer/history/static)
- Evaluation function at least equal to the previous version
- managing opening/final positions
- time management
- Performing alpha-beta
I have some more ideas to do after adding they tasks, but I will implement it after a first release.
Friday, May 6, 2011
C++ thread: A strange problem sending stdout to the GUI
Today I implemented a new thread for analysis, so the main thread can continue to listen for input from GUI during the analysis, when the "stop" command is sent, I just have to update a flag m_StopAnalysis to true and the thread exit with the serach results, this is very helpful and easy to implement. Concretely, when the GUI send the "go" command, I just call LaunchThreadAnalysis(), defined like this in my code :
The pointer of the current class is sent as parameter to the function ThreadLauncher, Defined with the followed code :
Finally the function LaunchingAnalysis(), part of the same class is called, and it launch the Analysis. This call Alpha-Beta and write "info" and "bestmove" informations to the stdout in order to reply to the GUI, and then exit from the thread.
I tested with command line : it works perfectly. But when I tested with Arena, the Engine never replied until the GUI send "stop"... Very strange, in depth 4, the engine should find the result in less of 2 seconds, but it never reply, even after 1 minute. After 2 hours of investigation, I found the problem : the behavior of the stdout from the child process is different, it seems to bufferize the characters sent to the GUI...
If you have same problem, the solution is simple : after each stdout, use
void CProtocolUci::LaunchThreadAnalysis()
{
CProtocolUci *p = this;
HANDLE hProcessThread = CreateThread(NULL, 0,&CProtocolUci::ThreadLauncher, p,0,NULL);
if ( hProcessThread == NULL ){
MessageBoxA(NULL,"Thread error : "+GetLastError(),"Critical error",MB_OK | MB_ICONINFORMATION);
exit(0);
}
}
The pointer of the current class is sent as parameter to the function ThreadLauncher, Defined with the followed code :
static DWORD WINAPI ThreadLauncher(void *p)
{
CProtocolUci *GameAnalysis = reinterpret_cast(p);
GameAnalysis->LaunchingAnalysis();
return (0);
}
Finally the function LaunchingAnalysis(), part of the same class is called, and it launch the Analysis. This call Alpha-Beta and write "info" and "bestmove" informations to the stdout in order to reply to the GUI, and then exit from the thread.
I tested with command line : it works perfectly. But when I tested with Arena, the Engine never replied until the GUI send "stop"... Very strange, in depth 4, the engine should find the result in less of 2 seconds, but it never reply, even after 1 minute. After 2 hours of investigation, I found the problem : the behavior of the stdout from the child process is different, it seems to bufferize the characters sent to the GUI...
If you have same problem, the solution is simple : after each stdout, use
fflush(stdout);
! This should flush the stdout pipe and send your characters to the GUI.
Thursday, May 5, 2011
Nanook chess from scratch - First step : UCI protocol, move generator and alpha-beta
I want for this version of Nanook chess to avoid from the beginning all kind of moves bugs that we often detect too late. Beginning with a stable move generator and a well working alpha-beta algorithm is the best way to correctly progress forward.
So, first of all, I choose a 0x88 board representation : It's a little different from the one used in the previous version of Nanook, but it seems to me to be a better way. Then I developed the move generator, nothing complicated at this point : just need to make sure that special move as castling/en passant/promotion are well understood. An finally, I implemented a basic alpha-beta algorithm with a really simple evaluation function (counting score of captured pieces, no score for position).
Before to make a step forward, I need to make sure that all these points work perfectly, the best way to do it is to implement now the UCI protocol, in order to be able to test all kind of situation with fen positions.
UCI protocol implements a lot of commands, basically at this point it will be interesting to integrate the commands position/info/bestmove/etc... (options and timer can be done later), the most important is the possibility to load a fen position. Believe it or not, but previous version of Nanook was not able to load a fen position, I never implemented it ! Testing a position was possible only using startpos...
As soon as these commands are understood, the engine can reply with the best move, and some other informations... It should be interesting also to manage "go infinite" and "stop": when you will launch test analysis, the GUI might use these commands. The best way is probably to create a Thread where you launch your analysis, so you can continue to read input commands from GUI and wait for the "stop" signal.
Ok, so now Nanook Chess implements all these points, I just need to load and test some specific fen positions via UCI to make sure it didn't make an illegal move. I was thinking to do my own GUI engine with a list of fen positions and their expected moves, but it seems Arena give this possibility with the "engine analysis", you can load an EPD file (EPD is a format where you can find a list of fen positions and the move expected to be played for each of them), the engine will analyse these moves, and finally it will display which moves the engine success and fails. Great ! So the only thing I need to do is to create an EPD list with positions that Nanook should understand at this point of development (get a "free" piece, find a mate, escape a mate, test a pat, promotion, ...), and I will go forward only when it will success with 100%. This seems to be a very good way to proceed : for each step of the project, I will check again all EPD positions, and develop new ones, then Nanook should never have a worst score than the step before.
I'm now preparing an EPD list of fen (around 30 specific positions), I will probably test the engine today or tomorrow with it.
So, first of all, I choose a 0x88 board representation : It's a little different from the one used in the previous version of Nanook, but it seems to me to be a better way. Then I developed the move generator, nothing complicated at this point : just need to make sure that special move as castling/en passant/promotion are well understood. An finally, I implemented a basic alpha-beta algorithm with a really simple evaluation function (counting score of captured pieces, no score for position).
Before to make a step forward, I need to make sure that all these points work perfectly, the best way to do it is to implement now the UCI protocol, in order to be able to test all kind of situation with fen positions.
UCI protocol implements a lot of commands, basically at this point it will be interesting to integrate the commands position/info/bestmove/etc... (options and timer can be done later), the most important is the possibility to load a fen position. Believe it or not, but previous version of Nanook was not able to load a fen position, I never implemented it ! Testing a position was possible only using startpos...
As soon as these commands are understood, the engine can reply with the best move, and some other informations... It should be interesting also to manage "go infinite" and "stop": when you will launch test analysis, the GUI might use these commands. The best way is probably to create a Thread where you launch your analysis, so you can continue to read input commands from GUI and wait for the "stop" signal.
Ok, so now Nanook Chess implements all these points, I just need to load and test some specific fen positions via UCI to make sure it didn't make an illegal move. I was thinking to do my own GUI engine with a list of fen positions and their expected moves, but it seems Arena give this possibility with the "engine analysis", you can load an EPD file (EPD is a format where you can find a list of fen positions and the move expected to be played for each of them), the engine will analyse these moves, and finally it will display which moves the engine success and fails. Great ! So the only thing I need to do is to create an EPD list with positions that Nanook should understand at this point of development (get a "free" piece, find a mate, escape a mate, test a pat, promotion, ...), and I will go forward only when it will success with 100%. This seems to be a very good way to proceed : for each step of the project, I will check again all EPD positions, and develop new ones, then Nanook should never have a worst score than the step before.
I'm now preparing an EPD list of fen (around 30 specific positions), I will probably test the engine today or tomorrow with it.
Wednesday, April 27, 2011
History and Future of Nanook Chess : a new version from scratch in preparation
I think it's now time to improve Nanook chess with a real new version. The last release v0.17 is weak, I identified a lot of problems 2 years ago but I never corrected them, a lot of functionalities are not implemented, and I don't feel very well to let this project unfinished.
I started this project almost 8 years ago in C language, for a computer school project. The name of the project was "Epichess", and it has been developed to play chess through network, with client/server connections functionalities, 2D graphic, multiplayers/multi-engines for tournament, elo estimation, compatibility on Windows/Linux… I worked in this project during 2 months, the engine was weak, oriented for beginners.
4 years ago, I decided to extract the engine from Epichess project and make it compatible with UCI protocol, rewriting quickly just some pieces of code, with no improvement, Nanook v0.15 was born. V0.16 has been released in june 2007, with some improvements but nothing really new.
In may 2009, after 2 years of inactivity, I added some new functionalities, but it was more like a patch than a real new version, just to make it a little stronger.
Now, when I watch the C code source, I’m very surprised and I understand why Nanook Chess is so unstable… I patched this code for so long, I actually can see some error that I coded 8 years ago that are still there. The only way to have a new stable version is to develop this project from scratch, and that’s the decision I just caught: the next version of Nanook Chess will be developed in C++ from scratch. I expect from this version to be stronger than the 0.17, more stable and implementing the UCI protocol with all functionalities.
I started this project almost 8 years ago in C language, for a computer school project. The name of the project was "Epichess", and it has been developed to play chess through network, with client/server connections functionalities, 2D graphic, multiplayers/multi-engines for tournament, elo estimation, compatibility on Windows/Linux… I worked in this project during 2 months, the engine was weak, oriented for beginners.
4 years ago, I decided to extract the engine from Epichess project and make it compatible with UCI protocol, rewriting quickly just some pieces of code, with no improvement, Nanook v0.15 was born. V0.16 has been released in june 2007, with some improvements but nothing really new.
In may 2009, after 2 years of inactivity, I added some new functionalities, but it was more like a patch than a real new version, just to make it a little stronger.
Now, when I watch the C code source, I’m very surprised and I understand why Nanook Chess is so unstable… I patched this code for so long, I actually can see some error that I coded 8 years ago that are still there. The only way to have a new stable version is to develop this project from scratch, and that’s the decision I just caught: the next version of Nanook Chess will be developed in C++ from scratch. I expect from this version to be stronger than the 0.17, more stable and implementing the UCI protocol with all functionalities.
Thursday, April 21, 2011
Links to download "Nanook Chess" are updated
The server Host for the binaries v0.16 and v0.17 changed 1 month ago, and links to download them was not working anymore. I just updated the links with the news host, they are now available.
Subscribe to:
Posts (Atom)