   chess and c++
  well here is my skeleton code for a chess game.I need to know if it is setup correctly.#include <iostream>using namespace std;class Player{int piece;public:bool win();bool lose();};class Piece{int value;public:void move();void capture();};class Board{public:void stalemate();void checkmate();};class Row{};class Column{};class Square{};class Position{};class King {public:void castle_king();void castle_queen();void check();};class Queen{};class Rook{public:void castle_king();void castle_queen();};class Knight{};class Bishop{};class Pawn{public:void en_passant();};int main(){return 0;}
  No, it's not.You need to concentrate on two classes: Board and Move. Board keeps all the state you need to describe the current game situation, and provides methods to generate a list of moves, to perform a move on the board and to undo it. I would start there. You will need other methods and a few other classes, but you'll figure them out as you go.   ;  I would have the individual piece types inherit from the generic piece class.And instead of having a "move" class as suggested by alvaro, have the piece sub-classes implement a interface that contains functions such as "is_valid_move(char rowcol[2])" and/or "get_valid_moves(vector<char*> &movelist)".   ;  There's not enough to go on for me to offer much advice. I think it's good that you're thinking in terms of classes. However, I don't have a clear understanding of your vision for how these classes will work together logically. If you flesh it out a bit more, I may have more advice.I do have some comments about where I think you are going. For instance, consider the Square, Row, Column, and Board classes. I think you may find that some of these classes are unnecessary. What is a Square, except a position where a piece can reside? What is a Row or Column, except a group of 8 Squares?In other words, let's say you wanted to know the state of the board at any time. What you really want to know is, what pieces reside where? You could probably get away with a single Board class, that has an 8x8 array of Pieces, like so:class Board{   Piece m_grid[8][8];public:   Board();   //--- and so on ---//};Now, you would need to define a 'null piece' of some kind for empty squares. Alternately, you could use Piece pointers, and set a certain grid element to NULL if it is empty.As you can see, this gives you all the information that you need. If you know the rank and file of the square that you want to examine, just check the corresponding array element to know which piece is there.If you decide that this isn't enough information, then go ahead and create a Square class. Then, your board can become an array of Squares:class Square{   Player player; // black or white   Piece piece; // Queen, Rook, etc.};class Board{   Square m_grid[8][8];public:   Board();   //--- and so on ---//};Many modern chess games that feature intelligent AI have different data structures, like bit boards. Gamedev has a pretty extensive series of articles on this, which you may or may not find useful for your game: http://www.gamedev.net/reference/programming/features/chess2/I noticed that you have a different class for each piece type. This could prove to be useful if you want each piece type to implement its own methods for determining valid moves and the like. Keep in mind, though, that knowledge of the state of the board would be required. I bishop knows, based on its position, that in theory it can move to any square that is diagonal to the one is currently resides in. In practice, some of those squares may be blocked by other pieces, or the bishop itself may be pinned to the King, thus preventing many otherwise valid moves. Calculating valid moves requires knowledge of the board, so if you decide that the piece classes themselves are to make this determination, there will need to be communication between the piece classes and the Board class.I'm not sure what a method like 'King::check()' would do. Does it evaluate the board for checks and checkmates? If so, the Board class might be a better place to put it, since that class has access to the entire board state. Also, I noticed that there is a generic Piece class as well as classes for each of the individual piece types. If there is functionality that is common to all piece types, you might consider sticking it in the Piece class and then having the other piece classes (King, Rook, etc.) derive from it using inheritance. The last thing I noticed is that the piece types, in the Player and Piece classes, are stored as ints. Consider using an enum, so that your code will be more self-documenting, i.e.enum PieceType{   PT_NONE,   PT_KING,   PT_QUEEN,   PT_ROOK,   PT_BISHOP,   PT_KNIGHT,   PT_PAWN,   NUM_PIECE_TYPES};class Player{PieceType piece;public:bool win();bool lose();};class Piece{PieceType value;public:void move();void capture();};Also, I'm not quite sure why there is a single piece being stored in the Player class. Considering that there are only two players possible (black and white), a Player class might not even be necessary. You may yet find a use for it, but just make sure you need it before you actually make one.;  I think alvaro has some good advice in that you shouldn't get ahead of yourself. Don't try to map out every class you're going to need right now, especially if you're a beginner and you haven't acquired a skill for planning. It's sort of tough advice to give, because planning is generally regarded as a good thing, while jumping into code head-first is considered a bad thing. However, I believe there is a stage at the beginning of every programmer's path where they're just barely learning these concepts from a book, and they haven't really tried things out yet. It's all theory and no empiricism at this point. How can they plan if they can't envision how their plan is going to work?It's sort of a Catch-22. You need to plan in order to program. You need to program to gain experience. But you need experience to write a solid plan. It's actually a lot like chess. A good chess player can see many moves ahead. A mediocre chess player can see maybe 1 or 2 moves ahead. If the mediocre player attempts to calculate beyond 1 or 2 moves, she or he will just spin their wheels and get nothing accomplished.So I think everyone has a point at which you can be analytical to a fault; a point beyond which you can't comprehend how your plan is actually going to run, and the only thing you can do is try it. Eventually, you will see how things work, and this will give you the experience you need to go a little further.If you try committing your plan to code, and still find yourself lost and confused, then the project you took on may be too complex for you. Try something simpler, like Tic Tac Toe. Do some Project Euler exercises.Anyway, I got off track. It suffices to say that learning programming, as far as I've been able to see it, comes in alternating phases of study/planning and trial/error, and you grow bit by bit. Growth is frustratingly slow at first, but speeds along exponentially.   ;Quote:Original post by zerothrillzI would have the individual piece types inherit from the generic piece class.And instead of having a "move" class as suggested by alvaro, have the piece sub-classes implement a interface that contains functions such as "is_valid_move(char rowcol[2])" and/or "get_valid_moves(vector<char*> &movelist)".I'm not sure what basis you have for your advice. Have you ever written a chess program?Having a base piece class and a derived class for each piece type sounds very reasonable on the surface, but you'll discover that there isn't much useful you can do with that hierarchy. An enum for piece types is all you need.I'm not going to comment on the rest of your advice, but I believe it's similarly misguided.;Quote:Have you ever written a chess program?Depends on what you mean by chess program.  Have I written a finished, polished chess application complete with artificial intelligence?  No.  And in that respect perhaps I am, in your wisdom, underqualified to answer this question regarding the design of a chess application.  Have I ever written a program that implements the rules of chess regarding the position and movement of pieces?  Yes, and from that experience I have developed the impression that using a hierarchy of classes was the simplest way to solve this problem.I apologize if the alternative I suggested offended you.   ;Quote:Original post by zerothrillzI apologize if the alternative I suggested offended you.I am not offended, but I tried to give the OP good advice, and I think your first post confused things more than it helped. Having a Move class is absolutely the right thing to do. You'll need to loop through the available moves if you ever want to implement MiniMax search, and having to gather them piece by piece as `char *' won't be very useful....Ooops! I just realized you are thinking of implementing a chess GUI (what you are saying makes a lot more sense in that context) and I automatically assumed we were talking about AI. Hmmm... Perhaps the OP could clarify which of the two he is actually trying to tackle.Oh, and apologies for thinking you didn't know what you were talking about.   ;  I have no experience with minimax, and very little in-depth understanding of how a chess AI would work.  In that respect I, I couldn't and wouldn't comment on either implementation being superior.  The purpose of the char * was to specify a board position as two chars, such as 'A''2', and perhaps isn't the most understandable way to do such a thing.  I should have clarified on that.I do appreciate the apology.edit:sp   ;  thanks for all the advice!   