Fool’s Mate Friday: Ubports (Ubuntu Touch) Chess, with a hint of Cinnamon.

As I dive into the realm of making my Just Chess Engine playable, I was taking a look at some of the other chess interfaces out there, to see what kind of features I should implement.

Recently, I decided to test drive Ubuntu Touch on my Oneplus One, and it was during that trial run that I tried out the chess program that they have in their OpenStore.  The app was called Chess, written by Andima Landaluze. You can check out the source code here:

Sometimes, when you open a chess app, you are overwhelmed with 3000+ options. You end up scrolling through dozens of menus, and in the end, you just wanted to play a quick game of chess. Don’t get me wrong, sometimes you need those extra options for critical thinking and deep play, but if you are playing on your cell phone, you probably just sat down on the bus for 15 minutes and decided to play a short match.

That is one of the things I like about this app. The simplicity of it. While I don’t think my app will look overall like this one, I feel I can draw from this app a little note from the simplicity. The app features the Cinnamon chess engine.

I also took a moment to look at the Chess Clock program by Michele Castellazzi. It has all the standard features of a chess clock, and worked flawlessly when I tested it out. Again, the interface was focused on simplicity, which made for a very appealing and smooth interface.

If there was anything to take specifically from the clock application, it would have to be the pause feature. Setting up my own interface for play, it might be nice to be able to pause the game, but further thought brought me to the idea of pausing the game if you press the home button as well. Perhaps that might be a handy feature, as well.

Linux – keep it simple.

Fool’s Mate Friday: Jin, FICS, and Correspondence Chess

Apparently, the earliest documented correspondence chess game was played between Henry I of England and Louis VI of France, but the earliest correspondence chess game in which all of the moves were recorded took place sometime in 1804 between F. W. de Mauvillion of Breda and an officer at a city of Holland, The Hague. According to Harry Golombek in his book ”Golombek’s Encyclopedia of Chess”.

Since then, we’ve moved to more modern methods of distance play, especially since the Internet. Now you can play on your computer, your cell phone, via email, or even telephone.

That brings us to Jin, but not rummy. That’s right, I’m talking about Jin, the chess interface. Here’s what the author of this great program says about it:

Jin is an open source, cross platform, graphical client for chess servers, written in Java. Jin can run either as a standalone application (available at this website) or as an applet, directly from your browser (available at the chess server’s website).

I’ve been using Jin for quite a while now on my Linux based machine. Among the many great things about Jin is that it is open source and cross platform. There is not enough of these kinds of good programs going around.

One of the best features, of course, is the ability to hook up to several chess servers, including FICS, the Free Internet Chess Server. I play there regularly myself. Of course, I am a big fan of free, so the price is right, but I also like the ability you have to message other players (somewhat like email), chat with your opponent during the game, keep a journal of your past games, and even email your played games to yourself. Perhaps later I can do an article specific to FICS and some of the great features there.

For now, you are probably wondering if this has anything to do with my Just Chess Engine. Well, I hope to one day have it playable on chess servers (although I doubt it would garner a great score), but it is not there yet. It is, however, available for others to drag and drop into their Android or Java applications to be used as a weak starter engine. No, I want to focus today on correspondence.

My next goal with my chess programming is to stick with Android for now, and in particular, cell phones. I’d like to build an android app that allows you to play other people who are not in the same room. I plan to venture into several different methods of communication, which will help me learn a lot about programming. In all of these methods, I hope to make a playable chess app as the objective.

My plan thus far is to make an app that starts with the option to play against the Just Chess engine, as a single player game. Then, I hope to move to a local, player verses player game, and for kicks, I’d like to progress to a game in which two players may play remotely, with the moves being sent via text, and the game app automatically importing those text moves into play.

From there, who knows? If the text games work well, I may branch out to how to have multiple games going at once, distinguished via some tag in the text messages. Or perhaps I’ll try my hand at a Bluetooth chess app. I’m not really sure. Either way, I have some work ahead of me, and hope you enjoy following along with my journey.

Linux – keep it simple.

Fool’s Mate Friday: Touching up the User Interface….


My uncle once told me that a good paint job will sell a bad airplane. He’s right. As an airplane mechanic, he knew the value of the planes that he worked on. At the same time, he saw customer after customer get “swindled” on a plane that looks nice on the outside.

The thing is, it’s true for apps and games as well. A really good program that doesn’t look good just isn’t as fun. Truth is, this engine app needed a little touch up in the gui department. So, while I didn’t make it pretty, I did add features to try to make it more useful.

Similar to the Beginning Chess Engine, I added a commit to allow the user to make a move by pressing the button. Simple stuff really, but up ’till now, I was doing all of my move making from the command line through the app code itself. Of course, if you can make a move, you need to be able to take it back to, so I added a commit to give the undo move method.

