Jump to content
  • Advertisement
Sign in to follow this  
Septic

Class design to determine child 'instigator' at runtime

This topic is 2785 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

[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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!