Week 4: It Finally Broke
March 31, 2023
“Without error there can be no brilliancy” -Emanuel Lasker
Welcome back! As you can tell from the title, things did not go particularly well this week. But that’s okay, I did predict that something will eventually go wrong. Anyways, let’s take a look at what I have done so far and what the error was.
- Castling Mechanics
- Pawn Promotion
- MRTK Errors
- Plans For Next Week
Castling Mechanics
What Is Castling?
One special moves in chess is castling. For those who don’t know, castling is when the king moves two times, and the rook jumps over the king. It’s a move that is played in the majority of chess games because it offers the king greater protection (though there are a variety of other reasons as well).
There are two types of castles: kingside castle and queenside castle. Kingside castle is when the king plays the special “castle” move with the rook on the h-file. Queenside castle is when the king castles with the rook on the a-file (which also happens to be the side the queen starts off on). Here are a few images to illustrate what I mean. Please note – all images are screenshots of sample positions that I created using Chess.com’s analysis board.
In this position, it is White to move, and the White King has been selected. Normally, it should only be able to move to the squares directly adjacent to it – namely, d1 and f1. However, c1 and g1 are also shown as legal moves. Those are the “castling” moves, where the king gets to move twice and the rook jumps over the king.
This is what the position looks like after the king castles with the rook on h1 (aka kingside castle). The king moved two moves, and the rook jumped over the king, onto the f1 square.
Alternatively, the king could have also castled with the rook on a1 (aka queenside castle). Again, the king moved twice, and the rook jumped over the king, resulting in the position shown above.
Rules Of Castling
Now the reason that implementing the castling feature is a nightmare is because there are so many rules regarding when castling is legal. Let me list them out:
1) The king has not moved previously.
2) The rook that the king is castling with must not have moved previously. Note – if one of the rook has moved but the other didn’t, then the king can still castle with the rook that didn’t move.
3) The king is currently not in check.
4) The king cannot castle through check. This means that both the two squares the king moves towards during a castle cannot be under attack by an opponent’s piece.
Rules 1 and 2 are pretty self-explanatory, but I’ll quickly illustrate 3 and 4 with some images:
In this position, the White King is under “check” (since it is being attacked by the Black Knight). Thus, you can see that the White King is not able to castle in this position (c1 and g1 are no longer legal squares for the King).
In this position, even though the White King would not be under check on g1 after it castles, the f1 square is still under attack by the Black Bishop. Thus, if the White King were to castle kingside, it would be “castling through check.” Thus, castling kingside is not a legal option in this case.
Implementing The Mechanics
Rules 1 and 2 are really easy to implement. In the ChessFigure class, I added a hasMove boolean variable that marks whether or not the piece has moved. Rules 3 and 4 are a bit more annoying to handle, but luckily for me, I already have a script, the LegalMoveManager, that checks for checks. To determine whether or not the king is currently in check, I just pass the current position to the LegalMoveManager. Regarding whether or not the king will be “castling through check,” I pass the position to the LegalMoveManager two more times – once after the king moves one move, and again after the king moves two moves. If the LegalMoveManager ever returns false (aka the position is not legal), then castling is not allowed.
I also had to make some changes to the BoardManager. Because castling moves two pieces at once, within the MoveChessFigure method, I checked whether or not the move that is being played is a “castle.” If it is, then I would move the rook to the appropriate square as well, in addition to moving the king.
As you can see, in this position, the White King is able to castle both the kingside and the queenside.
After castling kingside, both the White King and the White Rook have moved, which is correct.
In this position, I have moved the Black Rook on h8 back and forth. Now, after selecting the Black King, you can see that castling kingside is no longer a valid option, as the rook has already moved. Thus, the board correctly shows that the Black King is only able to castle on the queenside.
Here, the White Bishop is attacking the square on c8, which is needed for the Black King to castle queenside. Thus, the program correctly shows that castling queenside is no longer a valid move, due to the White Bishop.
Pawn Promotion
What Is Pawn Promotion?
Another special move that I implemented is pawn promotion. In chess, when the pawn reaches the back rank (8th rank for White, 1st rank for Black), then the pawn “promotes.” What this means is that the pawn becomes any other piece – a knight, bishop, rook, or even queen.
Implementing Pawn Promotion
Implementing this mechanic wasn’t actually too difficult. I only had to make a few changes in the MoveChessFigure method of the BoardManager script. For now, to simplify implementation, I auto-promote pawns to queens, which is the most common promotion anyways. Thus, once the pawn reaches the back rank, I destroy the pawn gameobject and simply instantiate a new queen gameobject.
I did make a few changes to the structure of the program though. Instead of trying to match an index with the corresponding chess piece model, I created two dictionaries – one for white pieces and one for black pieces. Each one maps a PieceType enum to the corresponding chess piece gameobject. This doesn’t make too much of a difference in the program. It’s just helps make the code more readable. Rather than doing pieces[1] to access the White Queen gameobject, I can now do whitePieces[PieceType.Queen].
In this position, it is White to move, and I have selected the White Pawn on the 7th rank (from white’s point of view). If the pawn moves forward or captures the rook (hence reaching the back rank), it will “promote,” allowing it to become any other piece.
I chose to capture the rook, and as you can see, the pawn auto-promoted into a queen.
Now just to check that everything is working, I played a random move for black, and now, you can see that the new white queen has all the appropriate moves available.
MRTK Errors
Now, this week, I did try to begin implementing the actual augmented-reality features of this project. Sadly, I ran into an issue right away with Unity’s MRTK (the Mixed Reality Took Kit). My initial plan was to create a mixed-reality button under every single square in the chess board. That way, instead of using a mouse, the user would be able to press the squares and move the pieces with their hands (which is how it should be in AR). However, there was a problem – when I was trying out Unity’s hand gesture simulation, nothing was working! I was unable to move any blocks, press any buttons, or do anything with the virtual hands. I tried many things to understand why, but sadly, I couldn’t figure out the issue. MRTK is very difficult to get working, so I’ll be meeting with my mentor again to resolve this issue.
These are the virtual hands that I was talking about. I have all the appropriate scripts attached to the cube, so normally, I should be able to interact with the cube using my virtual hands. Sadly, that is not the case.
Plans For Next Week
I talked to my mentor this week about what I’m going to do with the fact that I don’t actually own an AR headset. Although I initially wanted to go to the lab to use the HoloLens 2 device that I’m already familiar with, my mentor suggested that I buy either the Meta Quest 2 or Meta Quest Pro headset. Those aren’t nearly as expensive as the HoloLens 2 (though the Quest Pro is still $1000), and taking a week to go to the lab may cost even more. So, next week, I will be taking a look at the Oculus Development Kit and learning how to use it. I will still be debugging the HoloLens MRTK system as well though, in case the Oculus plan does not work out. Now that I have the majority of the special moves out of the way, I can focus on creating the augmented-reality portion of my project (which is probably the most important part anyways).
Thanks for tuning in! And don’t worry, the “brilliancy” of my project will come soon (maybe). I hope you enjoyed the post, and let me know if you have any questions or suggestions in the comments below! See you next week!!!
References