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

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.

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 :

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);

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);
   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...

UCI protocol - Analysing a given FEN position via command line
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.