Brainstorming: Attacking and ownership system

[StefanP.MUC]

Because of the recent Cannon bug I mentioned some possible design flaws regarding the attacking and ownership system. I initially thought that we could wait until the refactoring is done but lately I often stumble upon conflicts between the planned refactoring and the attack/ownership system, especially the coveredTiles thing and the fact that many methods need Tiles as parameters.

What are the main problems?

1. Currently an object must find its owner by comparing its color with a list.
2. takeDamage(double, Tile*) needs a Tile as a parameter and is currently always simply called with coveredTiles[0].
3. Attacking is a mix-up procedure of finding tiles and GameEntities at different code places.
4. Current system will be extremly hard to convert to Angelscript

What do I suggest/find more logical?

1. An object should just know its owner (Player* or Seat*, don't know which is the right one here). A pointer to the owner needs 4 bytes just like the color, so technically nothing to worry about. And only the owner knows his color (so the object knows it through its owner). Enemies/allies can identify simply if they have the same owner.
2. An object already knows where it is standing (getPosition(), when refactoring is done also sth. like getTiles()). The attacked tile from big objects (Buildings) should always be the nearest to the attacker.
3. A GameEntity "One" should just be able to attack GameEntity "Two" if its in range: if(Two->isInRange()){One->attack(Two)}, everything else like damage and nearest Tile has to be calculated in attack().
4. GameEntity::attack() should later ideally just pass references to the two fighters to a script function -> can easily be registered to AS

Any comments, improvements, critics on these ideas?

[oln]

a.
A pointer/reference to the seat is probably okay (basically dependency injection?). I suppose we might have to add a "neutral" seat if we need to access the owner.
b.
I agree here.
c.
Agreed. I think we need to differentiate between attacking, and taking damage, as there will be a delay before a sword swing hits (crucial for animations/sounds etc), a missile hits the target etc. Maybe later we could also make the attack process more advanced, such as a creature not taking damage if it moves away before it's hit.
d. Agreed. Though, we shouldn't be too concerned with this at this stage.

[MCMic]

Be careful about moving attack semantic to super-classes as some traps have really specific systems.
A good example is the cannon : (the following is theory, not implemented yet) It first needs to rotate towards the unit it wants to attack, that take some time in which maybe the unit have run away. So it needs to attack an opponent that needs the less rotating (that's not the same as the closest one). It does not really have a limit distance of attacking, I mean it should only detect enemies when they are close but then it should be able to fire them as they are running away.

This is just a bunch of examples, but what I mean is that some creatures or traps might need very specific behaviors when attacking/targetting.

[StefanP.MUC]

The rotation is needed for all attacking entities. Also creatures need to "rotate" to face their opponent. If the oponnent is reachable then just attack. And the specific attack-action is sub-class-depenendent, of course. This can either be solved in the "super-class" (switch over ObjectType) or by making attack() a virtual member and call it from derived attack():
In each Derived:attack() first call GameEntity::attack() (that has common attack stuff like aiming) and then do specific stuff. For a cannon this would basically be firing a MissileObject - and this MissileObject is doing the real attack then. The Cannon doesn't need to care how to do the damage, it just needs to trigger.

I see no problem here.