Chess by Cruz Wiki

MANCHESTER COLLEGE
Chess in Processing
Senior Project
Monte Cruz Gregory
Spring 2012

Abstract
The following chess application is the product of my senior project performed for Manchester College that has been in construction since late Fall of the year 2011 and continues on through the completion of the course. The purpose of this paper is to explain the development and what went on with the project during the course. The project, as of April 2012, has close to two-hundred hours invested in it and is in the pre-alpha stage of development.

1 | P a g e
Table of Contents
Introduction ....................................................... 2
Gathering requirements ............................................. 4
Analyzing the problem .............................................. 5
Devising a design .................................................. 6
Version control .................................................... 8
Implementation ..................................................... 8
Interaction between user and computer ........................... 12
How to interact ................................................. 13
Restrictions .................................................... 14
Check and mate .................................................. 17
Undo move ....................................................... 19
Artificial Intelligence ......................................... 20
Conclusion ........................................................ 21

2 | P a g e
Introduction
The reasoning of why I chose a chess application as a senior project goes back about six years when I first became fascinated with the game of chess. At the time I was in my third year of high school. I spent countless hours playing and studying the game with a buddy, who introduced me to the depths the game offers. It became my goal at this time to become as good as I could get. My friend and I created a chess club at the school and eventually had 15 members. This was quite the group considering the meeting time was an hour before school started and the school only had 500 students total. After a few tournaments, in which I was demolished, I understood my goal would be never-ending. This came at the time I started college and throughout the four years spent at Manchester College, I only played chess occasionally on websites. The idea of creating a chess application has always been in the back of my mind. I was privileged with meeting Grandmaster Maurice Ashley personally thanks to Manchester bringing him in for a lecture. I was able to have breakfast with him, which in doing he had asked if I ever thought of creating a chess program. I had told him I have always
3 | P a g e
wanted to and hopefully I could get to that point with my programming skills. Maurice told me directly afterwards, "Saying and wanting to do something means nothing until you actually do it." That saying has stuck in my mind and gives me an increased drive. He had told me to get a hold of him if I ever create a chess application, because he wanted to see it. I figured I would not take up such a project until after I was finished with college. The problem was I had always heard of the difficulties people had with creating one and those stories made me feel like I was not at the level with my programming skills to take on such a project. With the deadline approaching to determine what I was going to do as a senior project, I had three or four ideas that did not include a chess program. A chess program was not even given much thought, but before a meeting with my professor in which I would decide, I penciled in "chess." I wrote nothing else with it but the word at the very end of the list. During the meeting with Professor Raheel Ahmad, we talked of all the projects I had written down. Over the discussion of the chess project, Ahmad had told me to chose it if I was interested enough in it and ensured me I could do it. That's the story of how I set off on another never-ending objective involving chess.
4 | P a g e
Gathering requirements
There are multiple steps that occurred before any implementation of the chess application took place. Planning the development and what will be required for the program to do is the first step in the software's development. In this case there were two people, Professor Ahmad and myself, making the decisions in the requirements for the program, so these were the initial goals to be accomplished. The first goal set was to get the board to be shown along with the pieces. The pieces and board did not need to respond to the user yet for this first step. This sounds like a simple task, but this step needed to be broken down even further when it came to implementing. The idea of taking a task and breaking it down to even smaller tasks is what occurred throughout the development of the chess application. Because this application was a senior project, there were no wild abstract ideas of what a client wanted as an end result. It made it so this stage in the development went quick and did not need much negotiating. When a goal was met, the professor and student met to decide whether the goal accomplished was good enough and whether some alteration needed to occur. During this time if the project was okay to move on, the next goal was given and the expectations for it. Throughout the development of the desired goal, a meeting of
5 | P a g e
how to handle tough problems within the goal occurred periodically. The project was given realistic goals and requirements that needed to be met throughout the development.
Analyzing the problem
The problem is to develop a high quality chess application that any user can interact with, with ease. The language was really not an issue in deciding which one to use. I had worked with OpenGL and Processing mostly in a graphics course offered at Manchester. With a sounder grip on Processing there would be nearly no learning curve and I felt it would be easier. For those unfamiliar with Processing, it is an open source object-oriented programming language and environment for people who want to create images, animations, and interactions. To program the chess game, or any game for that matter, one should study and have a good understanding of the game and its rules. This is essential so the application interacts with ease for any user expecting to play a chess game, and that user would have no problem starting it up and playing. For example, a chess player or user of the application should only be able to move a bishop in a diagonal manner and not be able to jump over any other pieces. Studying the game of chess in this case was
6 | P a g e
straightforward because most of the studying had been done in high school.
Devising a design
It is important to have a solid foundation and design of how to go about coding a software application. Preparing the design for the code was essential to the later flow of the code's development. The first week or two was spent on this step. Due to the lack of time and interest invested to this phase, it led to major facelifts and changes which occurred in the development later on in the process. It is hard to plan everything, but in this situation not much research was done to help an already novice designer. Finding a structure or plan for the code was initially decided by developing a class for each aspect of the game that would display and do the desired work needed from it. The design after a big cleaning ended up with the following diagram.
7 | P a g e
8 | P a g e
Version control
Before working on the next goal, a Github account was created to help with version control. Github is a web-based hosting service for software development projects that use the Git revision control system. Version control was possibly one of the most important aspects in creating the chess application. When coding and adding large amounts of code at a time, it becomes hard to find where errors are occurring. This became a reoccurring problem throughout the process. The problem only got worse, because the Processing IDE was weak in helping find the problems. Version control made it possible to look at the previous versions that worked and find where or why something was not operating properly. Github is a great tool for this task and they make it easy to use.
Implementation
Like stated previously, the diagram above is the latest design not the initial which is explained here. A class was created for each piece that was all used as objects of another class called Piece. A Board class was designed so the board could be displayed along with all the options for
9 | P a g e
the game to have. A class called Chess was created, which created an object of the Board class and would be the host for the runner method of the whole program. So this initial design was implemented first, but due to many issues involving memory, the design was changed significantly and led to delays in the development. For example, there was no need for each piece to have a class when all the data needed could be stored in the Piece class.
So to explain what went on in this goal, I will fray from explaining the code in too much detail so most people can follow it. The first class developed was the Chess class. In this class, there were two main methods: setup() and draw(). These two methods had important jobs to do: the setup method created the total size of the application along with the background and multiple other aspects that needed to be setup for later use. An object of the Board class and a static integer called squareSize was created as global objects for this class. The squareSize is the variable that would determine the size of each squares on the board along with the total size and many other aspects. The draw method is the method running the entire operation. It will call the required methods from the draw class and will loop until the program is closed.
10 | P a g e
Of course nothing can happen right now because there is no Board class yet, so that was the next class assembled. In this class, there needed to be multiple jobs fulfilled. The class needed to draw the board, direct traffic and do the desired work asked. This is the most important class and throughout the whole process, most of the bugs or errors were found in this class. The step of only showing the board and pieces only required a few procedures. Like stated earlier, this step needed to be broken down to smaller tasks. I will explain the tasks in more detail here, but promise to keep it simple and only do it a few times to give an idea of the coding process. The first task was to write a constructor, a method that will setup the Board object when it is created in the Chess class. The constructor had the job of creating all the objects of the Piece class needed (all 32 of them) and setting the values such as coordinate position. The class needed multiple other methods that would create the visual board.
With the Board class capable of doing its desired tasks, the Piece class needed to be assembled. In this class, it needed to have methods that could be used in the Board class to store information needed for the piece. Initially, the program created six objects each of a different class (pawn, knight, etc), this was a novice mistake and led to the
11 | P a g e
program using way too much memory than it needed to. This was how it was first structured, so a bunch of methods were created that will not get explanation here, because they were scrapped anyway. The class held the column, row, whether the piece was white or not, and the type (pawn, knight etc). Not much description of the individual piece classes, but they were scrapped anyway.
With the previous coding steps accomplished, the program was able to show the board and pieces without interaction between them. The previous was an example of how each goal was handled and the process in achieving that desired task. To save time the next goals will simply be explained and little detail of the coding will be given, otherwise this would become a book and not a paper.
The diagram shows a PieceImages class. This class was created after the demolition of the pawn, knight, bishop etc classes to load all the images needed and display them when asked. This design made it so images were only being loaded once and was a major memory usage reducer. The program runs noticeable faster with this design.
Another class that was added later was the MoveKeeper class. This class had the responsibility of recording the
12 | P a g e
moves made. This allowed for rules that needed knowledge of the previous move, such as en passant, to be implemented.
Interaction between user and computer
With the board being displayed, the next goal was to get some interaction between the user and the program. This task first involved a decision on how the interaction should take place. In a chess game, every move is turn based. Each turn a player must select a single piece to move, and this move needs to be within the restrictions of the type of piece. For now, the piece just needs to move and restrictions do not matter yet. There are multiple ways to move a piece in other chess games. For example, the user could left click and drag the piece. Many online chess games will ask after the piece has been moved for verification via a button if the move was the desired move. For this game, I wanted to make everything based on a single click. When the user wants to make a move, they click on the piece then click on the desired square to move the piece. The program will not ask whether this is the move desired, because the user had to make two clicks for a single move and with this feature, the chances of an error is limited anyway. Through previous experience with the drag feature in chess applications, there were times when in the process of dragging, an unclick would happen and lead to an unwanted move.
13 | P a g e
How to interact
To program the click based feature, it involved thinking of what the computer needed to do when each click had occurred. With Processing a method called, mouseClicked(), will allow the programmer to setup instructions to the method which occur when a mouse button has been pressed and then released. It is features like this that made the programming language, Processing, a solid choice to write the chess application in. Since the task of asking if the user has made a click is taken care of, the next step is to tell the computer to ask for the position of the mouse at the click. Again Processing takes care of this task with global variables called mouseX and mouseY. These system variables always contain the current horizontal (mouseX) and vertical (mouseY) coordinate of the mouse. With these variables taken care of, it came down to writing the code that determined the square that was clicked on. If it was a square and whether it had a piece, was the focus for the checks. Again, getting into the details of the code is not the goal here, but it is important to explain some of it to understand all the work actually being accomplished in the code. The code in this task asks a series of boolean (yes or no) questions to determine what the computer needs to do. In this case there are a two things that could occur at a click, either a click
14 | P a g e
on a piece, or not on a piece. At this point the goal is to be able to interact with the pieces, so any piece can be pushed onto any square with no restrictions from the user. With the correct checks and instructions, the user is now able to click on a piece and put it wherever they desire and regardless of who's turn it actually is.
Restrictions
Anyone who has played a chess application, knows the program should not allow them to move pieces anywhere they want. If a chess program allowed anything to happen, consequently it probably shouldn't be called chess. To get the program to have restrictions on piece movement along with turn based features, becomes the next goal set forth.
In deciding on how to go about restrictions on a piece, I decided the coding for this task should all be done in the Board class. This made it easier so there were no passing of tons of parameters to the piece object. All the variables were mostly global and did not need passed to the methods. So the computer could eventually use the restriction methods to test whether a piece could move somewhere without actually moving it, three and sometimes four parameters needed passed: x and y coordinates, the piece number being tested, and with pieces that need to have their first move known took a
15 | P a g e
boolean value that would tell the method whether this was an actual move or not.
Pawns sound like they would be the easiest of all pieces to code their restrictions, but are surprisingly difficult. A pawn has certain moves that can only happen when something occurs. A pawn can move two squares forward if it is its first move. They capture only diagonally, cannot jump another piece, can promote itself after attaining eighth or first rank, and can do a special move called an en passant. Calling someone or something a pawn has a completely new meaning to me; instead of a simple tool, it should be used to describe something that is morphing or versatile. Coding the restrictions for a pawn was the first piece I attempted, and was also the last piece finished.
Rooks and knights went smoothly when it came down to coding. They run by a set of rules and do not need any special treatment. By special treatment, I mean they do not morph, have a special attack, or do anything unique other than their own attacks.
Bishops are very similar to rooks, but coding for the diagonal attacks took some time. When one looks at a chess board, a diagonal move consists of moving the same distance in both the x and y coordinates. If the distance is the
16 | P a g e
same, then the code had to loop to find if there were any pieces between the bishop position and destination position. If there was no pieces between them, then the move was given the clear for the restrictions.
The queen's restrictions, once the restrictions for bishops and rooks were complete, were the easiest to code. The code consisted of the two methods, which gave a boolean value depending on whether the move passed the restrictions of the bishop or rook. It is interesting how the most powerful piece was actually the easiest to code.
The king has characteristics to its restrictions that require information from other pieces and whether it has moved before. Coding the normal move a king is simple because there is only one space it can move at a time. The king has the ability to move two spaces depending on certain circumstances. During what is called a "castle," a king can move two spaces to the left or right and bring the rook from that side to the other side of the king. This can only happen if the king and rook have not moved during the current game, the king is not in check, no pieces between the rook and king, and if there are no attacks on the squares between the king and rook. There are multiple problems to be broken down and could be talked about in great detail here.
17 | P a g e
Not much code explained in this section yet, but one important change in the code happened during the piece restrictions goal. The need for less time during moves occurred. Through analyzing the code, it became apparent in how the piece images were being loaded every time a move was made. This was a major mistake in the earlier design. The solution came by scrapping all the piece classes, such as pawn, knight etc, and replacing them with a single class that took care of all image needs. This class extended the board class and made it possible to only load the images once in the setup method for the Board class during initial startup. This should have been done from the beginning, but I scrap it to a big learning experience.
Check and mate
With restrictions in a stable condition, work began on getting the computer to understand check. I like to attempt a problem with first understanding what goes on in the mind of a real world situation when the problem occurs. Assuming one was playing a game of chess and a check occurs, but it was not stated by the opponent. It is still check, but the player in check may not know it has occurred right away. The player uses his eyes to determine what the opponent's previous move has done to the board. They would look at that last piece and see that the move has put the king in check.
18 | P a g e
The last piece moved may not even be doing the checking, but it may have set up a discovered check. This situation makes it so the computer must ensure that each of the pieces' attacked squares are not putting the king under attack, and not just verifying the last piece moved for the check. To continue the situation, the player then focuses on what they must do to undo the attack on the king, because they cannot move until the check is no longer present. The whole situation needed to be supervised by the computer to ensure a move is really valid and not just complete under piece restrictions. The first step is to find if the last move has put the king in check. If it has resulted in a check then a move cannot be allowed until the check is no longer occurring after the player's next move. There were a few ways I saw this problem being solved. One solution could have been to have a method that looped through all the pieces and determined whether they attacked the other color's king's square through the piece's restrictions. This would have been a solid solution to finding whether the check had occurred, but one problem followed.
The computer needed a way to determine checkmate, and why make the computer do even more loops than the few above? A two dimensional array for each piece was created to hold all the piece's valid moves. As one could see, each array would
19 | P a g e
need to be reset if a new move had occurred, because of how the move could change the scope of other pieces. To store every possible move involved quite some time to develop the methods required for this aspect, but the benefits of the feature allowed checkmate to be determined with ease. Each possible move for each piece was passed through restrictions and if it passed them then the move was stored in the array.
To find checkmate, the king must not be able to move and none of its fellow pieces cannot save him. This required looping through all the king's moves and individually finding if the move from the king would put it under attack from the other pieces. If in doing so the king was determined to be pinned, then another group of checks began to take place. A loop of all the pieces with the same color occurred to find if a move from any one of them would obstruct the check to the king. If the process completed without finding a piece that can save the king, then the game is over, checkmate!
Undo move
With the main guts of the program addressed, adding popular features became the next goal. An undo button allows for beginners and those studying the game to advance their chess skills. To develop the undo feature, a new class was created that would store the moves made. The class contained
20 | P a g e
important values such as x and y positions of the move's original square, if a promotion had occurred, the piece number moved, and the piece number killed. With these values, it was simple to have an undo button. Although it did lead to many changes and additions throughout the code.
Artificial Intelligence
In my attempt to create an artificial intelligence, I discovered the long list of checks I would need to have the computer cover. The AI needed to loop through multiple circumstances and rank the importance of a move. Due to the time I was given, the program only analyzes whether it is being attacked at any position at this time. If the computer is under attack at a certain piece, then the program goes through a series of steps to determine if it can protect the piece or move it out of the way. The amount of code and time spent on this aspect of the AI was enough to get me frustrated and lost in my own train of thought multiple times. As complicated and humbling as such a little part of the AI was, the AI continues to be my favorite project within this chess project. There are chess AIs that can beat the best grandmasters the world has to offer. With my experience developing one to this point, the people who program those AIs are my new heroes.
21 | P a g e
Conclusion
There are multiple features that were worked on and completed that are not explained or talked about here. The ones focused in this paper are just the main goals and features that took the most time. The AI is still in development and plays pretty weak still. The project has been one of the greatest experiences I have had and there is no plan to stop working on it. As of April 10th, 2012, the first public pre-alpha version is available for windows users at:
https://sourceforge.net/projects/chesscruz/
There will be updates periodically depending when I find the time. Thank you for reading, interest and/or downloading if you did. If there are any bugs, which is the purpose of the public release, please contact me on my project email: chessbycruz@gmail.com