Week 10 – Python Chess

I’ve been working on cleaning up some of the modularity issues and spreading the work required for castling between the king(moving itself and the rook), the rook (added a function to calculate where it moves when castling) the board (finding which rook to castle), and the legality functions (whether castling is legal).  I decided to integrate the legality functions into the board class because the major functions depend on the matrix which is stored in the board class.  I also added the board labels to the individual players which saves a few lines of code when redrawing them each turn.

Of course now I’ve run into a snag.  The full legality of castling involves checking whether the king is in check, or moving into check, or across check.  Until now I’ve treated the king, for the most part, like just another piece.  In thinking about the intricacies of evaluating check situations I decided to iterate through the opposing pieces to see if the king is located in their path.  However the complication comes in deciding when to evaluate a check situation.  It has to be done before the pieces actually move to a new location but must take into account the new configuration of the pieces.  What this means is that I need a transition matrix for the pieces to run the check scenario.  After determining that the king is not in danger I can collapse the transition matrix back into the real matrix and move the pieces accordingly.  What this means is that the pieces will not actually move themselves. Unfortunately this will probably require a radical rethinking of the way that the game, the players and the pieces interact with each other.

This is definitely a drawback to prototype design, and a really good argument for planning out the dynamics of a major project ahead of time.

So when I do the presentation on Tuesday I can offer a cautionary note in the development process.  I will cover the basics of Object Oriented Programming, and the different development processes, including top-down, bottom-up and spiral (prototype) design.  Demoing the game should be interesting.  It’s at a point now where all of the moves, including en passant capture and castling, are functional.  The higher logistics of legality are the only major hurdle to functional game play.

After I finish the functionality, I still want to design more of the GUI, including adding actual bitmaps of the pieces and showing which pieces are captured.  I also want to add save functionality and a move list annotated in current algebraic notation.  I’m glad I don’t have a real deadline to finishing the game, because I’ve got no idea how long it will take to get it to a point where I consider it ‘finished’.  If nothing else it’s a great programming exercise.

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*