• Content count

  • Joined

  • Last visited

Community Reputation

131 Neutral

About Attronis

  • Rank
  1. 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. [img][/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.
  2. Topic redirected to: [url=""][/url]
  3. Simple game

    [quote name='greenvertex' timestamp='1350581901' post='4991490'] Everyone starts with pong... Just do that. Trust me, there's really no magic going on behind the scenes here. Rarely are there bits of arcane knowledge to be gained by looking at others' code for simple stuff. You'll learn a lot more by doing yourself than you will by watching someone else do. [/quote] Not to speak to the contrary of most assuredly a more experienced programmer, but for beginners really looking to tackle their first project (I do speak from experience here) it can sometimes be overwhelming "putting the pieces together." I've found that it can help to look at the way other people have structured their programs, or ways in which in they manage their data, etc. However, one would be well advised to look for example code that is [color=#800000]not more complicated than you are ready to digest.[/color] Also, you're looking to glean ideas here, not foundations; you [i]will[/i] learn very little if you "core" a program and decorate it to suit.