picoEngine: Fixing FEN + Moves!


Today I was able to finally put the nail in the coffin of the FEN + Moves bug in picoEngine! It felt great to close that long standing issue. You can even check out the commit for all the details, but as usual, I’ll talk about the pertinent part here.

The reason this is important is because many chess programs allow you to set up a position on the board, and then seek the engine’s advice on a next best move. Initially, while meeting the UCI (Universal Chess Interface) standard, I enabled picoEngine to accept either “movepos” ( a move by move insertion from the program to my chess engine ), or “FEN” ( a string of numbers and letters that represents the current board ). What I didn’t realize is that some chess programs did not do what I expected per the UCI guidelines.

The way I understood it by reading the UCI guidelines, was that the controlling chess program (say Arena, in our case) would choose before hand to either send “movepos” with a list of moves to get the board set up, or it would send “FEN” with a string of the board setup for each move. I understood that if you set up the board in an unusual position, it would need to send FEN commands to my engine. That made sense.

What I thought would happen for further moves, however, did not. I thought, since it started as a FEN command game, then every turn, it would send the FEN string of the new board. Some chess programs do this. In the case of many programs, such as Arena, it did something quite unexpected to me. For further moves, it would send the FEN to set the board, then a string of the moves after that setup. So it was doing both movepos and FEN all at the same time!

Knowing that now was an easy fix. Simply read the FEN to get the current position, and if you have follow on moves, then apply the movepos rules on them. What gave me the biggest hiccup, however, was a slight miscalculation on my part. I was feeding the FEN into the engine in such a way that the board came out mirrored! Here was the code I used to fix it:

From this:

	int j = stringBoard.length();	
        for (int i = 0; i < j; i++) {
	if (i < 64){ m_theBoard[63 - i] = stringBoard.at(i); }

To this:


        for (int i = 0; i < 8; i++) {
		m_theBoard[i+0] = stringBoard.at(i+56);
		m_theBoard[i+8] = stringBoard.at(i+48);
		m_theBoard[i+16] = stringBoard.at(i+40);
		m_theBoard[i+24] = stringBoard.at(i+32);
		m_theBoard[i+32] = stringBoard.at(i+24);
		m_theBoard[i+40] = stringBoard.at(i+16);
		m_theBoard[i+48] = stringBoard.at(i+8);
		m_theBoard[i+56] = stringBoard.at(i+0);

The picoEngine is really coming along nicely! I think it is playable now, and I’m just about done working on it. It’s still not very bright yet, but it is getting better!

Linux – keep it simple.

Are you mobile, picoEngine?


With so many of my posts being about mobile phones, this title might seem misleading. However, I am not implying that picoEngine is on a mobile phone, but rather that I have added the ability for it to determine the mobility of the pieces on the board.

So far, picoEngine is off to a good start, since it now believes that the best first move you can make is that of e4, or the kings pawn to the fourth rank. This is great because it is taking into account the fact that such a move would allow it to be more active with it’s pieces. With one move it adds multiple options to it’s repertoire of available moves for the next turn. Here’s a look at the code:

	// Mobility evaluation
	string listMoves ="";
	int deltaChange = 0;
	try {
	listMoves = moveEvaluations.available(thatBoard, true, false, false);
		if (listMoves.size() == 0){
			deltaChange -= 10000; } else {
			deltaChange = deltaChange + listMoves.size()/5;
	listMoves = moveEvaluations.available(thatBoard, false, false, false);
		if (listMoves.size() == 0){
			deltaChange += 10000; } else {
			deltaChange = deltaChange - listMoves.size()/5;
	} catch (...) {
			cout << " Exception " << endl;
			} // End try/catch block
			//cout << deltaChange << " Delta " << endl;
	picoEval += deltaChange;

Pretty straight forward. Essentially, it checks both sides to see how many legal moves they are able to make, and adds a point for each white move, and minuses a point for each black move, creating a mobility delta. This delta, positive or negative, is added to the picoEval variable for final consideration. You can always check out the full commit if you’d like.

I wrapped it in a try/catch block to be safe, but I don’t think that I actually need it in this case. I may remove that later. The best part about this is the null move return. E.g., if no moves are returned, then the opponent must be in stalemate or check mate. This is highly desirable, and hopefully will allow picoEngine to choose moves that lead to a win. We’ll have to play it out and see.

Linux – keep it simple.