Castling
https://en.wikipedia.org/wiki/Castling
In object oriented programming, you should never have to know the type of an instance or cast to a specific type reference. But how would you implement castling under these restrictions?
In object oriented programming, you should never have to know the type of an instance or cast to a specific type reference. But how would you implement castling under these restrictions?
closed account (3qX21hU5)
Here are some common information for castling
1: The king/rook involved must not have been moved before. If it has made a move already it can't castle.
2: There must be no pieces between it and the rook.
3: You can not castle when you are in check.
So with them in mind are you asking how you would know when the king can castle without knowing the other pieces information on the board?
Not sure I am understanding the question exactly, but you could have conditions in place to first check if the king has been moved, then if there is any pieces between it and the rook it wants to castle with, and then lastly if it is in check.
Again not sure if I understand exactly what you are asking.
1: The king/rook involved must not have been moved before. If it has made a move already it can't castle.
2: There must be no pieces between it and the rook.
3: You can not castle when you are in check.
So with them in mind are you asking how you would know when the king can castle without knowing the other pieces information on the board?
Not sure I am understanding the question exactly, but you could have conditions in place to first check if the king has been moved, then if there is any pieces between it and the rook it wants to castle with, and then lastly if it is in check.
Again not sure if I understand exactly what you are asking.
Last edited on
His question is that you would need to know the types of pieces in order to do it, whereas in an OO design you generally do not.
I think you have to suck it up and cast (or have a type id in there somewhere).
I think you have to suck it up and cast (or have a type id in there somewhere).
The application of theory is generally not as beautiful as the theory itself, keep that in mind.
TBH. I'd just have an enum that said what type each piece was and assign that to the piece in the constructor. It saves any RTTI or casting on the fly. It could also be useful when trying to determine if you're in check/checkmate, when pawn hits the end of the board etc.
Edit: yes it's not the "perfect" solution. But it's simple to implement, simple to understand and would be simple for another developer to maintain (I'd say the most important aspect of any piece of code)
Edit: yes it's not the "perfect" solution. But it's simple to implement, simple to understand and would be simple for another developer to maintain (I'd say the most important aspect of any piece of code)
Last edited on
@Zaita it's not exactly like a game of Chess needs to be optimized for realtime performance.
@cire: when you plan to add nw kinds of pieces to the game, you would.
@cire: when you plan to add nw kinds of pieces to the game, you would.
> how would you implement castling under these restrictions
This old thread contains some discussions (not about castling per se, but about programming a chess back end in general), and some useful links.
http://www.cplusplus.com/forum/beginner/59546/
This old thread contains some discussions (not about castling per se, but about programming a chess back end in general), and some useful links.
http://www.cplusplus.com/forum/beginner/59546/
| @cire: when you plan to add nw kinds of pieces to the game, you would. |
Actually, no I wouldn't. Ideally one could describe the moves of a new piece and load it from a file without creating a new leaf in the inheritance
Last edited on
closed account (N36fSL3A)
Nerds. Nuff said.
But seriously can you guys point me to a chess rule guide thingy?
But seriously can you guys point me to a chess rule guide thingy?
closed account (N36fSL3A)
Thanks buddy. You always have my back. I actually never seen this page before (Then again the last time I googled this was a few years back.)
| cire wrote: |
|---|
| Actually, no I wouldn't. Ideally one could describe the moves of a new piece and load it from a file without creating a new leaf in the inheritance |
I think I'm turning into fredbill's personal Googler... Anyway, on topic, what IS the problem?
closed account (N36fSL3A)
Something regarding OOP logic is what I get from the first line. My attention span is really short at this time of... day?
@Fredbill: if you don't have an answer, don't answer.
@Lachlan Easton: The problem is that I can't see how not to avoid the type check or cast. Even with cire's strategy pattern and files that describe moves, the file would have to say "this move only works with this specific kind of piece". That feels like cheating.
I've already implemented en passant without such cheating, I'm 100% confident that there is a way to solve this problem too - I just don't know what it is, which is why I started this thread.
@Lachlan Easton: The problem is that I can't see how not to avoid the type check or cast. Even with cire's strategy pattern and files that describe moves, the file would have to say "this move only works with this specific kind of piece". That feels like cheating.
I've already implemented en passant without such cheating, I'm 100% confident that there is a way to solve this problem too - I just don't know what it is, which is why I started this thread.
Create a virtual function
canCastle function will use castlingType and some private data (bool hasMoved) to decide if you can castle.
bool ChessPiece::canCastle(const ChessPiece& other) and protected virtual one ECastlingType ChessPiece::castlingType(), which returns CT_NOT_ELIGIBLE if it can not castle and CT_MAIN or CT_SUPPORT if it is king or rook respectively.canCastle function will use castlingType and some private data (bool hasMoved) to decide if you can castle.
Last edited on
You may not even need to be that specific. For each piece you could keep track of whether or not its moved before, if a piece in any corner hasn't moved then it is guaranteed to be a rook (unless there's some custom board layout shudder) and so without checking its type or canCastle you can know that the king can castle with it.
Well, it was an generalisation suppurting different board layouts, castling strategies and anything else.
Your solution is enough for this actually. We know assumed positions of both king and rooks, so we can just check if they moves.
EDIT: Also hasMoved function is useful to determine if pawns can move two squares too (or just check if they are on their starting position).
Your solution is enough for this actually. We know assumed positions of both king and rooks, so we can just check if they moves.
EDIT: Also hasMoved function is useful to determine if pawns can move two squares too (or just check if they are on their starting position).
Last edited on