The flow of these move methods are pretty simple. For most moves, it checks the from space and the to space and puts an “*” (asterisk) at the from, and puts the piece that was there in the to space. The process is reversed for the undo move method.

There are a few exceptions, though, like the additional moves that are special, en passant, castle, and promotion. Those are handled by reading the input move first to see if it matches any of those scenarios, if not, then a regular move is performed.

Obviously, making moves in chess is a pretty important part of the game. The longest chess game theoretically possible is 5,949 moves, and that would be impossible to do if you couldn’t actually make any of those moves!

Linux – keep it simple.

Fool’s Mate Friday: Keeping the king safe!


The word “Checkmate” in Chess comes from the Persian phrase “Shah Mat,” which means “the King is dead.”

While in the starting position, there are eight different ways to checkmate in two moves and 355 different ways to checkmate in three moves. Not to mention the countless other ways to be checkmated. Kind of sounds like one of those television series of “1000 terrible ways to die.”

We’ve looked before at code for making the king move, but now we want to break down how we check if the king is safe. Here’s the kingSafe commit, and we can reference several things from that code as we try to understand what I set out to accomplish.

First, let’s take a look back at the flow chart for determining available moves:

  • For each piece, check for valid moves that they can make, where the spaces are empty, or where they attack an opponent’s piece.
  • Add that move to the temporary list.
  • Once we have a temporary list of valid moves, try each move, 1 at a time, and check if the king is safe.
  • If the king is safe, add that move to the “available moves” list.
  • Put the piece back, and try the other moves on the temporary list.

With that in mind, up until now, our engine has not actually checked if the king is safe. We had a isKingSafe() method that always returned true, or “yes, he is”. Now we need to flesh that out and have it really check if it is safe. For the most part, we can combine all the pieces move options into one for the king, and just ask what pieces are at the “end” of those move lines. Here’s the flow chart:

  • Start with the king’s space number, and get the row/column number as well.
  • Using the bishop’s move table, check the next diagonal space until it is not empty. If it is not empty, is it either a bishop or a queen? Then the king is not safe.
  • Using the rook’s move table, check the up/down/left/right spaces until they are not empty. If it is not empty, is it either a rook or a queen? Then the king is not safe.
  • Using the knight’s move table, check the eight “L” spaces to see if they are empty. If it is not empty, is it either a knight? Then the king is not safe.
  • Using the king’s move table, check the surrounding spaces until it is not empty. If it is not empty, is it a king? Or in two cases, a pawn? Then the king is not safe.
  • The king must be safe!

As you can see from the flow chart, it is checking to see if the king is “not safe”. At any juncture that the king is not safe, the rest of the checks are ignored, and a “false” boolean is returned from the isKingSafe0 method. If there are no returns of “false”, then the method returns “true”, for the king must be safe.

In my mind, there are three main ways to handle the king safe issue:

  1. After each piece is moved, have it flag that the king is unsafe (e.g., you check the king, so he is unsafe).
  2. After every move, check from all pieces to see if they are attacking the king.
  3. After every move, check from the king if he is threatened by any pieces.

Method one seems hard to implement, when moving you own piece may illegally threaten the king by no longer “blocking” an attacker. Conversely, method two is way more resource intensive. You would waste time checking both bishops in all directions to see if they “find” the king. Method three seems the most logical, check from the king in all directions for the enemy, rather than from all enemies for the king.

Of the method we chose, there seem to me to be two sub-methods, that of checking if the king is safe, or checking if the king is not. I like to assume the king is safe, unless we find that he is not. I think this is faster, because the moment we find he is not safe, then we quit checking. E.g., if the bishop check reveals the king is not safe, we don’t do the rook, king, knight, pawn checks, we just return “false” – not safe.

Conversely, if we were to assume the king is not safe, and prove he is, we would have to complete all of the checks every time. This would be a waste of resources. Although, with the method I chose, most of the time, the king is safe, so we end up checking them all anyways. But, since we are trying to use this engine on cell phones, we need to save on every resource that we can.

Linux – keep it simple.

Fool’s Mate Friday: Perilous times for pawns!


Did you know that the piece with the lowest survival rate is the white queen’s pawn at d2? That’s right, out of 2.2 million master level games, this pawn survives the least games at only 24.5%. Conversely, king not withstanding, the one piece with the highest survival rate of any of those games is the white king’s rook’s pawn at h2? It survives over 73% of games played! With such a wild spectrum, this small piece is actually the highest and lowest survivor of any chess game. You can check out all of the stats for piece survival here at Oliver’s blog.

Of special interest, Oliver also wrote a program to analyse all of the moves to find that information, which you can look at on GitHub.

