Class design to determine child 'instigator' at runtime

Started by
6 comments, last by LorenzoGatti 12 years, 11 months ago
Hi all,

just a quick design query. I have a (simplified) class setup like so:


+ Actor
|
--+ Enemy
| | * member::_weapon
| | function::fire_weapon() calls _weapon->fire()
| |
| --+ Grunt
| |
| --+ SquadLeader
|
--+ Weapon
| | * member::_attached -> grunt/leader, variable is pointer-to-Enemy
| |
| --+ AssaultRifle
| function::fire() spawns Bullet
|
--+ Bullet
* member::_instigator -> AssaultRifle/other_weapon


I'm trying to think of the best way to track back who is the 'killer' of an enemy, when damaged by a bullet. Since the Weapon only has a pointer to an Enemy class (which is abstract), I need to obtain which Grunt/SquadLeader is the one responsible.

From what I know, I see four choices: use RTTI, use a visitor-style implementation, store identifiers within constructors, or just redesign it.

Is there another alternative, or what would you say is the best method to pull off what I'm trying to achieve? I have code in place that ensures a weapon can only fire if it is attached to an enemy, and a Bullet (probably later changed to a projectile) can only be 'fired' from a subclass of weapon (since weapon itself is abstract too), and would like to try and keep these restrictions if possible.

This project itself is going to be an AI implementation test before trying to utilize it within the Source engine, but I want to test outside of engine restrictions first to work out the kinks and get a suitable design. Other parts of this code are subject to the same type of problem as this direct one, so 'fixing' this will also be applied to the rest (such as Actors 'move' function, tracking back the outermost class to determine *what* actually moved).

Any comments welcome :)
Advertisement
Redesign it. If you're encoding data into a typename, you're invariably going to run into this. Being a grunt or being a squad leader isn't a type, it's an attribute.

Redesign it. If you're encoding data into a typename, you're invariably going to run into this. Being a grunt or being a squad leader isn't a type, it's an attribute.


Good point - how then would I define the squad leader? The leader has the unique ability to issue orders for a squad (made up of Grunts, naturally), but also needs to override any orders that a grunt may be executing at the current point.

i.e. Grunt has no orders, and self-determines the best course of action - halfway through the leader issues a new order that must completely erase the current one.

If they were all of the same type, would setting internal flags then be the best route? (e.g. _attrib |= CAN_ISSUE_ORDER, IS_LEADER, etc.)

Mostly curious since the original method is *very* similar to the way the Unreal Engine operates, except all players are of type pawn - but they have no 'leaders' to speak of, only the player themselves.

Cheers
That sort of permissions list is fine. I'd even be fine with a simple enum to store if the actor is a squad leader/grunt and then permissions check on the methods (if the methods are few).

I'm trying to think of the best way to track back who is the 'killer' of an enemy, when damaged by a bullet. Since the Weapon only has a pointer to an Enemy class (which is abstract), I need to obtain which Grunt/SquadLeader is the one responsible.
With the design as it is, any functionality or information you want to get about the shooter entity ought to be visible through the Enemy base class - a pointer to which you already have.

For example, if being shot by a SquadLeader is more harmful than being shot by a Grunt, then use the getDamageInflictionMultiplier() member function on the Enemy class.
I completely overlooked that actually; I should be able to implement everything needed from within the base class with little to no hassle.

A combination of bits should be the sweet spot.

Cheers

Good point - how then would I define the squad leader? The leader has the unique ability to issue orders for a squad (made up of Grunts, naturally)


Grunts and leaders are units. Units may have subordinates. The ones that are leaders are the ones who happen to have subordinates. The ones who are Grunts are the ones who are the subordinates of others.

[quote name='Septic' timestamp='1304024519' post='4804146']
Good point - how then would I define the squad leader? The leader has the unique ability to issue orders for a squad (made up of Grunts, naturally)


Grunts and leaders are units. Units may have subordinates. The ones that are leaders are the ones who happen to have subordinates. The ones who are Grunts are the ones who are the subordinates of others.
[/quote]
Dynamically, simple backlinks to an unit's commander and seniors should enable individual units to figure out, when the current leader dies or disappears, who takes command: one of them is going to start giving orders to the rest, possibly altering the structure of subordinate links.

Omae Wa Mou Shindeiru

This topic is closed to new replies.

Advertisement