Castling

Pages: 123
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?
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.
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).
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)
Last edited on
I wouldn't use an inheritance hierarchy to implement game pieces.
@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.
> 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/
@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 nodetree. The strategy pattern comes to mind.
Last edited on
Nerds. Nuff said.

But seriously can you guys point me to a chess rule guide thingy?
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 nodetree. The strategy pattern comes to mind.
Whether you mean a literal C++ class or a piece class described a file, the problem remains without change.
I think I'm turning into fredbill's personal Googler... Anyway, on topic, what IS the problem?
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.
Sorry L B. I'll try to avoid doing that again.
Create a virtual function 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).
Last edited on
Pages: 123