Personally, I find the pawn to be the most important piece of the game. But that is for another time. For now, we need to make some pawn moves. Surprisingly, for such a simple piece, it has the most complicated moves:

  1. Pawns can move forward one space.
  2. Pawns can move forward two spaces from the “home” row.
  3. Pawns can attack diagonally forward.
  4. Pawns can perform en passant only under the right conditions.
  5. Pawns can promote to another piece.

I am sure that you realized those moves exist, but by seeing them put to paper we can really get the feel for how complicated making the pawn move is! Of all of those moves, 4 of the 5 are conditional, meaning they can only be done under certain conditions. This makes programming them tough, as you have to check if those conditions exist, then check if making the move is possible, then check if that move is safe for the king.

As you can see in my pawn commit, I added the pawn moves, but there are some flaws in them. Unfortunately, most of these flaws were not realized at the time, but were fixed later, here and here. Essentially, the move that was flawed is en passant, both in the making and the undoing of that move. However, I did not realize it at this point, until I started making the engine perform and undo moves.

So, take a look at the code, and feel free to comment if you think of a better way to do those moves.

Linux – keep it simple.

Fool’s Mate Friday: Keeping the King on the move!


When it comes to king moves, the most interesting is castling, for which I did manage to find a few statistics on the web, based on official games:

  1. White castles kings side 80.2% of the time.
  2. White castles queens side 8.8% of the time.
  3. White doesn’t castle at all…11% of the time.
  4. White castles queens side about twice as much as black.
  5. Castling kings side gives a higher statistic of draws.

From a tactical standpoint, they say that to castle opposite of your opponent creates a more tactical game, while to castle the same side as your opponent creates a positional game. Now I just need to go look up what that means….

In any event, we need to get a move on! Well, at least our king does. So, I created two commits: the king moves, and the king castle moves.

The king moves are really straight forward. I keep thinking that there must be an easier way to do this, but again, it’s just pure math. king position +/- 8 to go up/down a rank, +/- 1 to go side to side, and +/- 7 or +/- 9 to jog diagonally. The easy thing about the king is that he can only move one space… unless he castles.

Castling is rather tricky from a programming standpoint. There are several conditions which must be met:

  • The king cannot be in check.
  • No square the king moves to can be in check.
  • No square the king moves across can be in check.
  • There must be empty spaces between the king and the rook.
  • The king must never have moved.
  • The rook must never have moved.

As you can see, that maneuver alone takes 6 factors into account! Later, I ended up changing this a little bit, rather than booleans of true/false for king moved or rook moved, I went with numbers, but I’ll touch on that later. For now, I went with booleans.

The “king is safe” method has actually not been written yet, so it was interesting to check if the king is safe for this move, before having a way to check that, but in theory it works just fine, once I write the king is safe method. For now, I assign a number to the king’s position, and have it check if the king is safe by moving the number, rather than the actual king, on the logical board, and check if the king would be safe there.

It’s a little complicated, but I think it will do the trick. Be sure to check out the code!

Linux – keep it simple.

Fool’s Mate Friday: Quickly created Queens


Ah, the most powerful piece in the game. The queen. She can move in eight directions over great distances, she can outmaneuver any single piece on the board, she is used in more attacks and mates (statistically) than any other piece. Very valuable. So valuable, that she is worth 3 bishops, or 3 knights, or almost 2 rooks. In chess, that’s valuable.

However, my favorite queen story is that of sacrifice. A top notch player, Paul Morphy, once faced two opponents who collaborated against him in the Italian Opera House in Paris, Salle Le Peletier. His opponents were the Duke of Brunswick and Count Isouard. The story itself is quite fascinating, which you can read up on Wikipedia, or elsewhere, but the interesting thing to me, is how Mr. Morphy sacrificed his queen, despite already having a “material disadvantage”, in order to gain check mate!

Since that was before world chess championships, Mr. Morphy was never officially a reigning champion. However, he beat every opponent so soundly, that before he was 30, he gave up playing chess because no one was a challenge. If only I was that smart!

When it comes to programming our queen into our chess engine, though, we can be really smart! In fact, we can quickly create our queen in minutes, because all we are doing is making a piece that is both a rook and a bishop and combining them in the same method.

As you peruse the queen commit, I’d like to point out something. While we don’t have a full king is safe check yet, notice that we are trying to speed up the making of a list of available moves by first generating the list of possible moves, THEN checking to see if they are “king is safe” moves. If it is not a valid move, then there is no reason to check if it is a safe move in relation to our king.

One of the big goals of this engine is to be an open source alternative for Android app creators, and as such, it will need to run on cell phones, which typically have less processing power than a desktop computer. One of the reasons I started the Just Chess Engine, as opposed to the Beginners Chess Engine, is to get rid of all the try/catch blocks. In the Beginners Chess Engine, we often rely on a try/catch block to fail, so we can stop some part of the process. This leads to wasted processing and time. Here, we are trying to write simple, clean code that doesn’t need a (or at least reduces) try/catch block because it should not return an error.

