Thread: If you had a chess-like boardgame....

....how exactly would you build an object-oriented program for it?

Suppose the game has the following basic rules:
1.) Two players
2.) Each player has 10 units that are placed on a grid-like board
3.) Players alternate turns by moving one unit at a time
4.) Units can attack each other (if within range) and deal damage to the units health (unlike in chess where everything is a one-hit kill).
5.) Each unit moves in a unique manner (some can move three spaces, some can move 4, etc.)


What would your object-oriented program look like?

I'm thinking there needs to be the following classes:

Board class, Player class, Game class, Unit class

Where the Game class contains one board and two players. Each Player has ten units.


But, where I get confused, is where do you put the "move" method??????

It seems that the move method should be a part of the Unit class, since each unit possesses the ability to move. But, in order to move, the Unit must have access to the board (to determine where it can move). But I don't see why it would make sense to have every Unit have a board data member. That seems wasteful...or is it?

I really don't know....I'm not much of a programmer, and I know you guys are much more advanced than me. So how exactly would you deal with the move method here?

Thanks for thinking your design through before writing code. Even with a thorough design in mind and then written down, you can run into unexpected requirements later that may require design changes. The more thought up front, the fewer changes along the way, the less time spent rewriting code. You may need additional classes to present the game's interface to the players, so you might want to give that some thought.

As for where the move() method belongs, I'm not even sure there is a move() method. Don't the users or players decide which Unit objects to move and where to move them? Aren't the users/players responsible for knowing the rules, how their Unit objects move, and where each can move from their current locations? Or is there some AI involved so that Unit objects move themselves?

I can imagine a Unit.move() method similar to move( Location newLocation) that is commanded by the user/player. That method would physically move the Unit's graphical representation from its current location to the new location and then update that Unit object's state to the new location. There could be some validity checking as to whether the move is legal, the new location is available, etc., but some of that (all?) should be the player's responsibility. As in a real chess game, the pieces have specific moves, but it's up to the players to move the pieces correctly and to approve the other player's moves. That's part of the game.

That's an interesting point.

But what I always thought was this:

when you play chess, if you click on a piece, all the panels on the board to which you can move light up. You then click one of those panels, and the piece moves there. Moving to an illegal panel isn't even an option.

In addition, my game is a bit more complicated than chess for a reason I failed to mention in the original post: you can move through friendly units (they will "step aside" to let you pass") but you cannot move through enemy units (they will block your path).

As an example, suppose one of your units can move three panels in any direction. Suppose that there is an enemy unit right in front of him. This means that your unit would have to move around that enemy unit. If you visualize it, you'd see that your unit cannot move behind the enemy unit with just three moves, despite the fact that the panel behind the enemy unit is just two panels away and your unit can move three.

This makes things a little complicated. I also think the game would be better and easier to play if all the panels on which you could move lit up every time you clicked on a unit.....but determining where each unit can move is somewhat difficult. Since it's possible for inexperienced players to be playing this game, I think it'd make more sense for the game to determine whether each move is valid. What if a player just calls another player's move invalid, even when it isn't? What if a player is new to the game and has not yet learned all the rules (some units, for example, may have special abilities that allow them to move through or fly over enemy units)?

In addition, I need to remember the path each unit took to move because ultimately the game will show the unit walking (in animation) as he moves. It's also worth noting that this needs to be the shortest path.

This function seems complicated enough to need its own method, though I'm still unsure of where it would go.

if you click on a piece, all the panels on the board to which you can move light up

That's a valid option but may not be always turned on. Sounds like a bit of a crutch.

As you've described the rules of Unit movement, each piece or unit should know what move(s) it is capable of making but may not know which of those possible moves are allowed by the game board's current state. I would expect the allowed moves to be defined by some game controller above the Unit level. From that, I imagine the user selects a unit, the unit reports the moves possible according to that unit's movement rules, and those possible moves are fed to a game controller to process and indicate which of those possible moves are allowed by the current game state, indicating the possible end points and possibly the effect of the movement along the paths to those end points once selected by the player, depending on how much detail you can/want to show.

You've thought most of this through. You seem to have a good idea of how you want the game play to occur and to appear to the players. Programming the mechanics of realizing Unit movement doesn't seem like it would be that hard. Don't give each unit object more responsibility for its existence and movement than it should have. This will keep responsibility for game play where it belongs and will require you to reduce each element of the game into its simplest form, reducing the overall complexity of the game's design as as much as possible.

Start by writing out everything the game should do - its functions. Then define the classes you think are necessary to do those things and assign each of the game's functions to the classes you've defined. Write a plain language description of each class, the game's functions it is responsible for, and how each class accomplishes those functions. Ultimately, you'll want to define each class' inputs/outputs and the data dependencies between classes. If you have functions left over or create new ones as you go through this process, define additional classes to handle them, as many as are needed. If the plain language descriptions of what the classes do begin to sound too complex or inappropriate for that class, create additional classes to share the load.

Don't start coding until you have all of the game's functions defined and assigned to classes, and you've written class descriptions in as much detail as necessary to ensure all game functions can and should be accomplished by that class. Once you've thought it through and documented the design to this level of detail, coding is much easier.

Thanks a ton for the help guys!

I have a lot of great advice to look through. I'll read through everything you guys said carefully. I think it helps a lot to hear advice from advanced programmers. Thanks again!