If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
Perhaps it would be prudent to also re-use any possibly already attached specific behaviour components and return those instead of always creating a new one.
I’m referring to these lines in the AbilityConfig imlementation clases:
public override AbilityBehaviour GetBehaviourComponent(GameObject objectToAttachTo)
{
return objectToAttachTo.AddComponent();
}
It really depends on the use case, so this could be a non issue for the course game, but odds are, that someone will end up calling this several times and end up with multiple identical MonoBehaviours on their player.
So thinking back on this lecture there are definitely a few things that I am having trouble understanding.
1.) I don’t understand how this is not causing an error.
public abstract AbilityBehaviour GetBehaviourComponent(GameObject objectToAttachTo);
Specifically how does the AbilityBehaviour in the line above work, assuming it just allows you to reach into the protected AbilityBehaviour and access the behaviour type.
2.) AbilityBehaviour behaviourComponent = GetBehaviourComponent(objectToAttachTo);
I am assuming this is of type GameObject and thus the variable name is telling us that we are attaching a gameObject to the children. I am unsure of this gameObject but my guess is that the gameObject is actually the skills we are using such as the heal, area of effect attack, and the power attack.
3.) I still do not understand the process of SetConfig(this);
My guess is that we are setting the config to the AbilityConfig as the superclass and that will take control over the child classes.
4.) return objectToAttachTo.AddComponent();
I am guessing that we are returning the object we have attached to ie the spells, and we are then adding our current coresponding behaviour to that spell. PowerAttackBehaviour for the power attacks.
C# doesn’t allow you to pass around classes (not instances, but references to the class itself)?
It’d be a lot nicer to treat this like config so the member and the abstract class aren’t talking back and forth to each other, like:
public override Type BehaviorClass() { return AreaEffectBehaviour; }
and do the logic of adding the component in the abstract class:
public abstract Type BehaviorClass();
public void AttachAbilityTo(GameObject objectToattachTo)
{
AbilityBehaviour behaviourComponent = objectToattachTo.AddComponent<BehaviorClass()>();
behaviourComponent.SetConfig(this);
behaviour = behaviourComponent;
}
Someone on stackoverflow indicated that this should be possible, but it doesn’t seem to work