Weapon class structure

Arn't the projectiles themselves the candidates for sub classes? I have class 'object' which is inherited by class 'projectile_weapon' and class 'melee_weapon', and that's where it ends. The projectile weapons are aware of what projectile they spit out, at what rate, and a few other properties. I haven't hard coded my weapons.

Quote:

Original post by speciesUnknown I haven't hard coded my weapons.

Right, well i was thinking of ways to create weapons without hard-coding (scripting) but thought it would be easier just to hard code it in.
And what do you mean when you say "projectiles themselves are the candidates for sub classes"? Projectile weapons inherit from Weapon and distinct projectile weapons inherit from ProjectileWeapon (or ProjectileBullet, whichever way i decide). I want each weapon a subclass so i can write custom code in each. I dunno, maybe i won't need to. It depends on how different each type of weapon is going to be.

Firstly, this isn't quite the right forum. Game Design is more about the gameplay rules and mechanics, rather than technical code design. Moving to Game Programming.

Secondly, I think you need to think carefully about the granularity of your class hierarchy.



This is OO gone mad. And it's simpler than the approach you've proposed because I've left out the LinearWeapon and ProjectileWeapon intermediate classes.

You don't need a class for Ammo at all. And you don't need a separate class for each different weapon type, let alone each different weapon.
Something more like:



This way you have a single weapon class that does everything you need for every weapon. The different weapon parameters can be loaded from a file, so almost nothing is hardcoded. If you want to add a new weapon type, instead of having to derive a whole bunch of new classes, you can just add a new entry into your weapons data file.

Quote:

Original post by XTAL256 So should i do it that way or have different Weapon classes which is responsible for calculating bullet trajectory, etc?

Calculation of a trajectory is a problem of a game/3D/physics/world engine, not a data class. Thought you might append trajectory object to each bullet. (You know if a long barrel weapon would change trajectory, you'd be at safe side.)~_^

resolveHit(ammo, trajectory)

In my shooter, I've got a Weapon hierarchy and a Projectile hierarchy, and my Weapons create and shoot Projectiles when they're fired. It seems to work out pretty nice. This allows for my Weapons to focus on shooting whatever ammo is loaded into them (as long as it is appropriate), and the Projectiles can focus on what they do best: damage! And flying, or "projecting," of course.

Quote:

Original post by Sandman Firstly, this isn't quite the right forum. Game Design is more about the gameplay rules and mechanics, rather than technical code design. Moving to Game Programming.

Right, thanks. I didn't know if this was the right forum but i thought Game Programming was more for actual code rather than class design and stuff.

First of all, i think i would need a Bullet class because this is the thing that is going to hit the target and my event system needs two objects when it detects a collision.

@Sandman: yes, your first way is a bit crazy but i was honestly thinking about doing it that way for a second. Although I would much rather do it the second way, with only one Weapon and one Bullet class. And for projectile/linear i could just have a mass variable which is 0 for linear. But i may want to code each weapon differently. For example, a laser will have a continuous stream while a missile fires a single bullet.

@Raghar: yes the trajectory will be done in a physics component. But how it will be done will be in the Weapon or Bullet class.

[Edited by - XTAL256 on March 6, 2008 6:26:26 PM]

Ok, i have decided to use just one Weapon and Bullet class and hard-code the projectile and linear types in. A Weapon will have this:

int type;         // Either PROJECTILE or LINEARbool continuous;  // True for laser, machine gun, etc. False for missile, etc.

In the future i may use &#106avascript so i can make custom code for each weapon but for now i won't worry about it.

Quote:

Original post by XTAL256 int type; // Either PROJECTILE or LINEAR

This should be an enum, enum WeaponType {PROJECTILE, LINEAR}.

Yes, i will probably use enum. I don't really use enum as much as i should.

off topic: how do i include my sig in a post without constantly clicking "Check here to include your profile signature."? Is there an option in the control panel?

I dunno much about C++ but I'm pretty sure you can use interfaces. I'd probably go with an interface idea. Such as:

etc...

[Edited by - jumpingrock on March 7, 2008 12:48:43 PM]

If you're posting code, you should put your source in ['source']['/source'] tags (remove the all the ').

If you're thinking of an interface like in Java, C++ does not have the same thing. Well, C++ does have interfaces, but they're just classes with all functions pure virtual.

Well, yes, i would have used 'interfaces' if i were to do it that way. But since, like you said, "they're just classes with all functions pure virtual" i didn't bother mentioning such details.
And anyway, i have decided what i will do. I will just hard-code how a 'weapon' works by coding each case (projectile & linear). After i have finished the game i will implement a simple scripting system and use &#106avascript to code specific weapons, i.e. maybe an EMP gun that disables all players for a short while. Such a weapon would have to target <i>all</i> players so i would need custom code for it. But for now i will just settle with limited weapon types.

On 05/03/2008 at 5:26 AM, Sandman said:

class Weapon

{
public:
    enum eWeaponType
    {
        WEAPONTYPE_LINEAR,
        WEAPONTYPE_PROJECTILE
    };
    void Fire();
    void Reload();
    void CalculateTrajectory();
    void DoDamage();

private:   

    uint mMaxRange;
    uint mCooldown;
    uint mAmmoMass; 
    uint mAmmoSpeed;
    ParticleEffect* mpFireEffect;
    ParticleEffect* mpHitEffect;
    // etc
}

Thanks a lot @Sandman. That is exactly what I needed. Data file driven approach is way more appealing than nested OOP structure.

please don't necro 9-year-old threads, okay? putting it back to sleep.