\

The Basics

The Piece Class

I'm sitting in my room, a blank piece of paper lying before me on the table, wondering where do I begin? My JAVA teacher has been going over class structures, but nothing near the magnitude of what I wish to accomplsh. My ambition, as usual, has gotten the better of me.

I decide to start brain-storming everything a piece is because this shouldn't be hard for a seasoned chess player like myself. "A piece has a color," I think to myself. "A piece can move from one location to another. A piece has a unique graphic associated with it. Each piece is different." Convinced that I've gotten everything, I jot my thoughts down ending up with something like this...

      class Piece{
         //properties
         Image pieceImage;
         String color;
         int sRank, sFile, eRank, eFile;
         String pieceType;
     }

Then I begin to think, "shouldn't the piece class represent any piece. If it did and the image was a part of it, then the class would have to have all of the piece images; for knights, bishops, pawns, rooks, queens, and kings since they are all pieces." I assumed this would be possible. And then I thought, "if each piece had an sRank, sFile, eRank, and eFile then those properties would have to change each time that piece moved. The sRank and sFile represent a square, just link the eRank and eFile. Squares are not properties of pieces, but of the board. Images, when I thought about it, are also properties of squares and not pieces. This can be understood if one thinks there is a knight on square "f3", draw the knight image on square "f3". An image and a square are closely related because the image resides in a square on the screen. Then I finally realized that there are two squares in my program; one that is drawn on the screen and another that has an sFile, sRank, eFile, and eRank. The image is related to the former. Therefore, it has no place in the piece class. I jotted down.

     String Color;
     String pieceType;

But I wasn't yet satisfied. One could represent the color and piece type with strings. For example, "black", "knight". But wouldn't 0, 2 be the same thing if in my program the integer 0 represented black and 2 represented a knight? The piece class should be as simple ass possible. On my paper, now filled with messy scribblings of some JAVA code, I write...

     int color; //the color
     int kind; //the type

Finally I wonder, "what if a king moved or a pawn or a rook moved"? I would want to know that because it means something. If the pawn has moved once, it no longer has the possibility of moving two squares forward and if the king has moved once, it no longer can castle. Whether or not a piece has moved is a property of a piece.

Now satisfied I decide I need functions in my class to set all of these values at once. They shouldn't be in the constructor because I may want to make several pieces at once, some that have no values set initially. Also I decide that I'll need access to all properties and the ability to set some. I note that I'll never have to set the color and the type since they are properties that can never change, just like a person can never change his color. The piece class is formed, surprisingly simple, logical, and at the same time beautiful. The page that I've written it down on is barely full!



     //simple class for piece maintainance and use
     public class Piece extends Object {
         //instance vars
         private String myName; //for debugging
         private int myKind; //the kind of piece
         private int myColor; //pieces color; 0 for white
         boolean movedYet; //has this piece moved yet

         //constructor
         public Piece() {
         }
         public Piece(Piece p){
             setPieceProperties(p);
         }
         //setting piece properties
         public void setPieceProperties(String aName, int aKind, int aColor, boolean movedYet){
             myName = aName;
             myKind = aKind;
             myColor = aColor;
             this.movedYet = movedYet;

         }
         public void setPieceProperties(Piece p){
             this.myName = p.getName();
             this.myKind = p.getKind();
             this.myColor =p.getColor();
         }
         //access piece info
         public String getName(){
             return myName;
         }
         public int getKind(){
             return myKind;
         }
         public boolean getMovedYet(){
             return movedYet;
         }
         public int getColor(){
             return myColor;
         }
         //set piece info
         public void setName(String aName){
             myName = aName;
         }
         public void setKind(int aKind){
             myKind = aKind;
         }
         public void setMovedYet(boolean movedYet){
             this.movedYet = movedYet;
         }
         public void setColor(int aColor){
             myColor = aColor;
         }
         //reset a pieces properties
         public void emptyPiece(){
             this.myColor = Board.COLORLESS;
             this.myName = "Empty";
             this.myKind = Board.EMPTYPIECE;
             this.movedYet = false;
         }
    }//piece


A Move Object

I'll be honest. It took me while to come up with the idea of having an object that represents a move. This, like the piece class, is another very simple concept. The start rank and start file of the piece represent a start square. The end rank and end file represent an end square. Together, these two squares represent a move from an intitial start file and start rank to a new end file and end rank. A move object serves to hold all this data for transfer to mainly the board. This comes in handy when your writing code that involves move arrays. Instead of keeping up with start ranks files and bla bla bla, you can have one array with a bunch of move objects that encapsulate all of the data for a move. The result, a much more compact program and less code to write. I decide to keep my move class simple, and keep in mind that I may want to just make a start square or end square, part of a move

    class Move{
         int sRank, sFile, eRank, eFile;
         public Move(Move m){}
         public Move(int sRank, int sFile, int eRank, int eFile){}
         //constructor
         public Move(){}
         public void setStart(int sRank, int sFile){}
         public void setEnd(int eRank, int eFile)
         public void setSquare(int sRank, int sFile, int eRank, int eFile){}
         public int getsRank(){}
         public int geteRank(){}
         public int getsFile(){}
         public int geteFile(){}
    }//move


The Board

My piece class is made, and now I'm thinking about the board. The pieces are just objects and without a board they mean nothing. I realize the board is an 8x8 array of squares and I've even drawn one out on the scratch paper laying in front of me. It is about 2 weeks after I've developed the piece class! I fill all the squares on my board with yellow(my favorite color) and black. The concept is simple. The board is an array of squares each that can contain a piece or be empty. The board is an 8x8 array of pieces. So I write..

            Piece board[8][8];

      This is a good start. However the formulation of a board is much more complex than that of the pieces and the moves. This is because the board contains algorithms for defining how the pieces can move through it as well as the properties that the piece and move classes contained. However, its properties are far more complex and can be arrays and other objects. Here ask youself, do I understand what the piece and the move represent? If you do, then the board class I will show you is a piece of cake. And once you've got the board, everything else is a walk in the park