Designing Movement Around The Board

[Brandon Tom]

I'm developing a board game. Here's what the board looks like:

The 'X' represents a game piece. Pieces can move around the board in three directions:

The directions are indicted by the red, green, and blue lines.

What I'm trying to figure out the best way to design the movement. Basically this is what I was thinking (I said 'was' because it's a TERRIBLE idea): For each direction there are seven rows. I was going to create three classes that represent the three directions and then create objects that represent the rows. There would be 21 rows in all.

Then I'd create a board space object. Each board space is associated to three rows. From there I'd populate the rows with board spaces and that's the general set up.

How valid movement would be determined:

From there all I'd have to do to figure out the movement was valid was to see if the two board spaces (the one being move to and the one being moved from) have a matching axis, then the move is valid.

This tactic looks like it's going to suck. It's totally ineloquent. As you can imagine, there's a lot of duplicate code which is always a sign of disaster (what would Kathy Sierra do?) I need a new strategy and a new inspiration. Where am I going wrong here?
[ March 30, 2006: Message edited by: Brandon Tom ]

[Jan Groth]

hi brandon,

that would be my approach:

create one class which holds the board, the position and methods for moving the piece. if you number your fields in a unique way, it's probably enough to hold the fields in a simple list-like structure:

...1...
..2.3..
.4.5.6.

(...)

your only maybe hardcoded part would be to develop the movement. say you got one piece on field 2. then getPossibleDirections(2) would return something like (up left, down right, down left). or, even better, the numbers of allowed fields (1,4,5). "maybe hardcoded" because in the moment i do not see an easy way to calculate the possible directions. this does not mean that no way exists ;-)

moving would be extremely simple, just make sure that the new field is an allowed position.

that't just a rough idea, but i'd say that's a good start for you project.

but: you said nothing about the game itself.

if you need functionality for (for example) judging the constellation of pieces (what is a good constellation to reach?, what is a bad one to avoid?), you need to find a clever way to weight a constellation. for example you might need a method which returns the number of pieces in the center region of the board, while another method might have to count the pieces which a blocked

those method would perfectly fit into the board class (or a subclass / delegate), but make sure that you don't have needs which require different design ;-)

hope it helped a bit,
jan

[Jeremy Tartaglia]

Actually, I think using a simple 2D array for the board would be the easiest solution:

...S...
..S.S..
.S.S.S.
S.S.S.S
.S.S.S.
S.S.S.S
.S.S.S.
S.S.S.S
.S.S.S.
S.S.S.S
.S.S.S.
..S.S..
...S...

The '.' characters would have to be "no such square" markers of some kind, while the S characters would be either empty squares, or the piece which currently occupies the square. Then, movement is a breeze:

Let x,y be the array position of a legal piece on the board. The possible moves are:

y-2 (up)
y+2 (down)
x+1,y-1 (up and right)
x+1,y+1 (down and right)
x-1,y-1 (up and left)
x-1,y+1 (up and right)

If these expressions yield impossible squares, you know for a fact the move is invalid. Of course, for multiple square moves, it will probably be simpler on programming to go one step at a time, but then I don't know the rules to your game.

You could even pad the board with a few extra columns so that you won't have to check for "out of bounds" exceptions.
[ March 31, 2006: Message edited by: Jeremy Tartaglia ]

[Brandon Tom]

A few people on another forum have suggested that I look into isometric game programming to help me with this design issue. I went out and purchased a very cheap book on the topic and I'm going to peel through it when I get a chance.

If it turns out to be useful, I'll report what I've learned. I've also decided to look at the source code of MegaTek, which is a java version of a board game called Battle Tek.

I've often heard that joining an open source project is often the best way to learn the ropes. The only problem is that it's hard to nail down what it is that I'm trying to learn when, really, I want to learn everything.