Classes for chess game

Apr 25, 2009 at 12:39pm
What classes can I make for a chess game?
One class that I made up is
1
2
3
4
5
6
7
8
9
10
11
const int LEN_FIGURE_TYPE = 10;

class FigureType
{
	char m_name[LEN_FIGURE_TYPE];
public:
	FigureType(const char* strType)
	{
		strcpy(m_name, strType);
	}
}

What are other classes that can be?
Thank you:)
Apr 25, 2009 at 1:15pm
Might not be what your looking for, but here's a few links on chess AI. There are some other random things about chess in these links as well I believe - I haven't looked through them myself though.

http://www.cprogramming.com/tutorial/AI/chessboardrep.html
http://www.aihorizon.com/essays/chessai/intro.htm

Hope that helps.
Apr 26, 2009 at 5:29pm
Many moons ago, I wrote a chess program in C - before I realized it should have been written in C++.

Here are some ideas I had at the time for potential classes:

BOARD contains (composition, not pointers) 64 SQUARES.

SQUARE may contain (association with pointers) a PIECE.

PIECE may belong on a SQUARE.

SQUARE knows whether it is black or white and what diagonal, rank file it belongs to.

Possibly a MOVE class, representing the "transaction" of from square/to square.

A transaction that may in fact be "voided" if the RULE class says it is an illegal move.

Possibly a RULES class, which serves as a "judge" for legal moves, how pieces move, etc...

This rules class REALLY comes into play when its time to queen a pawn, as a
pawn's basic "knowledge" wouldn't generally include what to do when it reaches the eigth rank. Isolating the rules in a separate class also provides for the future if you'd like to play "FisherRandom" chess. Otherwise, this dual knowledge would have to be housed in the piece's themselves, which as you may know can be technically, quite stinky.

Anyway, have fun and good luck!

One last suggestion: make your game "dumb" first, making striclty random moves, then layer in "intellegence" later on.
Last edited on Apr 26, 2009 at 5:37pm
Apr 26, 2009 at 7:16pm
PIECE is a class that describes the figure knight, rook...? Im I right?
Thank you very much
Apr 26, 2009 at 8:34pm
Yes, PIECE would probably be an ABTRACT BASE CLASS (A class with at leaast 1 pure virtual function, a class thart can't ever be used to create an object, it can only be derived from).

So you might say:

Class Piece {
int color_;
Square *location;

// things that every piece has & does...

member functions.......
}




Class Rook: Public Piece {

Things specific to rook....

}


Class Knight: Public Piece {

Things specific to rook....

}


etc......




Last edited on Apr 26, 2009 at 8:35pm
Apr 27, 2009 at 1:34am
Actually, I would make move() a virtual function of piece and have it just take the coords to which the piece is going to move. It can return true or false whether the move can work or not.
Apr 27, 2009 at 2:21am
You could do that. And if the only condition of a valid move is that it has to correspond to the path of the pieces movement, that would be ok. But whether a move is valid or not also involves things like asking 'Is the king in check'? If he is, then the only move that CAN be made is one that gets the king out of check. There are others, but the point is that there are things outside of "piece movement rules" that make a move valid or invalid. In other words I would want logic in the Bishop class about whether the king is in check or not. That seems like TOO much knowledge for the pieces ;)) I wouldn't do it that way, but I see your point of a more trimmed down design. I just like to give myself alot of extra room as the design progresses ;)) Because when design difficulties arise (as they always do) there is some room to manuever.
Last edited on Apr 27, 2009 at 2:23am
Apr 27, 2009 at 5:27am
I would think the move should simply determine whether the move able to be completed. Then, the game logic should decide how to respond (i.e. refuse if check happens AFTER the move is done, doesn't block check, opponent castling, etc).
Topic archived. No new replies allowed.