Original subtitles

Now, suppose that we want to have our rage ability, some sort of variant, we want to have a delayed

rage ability.

Now the obvious way to implement this is to create a subclass of the reachability and add in any of

the extra functionality that we want there.

But suppose delaying something is quite a common piece of functionality, and we want to be able to

delay not only the rage ability, but maybe the heal ability, the fireball ability or any other abilities

that we can think of later on.

Or alternatively, we want to apply different modifiers like a repeating modifier to change the way

the heal ability heals over time or something like that.

Now we can easily make this more modular by saying, let's implement a delaying decorator.

So the decorator would essentially be another type of ability.

It would have its own implementation of use.

But instead of entirely creating all of its own rage functionality there or inheriting from rage, it

would use composition.

It would have an ability that it delays.

That is a property, a private property, and that would be an instance of the AI ability.

So essentially you could slot anything in there.

You could delay any other ability, including and this is kind of interesting.

Another delay decorator so you could delay a delaying decorator and wrap those indefinitely.

So what you would get is instead of having the ability run a pointing directly to an instance of the

rage ability, you would introduce a delaying decorator in the mix.

So the ability runner would point to an instance of the delaying decorator, which itself would point

to the rage ability.

And that allows us to decorate or augment the functionality of that ability that is being wrapped.

So if we changed out the names, what we've got here is the classic formulation of the decorator pattern

where we've got components and operations instead of abilities and use.

And the decorator is something that contains one of the components and has its own operation that overrides

the operation of whatever the concrete component might be.

And you often see this formulation as well, where we take the decorator to be an abstract class that

inherits from the component interface and the concrete decorator often inherits from that.

We're not going to do it this way.

That's a little bit more complicated.

So let's go and see how we can implement a decorator like this now.

If you feel confident and want to give this a stamp for yourself and do pause the video and see if you

can implement this kind of class layout for yourself.

If not, follow along with me.

So what we're going to do is we're going to create underneath the ability interface.

I'm going to create a new public class called the delayed decorator.

And it's going to inherit AI ability.

And for sake of simplicity, I'm going to remove mono behavior from the rage ability and the scripts

will object.

So they are just pure C-sharp classes.

Then I'm going to implement the interface because that will make it a public implementation.

So there we go.

We've got a using method.

It's not implemented yet because in order to implement it, we need the ramped ability a reference to

that.

So we're going to have a private variable in here that's going to be of type ability, and I'm going

to call it the rapt ability.

And that's not going to be set up yet because we need to set that up when we construct this decorator.

But we can now implement the use function that we've inherited here.

We're going to do that by calling to the ramped ability to use and we can do on the line before it to

do some delaying functionality.

So here we've not actually got an implementation that is really workable in the game, but you get the

idea.

The idea here is we do some other piece of code before we call to our wrapped abilities, use functionality.

Now, in order to set this up, we need a constructor that will actually take in the ability we're supposed

to wrap.

You can easily do this in a voice code by doing controlled dots when you've got your cursor on that

private member variable.

So we're going to do a control dart and do generate constructor for delayed decorator.

And that's going to create as a public constructor that takes in a ramped ability and sets it to the

private property.

So your challenge here is going to be to go ahead and construct a delayed decorator instead of that

rage ability that we're doing in our ability run to make a delayed decorator to wrap that rage ability,

pause the video and have a go.

OK, welcome back, so I'm just going to put this new rage ability on a new line because what we want

to do is set the current ability to a new delayed decorator.

And we know that the delayed decorator takes in an eye ability itself.

So what we can pass in is the new rage ability as the parameter to the delayed decorator constructor.

So then essentially what we've ended up with is a current ability, pointing to a delayed decorator,

which is pointing to the rage ability, which is exactly what we had in the diagram.

So hopefully that elucidates how the wrapper the decorator pattern is working here now.

You could swap this out for mono behaviors, or you could swap it out.

The scripts with objects that key that you'd have to work out here is that you would need to point to

either a mono behavior subclass here or a script pull objects subclass in IE ability in order for this

to work, because you'd need to make it a serialized field.

So I'll just sketch out what this would roughly look like.

This isn't going to be a complete solution.

But for example, you would have a public abstract class that would be your base ability.

So and that would inherit from the script full object and from my ability.

And it would needs to abstractly implement the use method like so and then in anything that you want

to make a script for object, you would need to inherit instead it from liability you'd inherit from

the base ability.

So and then instead of having a constructor here, you would set up the link to the wrapped ability

as a pointer to a base ability.

So and have it as a serialized field, not a serialized reference.

Like so.

And then some syntactic changes here.

You'd have to have public override because we're using that abstract class and that just needs a syntactic

difference.

So you would just do that instead, and that mostly works.

You'll need to also pull these out into separate files and have a create asset menu.

And all that good stuff that you're used to from using scripts will object.

But that's the rough outline of how this would work with scripts for objects.

So I'm just going to go ahead and undo all of that to leave our code in a compiler state where we were

just using pure c sharp objects.

And in the next lecture, we're going to build upon that when we're going to look at the composite pattern,

which is related to all of this decorators and strategy pattern family.

I'll see you there.