-
Notifications
You must be signed in to change notification settings - Fork 0
Description
So far, I've been assuming that the Pieces in this Chess act like Chess Pieces.
Do you know what else can be played on a chess board? Checkers.
There are a few difficulties with Checkers: 1. The Chess not-an-AI is wholly unprepared for checkers. Waiting out in a trench works reasonably well for a 1900's AD infantry fighting another 1900's infantry man, but it's suicide for an 800's BC Phalanx to jump in a trench to defend against another 800's BC Phalanx.
2. Capturing in checkers is more recursive than the "Recursive" option on my chess pieces. AKA, a rook that has moved left HAS to keep moving left, but a checkers piece that captured another piece by hopping NE can then capture a second piece by hopping NW, a completely different direction.
3. There needs to be some system for accounting for the point value of capturing more than one piece.
4. Checkers Pieces capture by hopping over an enemy piece. Importantly, the capturing piece DOES NOT take the place of the captured piece.
All of these are interesting observations with the potential to render the Chess-App-Which-The-Not-An-AI-AI-Plays-on more robust.
However, I will focus on 4, given its interesting potential to solve the En Passant Problem.
If, I allow the capturing square to not necessarily equal the move square, I can both remove the need for a move's captureBehavior Enum (that will be handled by comparing the moving-to square with the capturable square), and allow an En-passanting pawn to capture without the need for Ghosts (see issue #3 )
Furthermore, I'm going to have to implement some sort of Virginity System to account for pawns being able to move two turns on their first move. Could caveats to a certain captures be cleaner than creating ghost units?