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!
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.
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.
The trolls and dwarfs are two opposing teams, so knowing what type it is also tells you who owns it.
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.