Ability Management Design

[safe lance]

I'm thinking the state tracking logic I'm running in the class could be exported to an internal AbilityStateclass and call upon that logic within the AbilityManager as I currently do and deriving classes will overload separate methods which don't require base method calls, meaning I can make them pure abstract.

Not sure if a better methodology would be possible

[dapper inlet]

you could have the public Activate method in the base class which is not virtual/abstract that implements your core logic which calls an abstract protected method ActivateInternalat the appropriate place
so the flow would be
SpecificAbility inherits from abstract Ability
SpecificAbility overrides protected ActivateInternal
Ability has public Activate which looks something like

public void Activate()
{
  //do core logic
  ActivateInternal();
}

AbilityManager calls specificAbilityInstance.Activate()

no idea how thread notifications work so just in case a ping @safe lance

[safe lance]

Thanks Sejadis, taking a look at what you wrote.

@dapper inlet Ultimately, this method will still require the SpecificAbility to make the call itself? My aim would be to have any inheriting ability to not worry about its parent when it comes to overrides. Just like how with MonoBehavior we get the Start() and Update() but we don't have to ever make base calls to them.

Asking for clarification. Thanks 🙂

[dapper inlet]

nah this reverses it, the base method will basically call the overriden one (by seperating it out to a 2nd method) before/after doing its own thing

the abilitymanager will never (and also cant) call the overriden method directly

[safe lance]

Ok so the Specific is implementing that protected method, and doesn't touch the activate method. The activate is free to do its activation logic before or after calling that inherited method?

This makes a lot of sense, thanks @dapper inlet !

[dapper inlet]

yea thats the idea