Jump to content
  • Advertisement
Sign in to follow this  
BigFreak

Fundamental design problem

This topic is 4418 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Rightyoh, so I'm trying to design a simple chess simulation OO stylee and have a fundamental question. Ok, so the Pieces have a position. However this would mean that they knew, in some way, about the board they are on->bad design? So I figure it doesn't matter, their position directly correlates to their position in an array(/vector/container of some kind). Fine. But then doesn't this mean that all pieces have the same behaviour and that the game then ensures the Pieces move in the correct manner? This would render the whole inheritence that I'd planned useless and there'd be no need for any subclasses. Any ideas/thoughs welcome. Yeah.

Share this post


Link to post
Share on other sites
Advertisement
well im still new to this myself but in my mind...

i think the board should have the pieces. a list of positions and what is at those positions

then the individual piece classes would have the moves that they could perform

the board would pass the position to the piece, and the piece would return where it could move from there

Share this post


Link to post
Share on other sites
If you really are set to keep the position out of the Piece class, then you have to pass it as a parameter when needed. For instance, if you want a method that returns a list of the valid positions the Piece can move to, you can declare it like:

class Piece
{
...
virtual std::vector<Pos2D> ValidMove(current_pos:Pos2D)=0;
...
};

...and override it in any of the subclasses like KingPiece or QueenPiece. Although I really don't see what's so bad about the Piece having a position member. Of course every Piece can have a position like B2 and must know how to move, otherwise if it didn't it wouldn't be a chess piece but a piece of wood. The 'problem' would be if it had a member referencing the actual Board.

Share this post


Link to post
Share on other sites
there is nothing fundamentally wrong with a piece being associated with a board ... and a board having associated pieces. 2-way associations are quite common. Sure there are many problems that are better solved by removing redundant references and improper binding, but this is not one of them.

A single instance of a game of chess is always played by 2 players, at 1 chess board, using an initial set of 16 white and 16 black pieces. If there is another chess board at your house, it has its own set of 32 pieces. You can logically navigate from any piece of information to any other ...

current game -> current player -> player 2 -> active pieces ==> collection of pieces

current game -> board . at position (rank, file) ==> null, or a piece

some piece . current position
some piece . is captured?
some piece -> board
some piece -> player

just make sure you maintain the relationships properly ... often times it is easier to write just the primary association first ... then later add the "secondary" association as more of an optimization than a fundamental requirement ... thinking of them this way helps you identify that they are 2 views of the same association on a UML diagram.

a good example of such a situation is:

A car has an owner, and a person is the owner for 0 or more cars. Sure in a database the many-to-one relationship is modeled as just a foreign key in the child table (car) ... but in the object-oriented world we are not assuming the ability or desire to access the entire pool of car instances in order to walk through them and find all cars that are owned by a particular person. Instead we would maintain that data directly.

Share this post


Link to post
Share on other sites
http://www.cis.uab.edu/hyatt/boardrep.html

That page is an EXCELLENT tutorial for making a Chess game, written by one of the best Chess programmers out there. There are other tutorials on that site to read after you have finished the foundation.

Object-orientated? Don't force a particular style just for the sake of it...

Share this post


Link to post
Share on other sites
Quote:
Original post by CzarKirkObject-orientated? Don't force a particular style just for the sake of it...


Agreed. Also, consider that a chess piece that is not on a chess board is not really a chess piece. A piece's relationship with the board and with other pieces is an integral part of its definition. Whatever internal representaion you use should really relect that.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!