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

will_castle

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…
theseMoves.push_back(58);
//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?

castleinput

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.

Fool’s Mate Friday: Castle, anyone?

From the git-go, one of the hardest parts of making this chess engine and the following gui system has always been the pawns and the king. Both of these pieces have unusual maneuvers that you can’t easily explain with the traditional shorthand that I was using for the engine. Things like castling, en passant, and promotions.

If you recall last time, I made the pieces movable with a simple two touch interface. The problem is, it checks against the engine to see if that is a legitimate move in the form of piece+square from+square to+captured. This works great for queens and bishops, rooks or knights, but doesn’t bode well when someone tries to castle. This brought me to a fork in the road: change my engine, or manipulate my gui.

I think I should have changed my engine, but I already re-wrote it from scratch, twice. I just don’t have the time to do that again. So, I went with the easier/quicker/less skilled method of manipulating the gui.

Here’s the commit:

public void moveablePiece (View view) {

    // Get the clicked squares tag to see what number it is.
    int number = Integer.parseInt(view.getTag().toString());
    String played;
    if (number < 10) {
        played = "0" + String.valueOf(number);
    } else {
        played = String.valueOf(number);
    }

    if (firstClick) {

        firstClick=false;
        String myMove = tryMove + played + String.valueOf(theBoard[number]);
        Log.i("WJH", myMove);

        if (myMove.equalsIgnoreCase("K0406*")){myMove="K-0-0R";}
        else if (myMove.equalsIgnoreCase("K0402*")){myMove="K0-0-0";}
        else if (myMove.equalsIgnoreCase("k6062*")){myMove="k-0-0r";}
        else if (myMove.equalsIgnoreCase("k6058*")){myMove="k0-0-0";}
        Log.i("WJH", myMove);
        moveOptions= terminal("availMoves,"+String.valueOf(wTurn));

        String[] separated = moveOptions.split(",");

        if (Arrays.asList(separated).contains(myMove)) {

            String query = terminal("myMove,"+myMove);
            Log.i("WJH", query);
            drawBoardPieces();
            wTurn = !wTurn;

        }
        tryMove = "";
        myMove = "";
        mCtv.setText(moveOptions);

    } else {

        firstClick=true;
        tryMove = String.valueOf(theBoard[number]) + played;
        Log.i("WJH", tryMove);
        String query = terminal("pieceMoves,"+ String.valueOf(theBoard[number]) +
                "," + played);
        mCtv.setText(query);
    }

} // End clicked piece.

Essentially, I know there are only 4 possible ways for a king to castle, so I make the gui check to see if that is the case, and then pass the correct move verbiage to the engine. Pretty slick trick for the moment, but it may fall short for en passant. I’ll have to check on that…

Linux – keep it simple.

Added the ability to castle to the Beginner Chess Engine

For better or worse, I added the ability to castle to the Beginner Chess Engine.

device-2017-10-04-111213

In theory, that would always be better. However, adding this feature actually caused two problems:

Problem #1 – Even though the castle works great, as expected, and is successful, occasionally, on the NEXT move of the side that castled, then the rook can turn into a king.

Problem #2 – The king cannot castle in check, nor to check, but can currently castle across check, which is an illegal move.

Hmm…. back to the drawing board I guess. You can check out what I did by looking at the commits.

Linux – keep it simple.