Jump to content

  • Log In with Google      Sign In   
  • Create Account



Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 Attronis   Members   -  Reputation: 131

Like
1Likes
Like

Posted 02 November 2012 - 02:15 PM

Hey All,

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. Posted Image

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?

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.


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?

e.g class Pistol : IWeapon, ICarryable, ISnappable, IJammable, ILocatable


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.



(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.)


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.

Sponsor:

#2 makuto   Members   -  Reputation: 828

Like
0Likes
Like

Posted 05 December 2012 - 04:26 PM

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?

I 'm not sure what you mean by "validation of that action". Do you mean performing that action, or making sure that action is valid?

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?

You do need the IWeapon interface in order to store all of the different types of weapons in the same data structure.

When it comes to the "lightweight interfaces", I think COM would be a good way to do this. Basically, each weapon would hold a list of "IWeaponComponent"s or something, then you would loop through the list, calling each component. This would make it a lot easier to plug in lots of different components without using multiple inheritance. You can read more about this technique in Game Coding Complete .

Want to get to know my work and I better? See my website: Au 79 Games

I wrote General Tips on the Process of Solo Game Development





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS