Are you listening to yourself, picoEngine?


Last post I was really excited about granting picoEngine permission to make multi-ply moves. However, I came to realize that while it was considering the end result of multiple ply moves, it was still only making the current move based on a single ply decision.

So, in layman’s terms: It would sacrifice a queen for a pawn because of the immediate gain, even though it knows the queen is toast next turn.

Obviously, that’s not going to make a very good chess engine. Not only that, but resources are wasted calculating moves that have no bearing on the current decision. So, I reworked the multi-ply decision tree in my latest commit. Unfortunately, it is currently stuck at a ply of 2 while I sort this out. You are welcome to take a look at the commit while I continue to work on it.

For now, though, it considers the moves this turn, and the opponents move next turn, and then decides on the best coarse of action. However limited that may be.

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.

Multi-ply picoEngine!


Hopefully, the above gif loaded for you. It’s not much to look at, but it is really neat to see the output and evaluation from picoEngine as it calculates through multiple moves before making a decision. At present, it is set to 3 ply, which means, if I play as white, then after making my move, picoEngine will calculate it’s move as black, my potential white move, and then it’s next move as black, or vise versa if we were to change sides.

The commit is not the largest one I’ve ever done, but certainly among the most thought intensive. Again, my goal with the picoEngine is just as the name implies: a small engine. Right now, the executable engine is only 335 kb, and while being loaded in Arena Chess, takes less than 2 MB to run. However, these stats don’t make or break a good engine, they are just in keeping with my lightweight goal.

So far, the only item considered by the engine to weigh in a decision is material. Now I need to work on two main things: pruning and/or a better evaluation system. As it stands, picoEngine is so material driven that it often falls prey to weak tactics, allowing picoEngine to capture something now, only to loose it later or be check mated, etc….

The largest problem right now is that picoEngine doesn’t actually know how to win. It is driven currently to attempt to whittle down the opponent to have no material left, but it doesn’t understand that it really needs to focus on check mates. I am thinking I can kill two birds with one stone though, if I add more evaluation for “mobility” (the ability to move about the board), with zero mobility of the enemy being desirable. This may lead to a stalemate engine though, so I will have to be careful.

Linux – keep it simple.

Single Ply Decisions from picoEngine!


While this may not seem like a real feat to many, I’m actually really excited about this. For the first time, picoEngine actually made an “informed decision” of what move to make. Granted, it is still making poor decisions, but they are at least no longer random.

Keeping in mind that the only evaluation criteria that I have given the engine is that of material difference, so currently, picoEngine is a hungry hungry hippo, because all it can do is attack any piece that comes within range. The downside to this is it will capture a pawn with it’s queen only to have you take back the queen with the defending pawn. So it is not a very bright engine, yet.

If I want to push it to the next level, there are several things I need to do. Currently, it is only searching 1 ply deep, meaning it checks each available move, and then picks the one move that gains the most points after it’s turn. In an ideal computer setup, you would want it to search multiple ply, as in what will it’s turn yield, and what will the evaluation read after the opponents turn. E.g., will they recapture the queen that you marched down there and stole their pawn with?

The commit is actually in two parts, and you are welcome to check them both out on my GitLab. One of the cool things about the current setup, is it does display the information in standard out, so you can actually see the decision being made first hand. The evaluation looks like this:

2019-02-19 13:40:13.611<–1:Move eval: f6g8 eval -10 places RNBQKBNRPPP–PPP———–Pn——————-pppppppprnbqkb-r
2019-02-19 13:40:13.611<–1:Move eval: f6e4 eval 0 places RNBQKBNRPPP–PPP———–PP—p————n—ppppppprnbqkb-r

Still needs some work, but definitely a step in the right direction!

Linux – keep it simple.

TWRP on the Urbane!

One of the side projects I have been working on is playing around with my new to me smart watch, an LG Urbane (W150). Among the different projects, I built TWRP for it. It had already been built before, but I like to build my own as well. You can download it here if you want:

One of the little highlights I did to make it more fun was to add a custom slider to the build. Now when you unlock or use the slider, you will see my icon on the slider!


Your welcome to use it if you like. Or you can head over to the TWRP homepage and download the official versions.

Linux – keep it simple.

What’s your evaluation, picoEngine?


While certainly nothing fancy, I have added a quick material evaluation to picoEngine. Up till now, I’ve been using picoEngine with random moves on. It is an option that by default is off, but the end user can choose to play against the engine in random move mode, where the next move is chosen at random. By default it will now play in “Normal” mode, which tries to make an educated decision.

Of course, the engine does not have a brain, or any essence of being, and thus cannot really “choose” a move. Thus, by educated decision, I really mean a weighted decision. The simplest of all weights is that of material advantage. In this case, I’m using “deca-pawns”, where each pawn is worth 10 points, the nights 30, the bishops 30, the rook 50, the queen 100, and the king 1000 points, respectively.

I don’t intend for this to be the final say in making the decision for picoEngine. At this time, though, I’m really in a position to work out the details of making a decisive move, but to be able to “choose” the best move, it needs some criteria to choose from. Thus, I put in the smallest and simplest criteria I could think of so I could work on the real part of determining how picoEngine will cycle through the available moves in order to pick one to play.

Other good methods of evaluating the board are:

  • Space – how much area you control.
  • Development – leading or lacking thereof.
  • Mobility – the freedom of movement that your pieces enjoy verses your opponent.
  • Aggression – the ability to attack your opponent.
  • Defense – things like the status of castling, or if your pieces are defended from loss.

