The Move Class

The Move class is probably the only class ( except the classes of the evaluation package) that I have had to change so many times.
The Move class basically encapsulates the following details:

• Location from
• Location to
• Piece movingPiece
• Piece capturedPiece ~~> Null if nothing has been captured. More about it in MoveType
• MoveType type

int searchVal ~~> This is for sorting the moves after generating them based on some static features.

At first, there were only the aforementioned variables and there getters and setters.However, there were several difficulties.First and foremost was that this representation was not suitable for castling moves.

So, I made an enum called MoveType. There are 7 move catagories 

1. Normal ~~> just plain moves
2. Capture ~~> capturing moves
3. ShortCastle_White
4. LongCastle_White
5. ShortCastle_Black
6. LongCastle_Black
7. EnPassent

Initially,  having just learnt enums to quite a extent for the OCP exam, I was really on a mood to try out there powers.So, I created an array within constant-specific-class-body of the castling moves to hold the individual rook moves and the king moves.It was statically initialized.For that, I also had to build a new constructor in the Move class taking MoveType as a parameter.

Now comes the executeMove() and the undoMoves() and there helper methods.

Internally, if the Move parameter is a normal move, then the executeIndividualMove() method is called.There, the previous Location of the piece is vacate() (a method of the Spot class),then the Location of the captured piece is vacated (if any) and then the occupy() method of the corrosponding Spot object is called.(corrosponding to the destination Location)

However, calling the vacate() method before occupy() is important as it takes care of some minor details.

This is why I made an array of Spots and not a plain array of Pieces as a lot of code could go into that Spot class and could be reused.

The executeEnPassentMove() method is a bit different but basically the same.However,generation of enPassent moves is really difficult and a Stack has to be maintained for the last move, not a simple variable as else , without a stack, a call to undoMove() will leave us destroyed.The undoMove() method and its helper methods are pretty similar to the executeMove() and its variants, but there functionality is the polar opposite.

The EnPassent moves are generated in the getMoveList() method of the Pawn class.However,it is very complex and so i will just leave it to the reader to read the src code when i post it.

However, you will see that now there is no code in the MoveType class and has been fully shifted to the Move class itself.This is because when i was building a UI, the new game feature was really troubling me.See, when a new game was started, new Piece objects were created along with a new Board.But the MoveType's individual moves were static, which meant that the objects were different.Thus ,often after castling , 2 kings would appear along with several other bugs while generating moves.Thus, after hours of troubleshooting, I finally detected the problem.However, after that it was pretty easy as only the code in these 2 classes had to be changed and nothing else.  

Thus , this is how move generation and execution works.