   Better way of creating Attacks?
  Ok, necessary background.  Action-RPG game, character runs around, pushes a button, and attacks.  Character has a Strength variable, and a Weapon Object, and a createAttack() method.  There is an Attack class that takes a baseDamage variable, Character.Position, and Character.Velocity/Direction.So how attacks are created/used is like this.  Keyboard input is taken in Update, if the button for attack is pressed, it calls Character.createAttack() which sends all the parameters to a new Attack object which then has its own position, velocity, collision boundaries, and is in every way separate from the creating Character.When a collision is detected between an Attack and a Character, Attack is sent a reference to that Character, and checks whether or not it hits the Character (might not hit because they're on the same team, or the enemy was hit before, etc.).  It then calls the hitCharacter.takeHit method, passing in it's damage, force Vector & magnitude.  Character's takeHit method lowers its health and moves the Character.Is this an acceptable/good way to do this?  I'm curious mostly about whether or not a Character should "own" it's attacks (other than a friendly-fire id).  Comments, suggestions?   
  Sounds like a good way of doing things to me. Maybe have the "Attack" class contain a reference to the original character, so you can have abilities which act as a "counterattack on hit".Also, make sure you store ALL attack related data within the "Attack" class. That way, it has all the data of when it was created, not at the current instant.Example: After shooting an arrow and while it is midair, character drinks potion or +arrow damage. Should the arrow midair get the benefit of the potion? Probably not.Some of the alternatives (IE - Character stores/owns ID of his or her attack object) would be a pain to implement things like multiple attacks at the same time.   ;Quote:Original post by Dekasamight not hit because they're on the same team, or the enemy was hit before, etc.That's something I really dislike in most games today. I think that lack of friendly fire not only breaks immersion, but it also makes things far too easy. Trying not to hit friendly units is an interesting challenge. Plus, in recent wars, as many or more people were wounded/killed by friendly fire than by the enemy, so it is not totally unrealistic.There should at least always be a reasonable chance. It doesn't always need to be close to 100%, but it should happen regularly enough, if you don't pay attention.For example, if you throw a grenade into a room with 3 enemies and 3 allies, you should not expect the explosion and the shrapnels to know who are your allies. You should not expect your 3 allies to walk out unharmed.If you shoot at an enemy who is in hand-to-hand combat with an ally, you should not expect your arrow/bullet to know that it may only hit the enemy (unless it is a "magic bullet"). Sure, it should probably hit the enemy more often since you're trying to aim, but not always.Similar can be said about the "was hit before" thing. One big, successful MMO does it that way with debuffs. While there is probably a good reason behind it (preventing some players from totally disabling others), it doesn't really make sense. Contrary, if you have been hit before, you are actually more likely to be hit again (although this would be a very bad design idea, since it's a negative feedback loop).Well, my 2 cents, anyway :-)   ;  Sounds like a good approach to me. You could model long-term attacks with this, such as poison effects, and you can easily enable/disable friendly on a per-attack base (perhaps delegating that to an attack type flyweight).As for who owns the attack, in terms of memory management it's not all that interesting, I suppose: most Attack objects will be short-lived, you pass them around to a couple of functions and then let them run out of scope. Long-term attacks could simply be given to the character(s) that they operate on.   ;  Alright, sounds like this isn't a bad design so I'll probably do it this way.  Captain P:I do plan on either altering or inheriting from this class for probably all forms of attack, especially long-range.  That's why I liked the idea in the first place.  I can use it for a sword strike, an arrow, and a theoretical triple arrow can just create 3 attacks, give them slightly different Vectors, and be off.Samoth:The Team ID isn't necessarily anti-friendly fire.  It's more because a sword strike's bounding box will usually collide with the character's box, and this allows me not only to avoid that calculation entirely, but not hit myself.  As of now you don't have a team, anyway, but for bigger attacks it lets me specify whether it hits everyone (meteor hitting the screen) or hits only enemies (magical smart fireball) or does different things based on your team (spell heals me and hurts you).  And the "hit-before" is that if an attack can hit multiple enemies, I don't want the arrow going through an enemy to strike them every frame.  It'll do random damage based on framerate, and and any physical force imparted will go from natural and small to unnatural and strange.Akitsune:That counterattack idea is neat, I might have to do that just for the extra possibilities it opens up.  Currently the Attack class does take all of its necessary components immediately on creation, but thanks for noting that.  And after thinking about it more, it definitely feels like a Character shouldn't know what attacks are theirs and what attacks they've created.  For any special attacks that create many attacks (one for each projectile) it'd be a big pain for a Character to store/remember all of them.Thanks guys!   ;Quote:Original post by DekasaSamoth:The Team ID isn't necessarily anti-friendly fire.  It's more because a sword strike's bounding box will usually collide with the character's box, and this allows me not only to avoid that calculation entirely, but not hit myself.  As of now you don't have a team, anyway, but for bigger attacks it lets me specify whether it hits everyone (meteor hitting the screen) or hits only enemies (magical smart fireball) or does different things based on your team (spell heals me and hurts you).  And the "hit-before" is that if an attack can hit multiple enemies, I don't want the arrow going through an enemy to strike them every frame.  It'll do random damage based on framerate, and and any physical force imparted will go from natural and small to unnatural and strange.I would say if you want to avoid hitting yourself you should either never include yourself in the collision detection (like not even consider yourself as a possible collision. Not just have a higher level ignore me condition on you), or you should consider having an "owner" variable that tells you if your the owner. It seems like it would allow for more usability and variability if you want to include or exclude friendly fire.You are lumping in two separate cases together, and this could severely limit your game design down the road.EX: say you want an attack that hurts everyone around you, friends and foes, and returns health to you. You have a team id of 1, your teammates have a team id of 1, your enemies have a team id of 2. How would you implement that?You might think now "I'll never do something like that," but in a month or a year when you think "wow that would be awesome" you won't have to go back into the code you no longer remember and try to figure out what you have to change.   ;  way2lazy:I guess I didn't say it, but I (after reading the previous responses) did implement an 'owner' reference into the Attack class.  Attacks know their owners and exclude them (not via team ID), Character's just don't know their attacks.  Attacks resolve their own collision, and send the proper method calls to those taking effects (enemy is hit, it calls Enemy.takeHit.  Teammate is healed it calls Teammate.takeHeal, etc.)It's more that attacks are responsible completely for themselves, a Character isn't responsible for its attacks, but an attack can call its owner for things like you mentioned, and an attack now excludes its owner through that reference, not the team ID.And that hit everyone to heal might be a neat idea.....   ;  You'll also want to store a reference to the firing character in the projectile...Er, if it is a projectile.Because that's generally the first thing a projectile collides with.   ;Quote:Original post by Dekasaway2lazy:I guess I didn't say it, but I (after reading the previous responses) did implement an 'owner' reference into the Attack class.  Attacks know their owners and exclude them (not via team ID), Character's just don't know their attacks.  Attacks resolve their own collision, and send the proper method calls to those taking effects (enemy is hit, it calls Enemy.takeHit.  Teammate is healed it calls Teammate.takeHeal, etc.)It's more that attacks are responsible completely for themselves, a Character isn't responsible for its attacks, but an attack can call its owner for things like you mentioned, and an attack now excludes its owner through that reference, not the team ID.Then I see no issues. In case you didn't implement it in such a way, you might want to make it possible to let the player hurt himself with his own attacks too. I'm guessing it should be work-around-able, but just in case you didn't yet it might be good too add that for similar reason to the above.   