And of course, materialism, which is the simplest to implement, as it is basically a count of remaining pieces. The problem with materialism as a goal is that such a machine can be easily tricked with things like a queen sacrifice, but it is a start!

Linux – keep it simple.

Would you like to en passant, picoEngine?

After hours of toil and pain, I realized that I was going about this all wrong, and then in 15 minutes enabled the ability for picoEngine to choose to en passant. It is amazing how far off track I was, and how quickly it could be fixed when I was on the right path.


I was attempting to call a private product of the “Board” class, when I needed to simply make it a public class method that could be called. It’s a bit lengthy, but you can always take a look at my GitLab for the full commit. Here is the important snippet:

if (isPass){
if (i > 23 && i < 32) {
int passedPawn = 8;
if (enPass == ‘a’){ passedPawn = 0; }
else if (enPass == ‘b’){ passedPawn = 1; }
else if (enPass == ‘c’){ passedPawn = 2; }
else if (enPass == ‘d’){ passedPawn = 3; }
else if (enPass == ‘e’){ passedPawn = 4; }
else if (enPass == ‘f’){ passedPawn = 5; }
else if (enPass == ‘g’){ passedPawn = 6; }
else if (enPass == ‘h’){ passedPawn = 7; }
if (passedPawn – colNum == 1) {
if (colNum – passedPawn == 1) {
}}// End en passant moves

The best part is that picoEngine can now suggest an en passant move, which is an important part of the game of chess.

Linux – keep it simple.

picoEngine, in passing?

One of the key things that any chess engine needs to be able to do, is take the input from the calling program with regards to en passant. With a little algebra, it wasn’t too hard to set up:


Fortunately, it was pretty easy to add the ability for the engine to check if the move was an en passant move, but it relied on two parts, both of which you can check out in the commit on my GitLab.

The first part was to make a flag that en passant was enabled, because the enemy pawn moved two squares. The second part was to calculate if the conditions were met on the next move to be an en passant move or not. If so, it then needed to adjust it’s own board and remove the “extra” pawn that was left behind!

Sounds simple enough! Guess you’ll have to be the judge of that by looking at the commit though.

Linux – keep it simple.

To castle, or not to castle, that is the question, picoEngine….


As you can see from the above screenshot, one of the engines possible moves is e8g8, which is for the black king to castle on the king’s side. This is great news. Previously, I had given the engine the ability to accept the input for castling, but it could not choose to do so on it’s own. But not anymore! Now it can decide to castle if it thinks that is the best thing to do!

Of course, you can read through the entire commit on my GitLab, but here is the focal point:

if (theBoard[60] == ‘k’) {
cout << “The king is on square 60” << endl;
if (theBoard[59] == ‘-‘ && theBoard[58] == ‘-‘ &&
theBoard[57] == ‘-‘ && theBoard[56] == ‘r’ && m_qcastle == true) {
cout << “Path is clear to castle queenside.” << endl;
if (isKingSafe(theBoard, turn)) {
//The king is not in check, so…
theBoard[59] = ‘k’;
theBoard[60] = ‘-‘;
if (isKingSafe(theBoard, turn)) {
//The king is safe in between, so…
//Then the move will get checked if king is safe at destination.
theBoard[60] = ‘k’;
theBoard[59] = ‘-‘;}
} //queenside

This portion covers the black king’s queen’s side castle options. It is more or less a convoluted set of if/then statements. If the king is on the normal king starting square, and the “hallway” is empty between it and the rook, and the rook and king have never moved (m_qcastle == true) THEN check if the king is in check, and if he will be safe every step of the way. If he is safe, then suggest that as a move to consider.

While it is not the cleanest code, and will cause problems for “non-classical” variants of chess, such as chess960, this gets the job done for traditional chess use.

Linux – keep it simple.

Castle, picoEngine?


After about an hour of accomplishing nothing, I finally gave up on what I was doing and fixed the UCI input for “movpos” when castling. So now, if given the move for castling, it moves the rook as well as the king!

You can check out the whole commit on my GitLab, but here is the only important part:

if (m_theBoard[first] == ‘k’ || m_theBoard[first] == ‘K’){
cout << “King Move” << endl;
if (first == 4 && second == 6) {
// White Castles King Side
m_theBoard[7] = ‘-‘;
m_theBoard[5] = ‘R’;cout << “castleWKS” << endl;
} else if (first == 4 && second == 2) {
// White Castles Queen Side
m_theBoard[0] = ‘-‘;
m_theBoard[3] = ‘R’;cout << “castleWQS” << endl;
} else if (first == 60 && second == 62) {
// Black Castles King Side
m_theBoard[63] = ‘-‘;
m_theBoard[61] = ‘r’;cout << “castleBKS” << endl;
} else if (first == 60 && second == 58) {
// Black Castles Queen Side
m_theBoard[56] = ‘-‘;
m_theBoard[59] = ‘r’;cout << “castleBQS” << endl;
} // Not a king move…..

As you can see, I just have the engine check if the input move was a king (k for black king, K for white king, which is standard computer notation). If it was a king that moved, it checks to see if it is one of the four possible castle moves, and then, if it is, the engine moves the rook as well. Nothing fancy, but it gets the job done!

Linux – keep it simple.