I'm having a small design issue with a Checkers game to be done in Java--

I'm not really worried about coding it, I can do that.

The problem is listing out the dependencies between classes.


For example, what should be responsible for what?

IF I code the program with the checkers pieces being capable of moving on the board, they need to know where they are on the board.

The problem with this? Should pieces really be responsible for knowing where they are on the board, or should they simply be 'used' as pieces?

The problem is broken down into two cases (and could be broken down into more, but for now let's say two cases).

The first case--

Piece base class, BlackPiece and RedPiece derived classes.

CheckersEngine emulates where the pieces can move within the board (adds movement restrictions, etc).

With this method, a piece (since it's really just "a piece") is only responsible for knowing if it has been attacked and killed. It does NOT hold responsibility for moving, since the piece is just "a piece."

The problem with this? I'm no forcing the board to determine when a piece moves and where.


I thought the design for that would be sloppy, and tedious. Sure it is the Engine's responsibility to make the game run, but I just felt that this design could be improved.


The second method results in pieces being more than pieces - they are now CheckersPieces. CheckersPieces know their direction of movement within a given CheckersBoard (so they must have a reference to the Engine).

I don't mind this pattern, because now within the actual Engine, upon loading I can simply call upon "move" for a piece and the piece will move with its given direction.

For some reason I feel a bit stuck. It feels as if the pieces now have too much responsibility?

Really, I just want to know if my approach is correct (and, just as a reminded, my approach is the second method).

-Alex

"The problem with this? I'm now forcing the board to determine when a piece moves and where."

"Really, I just want to know if my approach is correct (and, just as a reminder, my approach is the second method)."

Just correcting some misspelled words from the initial post.

I'm not sure that there is a "correct" answer to this. You have a GUI, which includes a board and all the pieces. I would probably have a Piece class that know its coordinate on the 8 x 8 board and knew its color. You could have a class called CheckersPiece that extended the Piece class, but I wouldn't have the Piece class know the rules of Checkers (what if you wanted to use it in a different game) and hence it wouldn't know how it could move. But it might make sense to have a CheckersPiece class that had a function that could tell you the legal moves using that CheckersPiece. Depending on the particular rules of Checkers though, especially the rule that if a jump is possible, it MUST be taken, a CheckersPiece would probably not have enough information to know whether it can move (i.e. it has the ability to make a move without jumping since there is a space that it can move to, but it is not allowed to because some OTHER CheckersPiece somewhere else on the board has a jump.

You also didn't mention, regarding "responsibility" of making the move, is there any artificial intelligence going on here or is it a human player versus human player game? If it has an artificial intelligence angle, a CheckersPiece would not have enough information probably to decide to make the move. You need to be looking at the whole board for that. So I think the ultimate "responsibility" should lie with a Game or Board class, something that has a birds-eye view and which has a Collection of CheckersPieces. Make the CheckersPieces relatively "dumb". They know what color they are, they know their coordinates, they know whether they are a king or not, and if you pass the Board to them, they can return a list of "possible" legal moves that are available to them. Don't have them actually make the move though. Leave it to a higher level class that can see everything and knows all the rules of checkers to decide (if using artificial intelligence) which move to make and to make the actual move (i.e. change the CheckersPiece coordinates, make it a king, delete it, etc.).

That's my two cents. You are probably going to have some MouseListener attached to the Board, which will be a JPanel or part of a JPanel, and when clicked, will have to know which CheckersPiece was clicked. Call a function within the CheckersPiece class to return whether/which moves are available. That's as responsible/intelligent as I would make the CheckersPiece class. But yes, I think a piece should know where it is and know what directions it can move, so I'd be more inclined to go with something closer to your second idea than your first.

I'm terribly sorry for not mentioning responsibility.

We're going to make this a Client/Server application for users to log in and play checkers. Of course the Server will only host for 2 clients. There wont be any real AI other than the rules implemented in the Engine itself, and the pieces knowing their legal moves.

I already know a few ways of getting the user to interact with the board using a mouse listener, and doing a flip-view of the board (basically the board will appear upside down for the second client so that they can make moves in a more comfortable angle).

I really like the idea of pieces not being capable of moving but knowing their legal moves. I do want to make a move method for pieces that take a mouse x and y coordinate and will return false if the piece isn't a legal move on the board. Of course the pieces will only be responsible for moving within their given direction. I can make the board force limitations on their movement.

Before a piece can move, I will have it selected, and (most likely) make some kind of faint marker of the possible moves for the pieces once it is selected. The user can then click on one of the valid locations, but if they right-click or a click registered on the focused pane is NOT the location, the piece will be deselected.

I can post what I have now from NetBeans. Really it's just a shell since I got stuck with the above problem before you got here.

P.S. I'll mail the code to you so you can see what I have so far.

> I really like the idea of pieces not being capable of moving but knowing their legal moves.

I am yet to see a game where the pieces don't move. Each and every piece is capable of moving though the set of legal moves differ from game to game. IMO, the pieces should be capable of moving be always passed a valid position so that they can dumbly and safely move to the position mentioned. Maybe a common interface like Moveable should do the trick here. Also consider abstracting the 'position' concept in your game inside a class which will provide you the flexibility of switching between 1D, 2D and 3D.

Since you are into a client server architecture, you might as well have a Game class whose instance will be a game in progress having attributes like total game time, the game name, the reference to the board in use and the players involved in the game.

There are many other finer points which come to mind but I think the above mentioned ones should get you going.

You can have a class that just controls the movements. It can check the piece and move it. The board class will have the information about the pieces that are on it. If the region is free, then the piece can move also it'll check the rules defined for that piece. After the piece is moved, you can save the information about the location and all in the piece and have the region on the board 'locked'.

i was going to suggest interfaces too, i think moveable is a good idea. i was going to suggest GamePiece as an interface with a method such as isValidMove(x,y), and maybe isAlive() and some others.

I didn't bother with the isAlive method, but i definitely made an isValidMove in the actual GameEngine.

I went with s.o.s.'s advice to make pieces dumbly move because they really are just pieces being used on the board.

So far everything is good, and now the pieces don't even need to know they are being used by the board!

The purpose of the class (im enrolled int) is not to simply make a functional program, but to practice good OOD concepts. The project I'm working on will be graded on the rule of-

"is it a good design?"

"does it make sense?"

"does it work?"

-and a lot more.

At the moment I'm having a small problem determining if I should have an auto-jump feature for when a user encounters multiple challengers on the board that he must clear in the standard rules of English draughts (checkers). If I don't do this then creating the game will be easy, but the finished product wont be as user-friendly. If I DO implement it, I have to stop the auto-jump when there is a fork (a point where the user has to make a split-decision between which path he/she will take).

I'm nearly done with implementing the rules. I got rid of a lot of unnecessary interfaces and simply let the Engine handle it, whereas the only public methods the Engine has are--


-- and I feel as if the first three methods could inherit from an interface called GameBoard which will make the design look as if it was created from the concept of "a game."

This thread is as good as solved, I just need to know what I should do about the jump-forking? Shouldn't be too hard to implement an auto-jump, I just don't want users getting pissed off if they can't take the path they want.

Design choices you make have to direct impact on your thought process. Had not the pieces implemented the Moveable interface, would the flow have remained the same? Does the ' Moveable ' interface logically make sense? And now do you really think that 'GameBoard' sounds like an Interface name or more so like a name of a Class? Would it make any difference if it were not an interface? Does making it an Interface solve any immediate problem you face?

I still see that you aren't using the abstraction called ' Position ' to hide the gory 2D details of your game. Instead of implementing the additional 'user friendly' features, concentrate on such finer points and you might end up getting more grades than those you focus on the immediate solution at hand. Also does displayBoard() really do all the rendering activity? If yes, then you need to rethink the design since it's really not the responsibility of the Engine to render the board. An alternate design here might be to have a RenderAble interface which is implemented by all the rendering classes like PieceRenderer , BoardRenderer and have methods like draw() , refresh() etc. The way you use these classes would be to have a constructor which takes a reference to Piece and Board respectively which would be with the Game. There are almost infinite possibilities out there when coming up with the design though the best would be the one which doesn't need any explaining to even a layman. All I am doing here is opening up them for you so you can decide what's best given the constraints you are developing the game in.

Though I don't like / play checkers, it's almost a known fact that the initial approximation you end up making for finishing your code turns out to be incorrect and the coding activity takes up more time than planned. My advice would be to forget about the additional feature 'auto-jump' and go ahead and complete your game. Client-Server architecture games aren't that easy to create especially when you are doing them for the first time.

Happy Coding!

I got rid of the displayBoard() method because you're right - an Engine shouldn't be responsible for rendering, it's there to "set the rules." It was there for debugging really.

I think I'm not yet experienced enough to understand the Position abstraction. Do I need to code around the concept of a board (potentially) being in a particular dimension if it is a particular game?

Wait... if what you mean is controlling the movement of pieces based on the dimensional environment I've only implemented it for 2D... I didn't think that people would play checkers in 3D but I see you have a point.

If I understand this correctly, the position abstraction will allow me to implement positions for objects in a 1D. 2D or 3D environment easily by simply extending from Position and redefining methods with their necessary behavior?

"Also consider abstracting the 'position' concept in your game inside a class which will provide you the flexibility of switching between 1D, 2D and 3D."

I have private methods called "isValidMove(int x, int y)," "jumpMove(CheckersPiece, int oldX, int oldY, int x, int y)," "validLocation(CheckersPiece, int oldX, int oldY, int x, int y),"
and other pieces that control where a piece can move. Am I even close to the right track there, or do you mean implementing a "Point" class, encapsulating it, and making each piece have aggregate control on these said Points?

For example, in the Piece constructor, I simply give an array of Positions the piece will be governed by, and code around the possible positions the piece can move from/to ?

I've done something similiar by initially assigning the pieces with a set of points. This can easily be changed by adding a 3rd dimension to the points and simply coding around it.

Again I could be way off. Could you please be more elaborate if I am?