OOP Design for Boardgame

Hello. I am making a computer version of the boardgame Thud!, although I guess this will apply to any generic boardgame. I have made boardgames in the past, but would like some advice on what would be good design, especially OOP design that I'm relatively new to.

http://en.wikipedia.org/wiki/Thud_%28game%29

Rather than me reiterate the article, have a quick look. You only really need to read the gameplay section.

My current idea is to create a board type that has a 2d array of cell types. Each cell type has a piece field, and a boolean value for whether or not there is a piece.

Assuming that's right, here's the piece type. My procedural blood tells me that the piece type should have a piecetype field which holds a constant. Dwarf could be 1, troll 2, 3 for thudstone and 4 for corner. (If only Blitz had enums)

My OOP senses are tingling that perhaps I should have dwarf, troll, thudstone and corner types that extend from piece. But I'm not sure how these would tell the game what type they are, other than returning a whatis function constant number. But that's just a long way of doing the above.

So any ideas?

Why do you need a boolean ( which Blitzmax doesn't actually have ) to tell you if there's a piece there or not. If the piece field holds a piece, it's occupied, if not, it's not. I don't see the point of another separate field.

Secondly, I don't know the game at all, so could you explain to me why the game would need to know whether the piece is a troll or a dwarf? The whole point of inheritance is for things *not* to know what type of thing extendedthing is.

1. If I want to see if a piece can move from one square to another, I need to know if that square is occupied. By boolean I mean an int which is just set to 0 or 1 :)

2. Trolls and dwarfs have different rules for movement and capture.

And in what way does testing if the square has a piece in its piece field not solve that problem? I'm still not seeing the need for a separate field.


Then they should implement abstract methods from the base class which define how those rules affect them respectively. If you're constantly checking to see what type they are, you're defeating the purpose of inheritance, and in fact you would actually be better off not inheriting at all.

Make a piece type with an abstract move method.

Then the dwarf inherits the piece type and the dwarf's move method moves how dwarfs are allowed to move.

The troll inherits the piece type and the troll's move method follows the rules of how a troll can move.

etc...

The trolls and dwarfs are two opposing teams, so knowing what type it is also tells you who owns it.

OK thanks.

For the first thing, you mean checking if the piece field is null or not? I thought about that but wasn't sure if it was a safe way of doing it. Guess it is!

I'm still having difficulty with the second bit. For example, a dwarf can only attack trolls and vice versa. So he needs to know what type is he trying to capture.

Yes, that's it. It's as safe as you make it. As long as you make sure you null the field when a piece is removed from that square of the board, it's rock solid.



Right, I think I understand now. In general, I meant what TaskMaster described, but there are a number of ways.

If trolls and dwarfs are really very similar. If, for example, the only difference is like black and white in chess, it's just a team identifier, then I wouldn't inherit them at all. I'd just have a team field and use that.

EG:

Field Team:Int

Const TEAM_DWARF:Int=1
Const TEAM_TROLL:Int=2

Method Attack(Piece2:Piece)
   If Self.Team<>Piece2.Team
      ' The piece is on a different team, so it's ok to attack it.
   End If
End Method

If, as I initially suspected, trolls and dwarves are really quite different, and have different rules about how they move and this sort of thing, then inheriting them probably is a good way to go. Personally, I would definitely want to keep all the type casting or type testing in those types though, because letting the game do it could get messy.

So you might have something like this :

Type Piece

   Const TEAM_DWARF:Int=1
   Const TEAM_TROLL:Int=2

   Method GetTeam:Int()
   End Method

   Method Attack(Piece2:Piece)
      If Self.GetTeam()<>Piece2.GetTeam()
         ' WE CAN ATTACK
      End If
   End Method
End Type

Type Troll Extends Piece
   Method GetTeam:Int()
      Return TEAM_TROLL
   End Method
End Type

Type Dwarf Extends Piece
   Method GetTeam:Int()
      Return TEAM_DWARF
   End Method
End Type

Then I would do something very similar for whatever other rules differentiate the different pieces. If they move differently, I would have an abstract move method. If they attack differently, the same. If there's anything I needed to know about them ( such as what team they were on, but could also be game rules which apply only to certain pieces ) then I would do that with abstract methods too.

It's all personal preference at the end of the day, and there are lots of ways to do it. It's not really right and wrong so much as ways you like and ways you don't. In my case, I don't much like the idea of the game examining pieces to see what type of piece they are. I like the idea of having the pieces do that themselves and then providing a method for them to tell the game if they can do certain things or if certain rules apply to them. At first it probably seems like extra work but as the game gets bigger, it tends to save you more and more work.

They're not -- all trolls move like kings in chess, and all dwarfs move like queens. Plus they both have a special move as well, which depends on the locations of the opponent and their own other units. (They can either do a 'normal' move, or get thrown to the end of a line of identical units, IIRC)

The idea is that the trolls are slow, few in number, and strong. The dwarfs are fast, large in number, and weak.

All games are a two-parter, with both players playing each of the races once.