I've been working on my first semi-large scale game and find myself constantly questioning (and changing) my approach to the overall class design. So much so, that I think I feel like I'm actually getting dumber, for lack of a better way of putting it. [img]http://public.gamedev.net//public/style_emoticons/default/blink.png[/img]
I would really appreciate some feedback on the various approaches I've taken thus far.
The game is to be a "re-roll" (in C#, using XNA) of one of those old box-type strategy games that Victory Games (or Avalon Hill, etc) published back in the 80's - Ambush!, to be specific. I thought this would be a good approach, as having the rules already written would take a load off of the overall burden associated with starting my first weighty project. Also, this particular game was designed as a solitaire board game, thus eliminating the need to develop any AI code. So I felt pretty good about it, and I've spent a decent amount of time studying OO design; however, without the experience, reading about design patterns gets you pretty much nowhere (other than second guessing yourself constantly).
Here are a couple of the current challenges I'm facing:
1) When a unit performs an action, where is the best place to handle validation of that action (e.g. firing a weapon)? In the soldier class? The calling class? The weapon class? or perhaps a combat-manager class?
[indent=1][i]In this instance, validation would require knowing: the stance of the soldier, status of the weapon, whether the weapon is actually in the soldier's inventory, his location on the map, the range of that weapon, whether LOS exists, what type of unit the target is (soldier, tank, structure, etc), whether the firing soldier is aim firing (vs snap firing), the type of terrain the target is in, the solider's particular shooting skill level, whether the soldier is injured or not... I could go on, but I think the point is made.[/i][/indent]
2) Too often I'm finding that game objects (lets say weapons, in this case) exhibit so many "exceptions to the rule" that it has become very difficult to write a method that can just take an instance of a weapon without having to explode that method with TONS of conditionals. My solution to that was to implement a good number of very lightweight (often empty) interfaces that I would have my weapon classes inherit from (as well as an empty blanket, IWeapon, interface). Is this a good design?
[indent=1][i]e.g [b]class Pistol : IWeapon, ICarryable, ISnappable, IJammable, ILocatable[/b][/i][/indent]
[indent=1][i]whereby a weapon's capabilities are indicated by the interfaces from which it inherits, and then any instance really only has responsibility for its own condition (jammed, out of ammo, etc). For it's range and damage (among other things), I used a static 'Tables' class that holds all the game's look-up tables.[/i][/indent]
[color=#008080](Please feel free to keep this topic fresh by commenting with your own similar difficulties. I'm sure I will have more content to add as well.)[/color]
I really appreciate the time and consideration of any who respond. An outsider's perspective would certainly be most refreshing. Thanks in advance! I'd be happy to post some code if that would help clarify kinda where I'm at on some of my more developed classes.