ActionScheduler - Help

[enkacang]

This is my second time through this course and I’ve understood 100% all the lecture until at ActionScheduler

Can anyone tell me in detail what’s this magic all about?

I have played this video two times and still, I can’t get a hold of it.

Thanks in advance!

[Brian_Trotter]

Let’s demystify this.

First off we’re dealing with the concept of an interface. Interfaces allow us to add functionality to any class in a way that somebody calling that class doesn’t need to know anything about the class except what the interface exposes to the world.

So suppose we had an interface like this:

public interface IConsumable
{
    void Consume(GameObject consumer);  //The public is implicit in an interface and cannot be specified
}

And we have a variety of foodstuffs:

public class Cake: IConsumable
{
      public float healthToGain=5f;
      //other properties and methods unique to fruit

      public void Consume(GameObject consumer)
      {
            consumer.GetComponent<Health>().Heal(healthToGain);
            consumer.transform.localScale=new Vector3(3,3,3);
            Debug.Log("Oh my, I'm too big to move!");
      }
}

public class Bottle, IConsumable
{
     public void Consume(GameObject consumer)
     {
          consumer.transform.localScale = new Vector3(.1f,.1f,.1f);
          Debug.Log("Oh dear, this made me shrink!");
     }
}

public class Tea, IConsumable
{
     public void Consume(GameObject consumer)
     {
          Debug.Log("Mr. Hatter, this is delicious tea!");
     }
}

In the above example, the three classes are different from one another, but they all implement IConsumable. We could do the following:

public void EnjoyTheFood()
{
    foreach(IConsumable item in FindObjectsOfType<IConsumable>())
    {
         item.Consume(gameObject);
    }
}

Now if we had one Cake, one Bottle, and one Tea in our scene in that order, you’d get the result
Oh my, I’m too big to move!

Oh my, I’m too big to move!
Oh dear, this made me shrink!
Mr. Hatter, this is delicious tea!

In our case, the interface is IAction.

public interface IAction
{
     void Cancel();
}

Any class that implements this interface must have a public void Cancel() method or the compiler will fail. This is the guarantee of the interface.

Now we get to the implementation, in our case we’re putting it on the Mover class and the Fighter class. This means that both Mover and Fighter must have the Cancel() method.

There is a second part of this interface, and this is where the magic happens. You can get a reference to an IAction, just like you could get a reference to Mover or Fighter. We’re going to pass that reference to the ActionScheduler’s StartAction()

So if Mover calls the StartAction, it would be

     GetComponent<ActionScheduler>().StartAction(this); //this is the Mover component

Then the ActionScheduler first checks to see if this is the current action already in progress. If that’s the case then there’s no point in continuing.
It then calls Cancel on any action in progress (after null checking, of course). Now we don’t know if that action is a Fighter, or a Mover (or perhaps in the future a Miner, or a Herbalist?). We don’t know, and we don’t care. In fact, we can’t even get information about what that IAction is, only that it’s guaranteed to have a Cancel() function. It doesn’t matter, because whatever component implements IAction must have the Cancel() method, and that’s all we care about. ActionScheduler then saves the new current IAction (Mover) as the currentAction

Now the Fighter has initiated Attack(), and that method also calls StartAction(this);
But the Mover was already the current action. The ActionSchedular sees this Mover is the current action and ActionScheduler calls Cancel() on it. Mover handles the Cancel, and now Fighter is the currentAction. ActionScheduler, once again, has no idea what the component is, only tha t si

As long as we use it consistently, only one IAction will ever be active at once.