Linux – keep it simple.

Fool’s Mate Friday: Building Bishops


Did you know that Bobby Fischer’s favorite piece was the king side bishop? Well, at least it is according to Grand Master Mihail Marin in his book, “Learn From the Legends: Chess Champions at Their Best”. On numerous occasions, Mr. Fischer will hold onto his king’s bishop until the very end of the game, using it as a lance to pierce his enemies from afar.

In a notable game with Mark Taimanov in 1971, Mr. Fischer gave up his king’s bishop in exchange for a pawn, which ultimately won him the game, as Mr. Taimanov had to move his last remaining command piece, a knight, too far away to capture it, and was unable to recover in time to fend off Mr. Fischer’s pawns. Looks like I could use some bishop 101, because it would have taken me a long time to figure out that trade working in my favor!

Again, as with our other pieces, moving the bishop on our logical board is a simple set of algebraic rules. Essentially, moving the bishop is: current bishop position +/- 7 or +/- 9 = new bishop’s position. Just like we saw for the rook, though, it does matter what row and column you are on. We can’t have a bishop go right off of the board at column 8, only to return a row up on column 1! Fortunately, as we had already solved this math problem for the rook, adding it to the bishop was easy.

You can check out the code on the bishop commit.

Linux – keep it simple.

Fool’s Mate Friday: A Rook-ie mistake!



The rook is believed to have once been the “rukh”, which was some sort of tower shaped carriage that was placed on top of an elephant. Supposedly, the rukh was the actual fortification itself, and the elephant was the means of carrying it around. In the top of this tower shaped fort was an archer who would rain arrows upon his enemies, able to control long open distances because of his archery. Other variants included men with long spears, who would attack from above. Over time, according to legend, the pieces evolved, and somewhere in Europe, where there are no elephants, the elephant itself was discarded, and the rukh remained, albeit changed to resemble the castle like towers which were common in the middle ages.


Now one can see why they are often erroneously referred to as “castles”. Technically, to castle is a move in chess, involving the rook and the king.

In either event, I set about to add the rook moves to my chess engine. Remember, my logical board is an array of characters. 64 characters arranged in a straight line. Each character is given a numbered spot in the array, so moving a “R” or “r” for rook (white and black respectively), is a matter of simple algebraic math.

To advance “up” a row is: rook current space + 8 = rook’s new space. Down is a minus 8, and to move side to side is +1 or -1. However, there is a catch. If a rook was in space 8 (a2) and did a move to the left (which would be an illegal off the board move), the rook would mathematically end up in space 7, which is h1. This can’t be allowed.

So, what we use is some elementary level math: rook’s current space / 8 = the rook’s row. Since integers are always whole numbers, 57 / 8 = 7.125, which the integer, being whole, always rounds down, which gives us 7. The rook is in row 7. Likewise, if we want the column, we use this formula: rook’s current space % 8 = the rook’s column. This is looking for the remainder after the division, so in the case of 57 / 8 = 7 with a remainder of 1, the rook is in column 1. Very simple to implement and use.

The trick was making sure that we properly use that information. Creating a simple while loop solved that issue. You can see the first rook commit here. However, in all of my “smartness” I made a rook-ie mistake! My mistake was this: there are 8 rows, and 8 columns, but it is not numbered 1-8, it is numbered 0-7! This lead to move errors, as part of my code said if you were in greater than row 1 or less than row 8, etc., which would allow pieces to “fall off” the board (actually creating an array out of bounds exception), or move from one row far column to the opposite column on another row! This is not acceptable! Fortunately, the fix was easy, and you can see it in the second and third rook commits. Yes, it took me two tries to fix my own Fool’s Mate!

Linux – keep it simple.

Fool’s Mate Friday: A knight’s tale.


Now that we have a visual board to display, and we’ve called for the engine to check for all available moves, we need to actually add moves for each piece. Today we are going to start with the knight. I started with the knight because I thought it would be the most difficult.

A fun fact about knights: knights have the advantage of being able to control squares of either color, unlike a lone bishop, however, a lone bishop can trap (although it cannot then capture) a knight on the edge of the board, or rim, especially in the endgame.

I ended up doing the knights move in two stages. I first made the knight’s moves, and later realized a way to make it better.

If the knight is on whichever side of the board, it can make the appropriate L or T shaped move in the opposite side of the board. Since our board is made of number squares, it really was just a mathematical problem. In every case, it is the following four algebraic equations:

  • Move to (m) = Knight (n) +/- number.
  • m = n +/- 17
  • m = n +/- 15
  • m = n +/- 10
  • m = n +/- 6

Pretty cool, huh? Be sure to check out the commits here and here.

Linux – keep it simple.