All language subtitles for 009 Strategy Pattern_en

So let us imagine for a second that we are writing a special abilities system, and in this special

ability system, you could have one of a number of special abilities equipped and that could change

it while you're playing.

You could run into fireball power up and you could get fireball special ability, for example.

Now, very naive and probably not.

The best way of doing this would be to have an ability run out on a behavior that's not the problem

here, but then configuring the particular ability that you have using an inner.

So here, for example, I've got an ability in them and it could be the fireball rage or heal that is

equipped at any given time.

And we can imagine that this could happen through power ups or running into different colliders, that

sort of thing.

But what is clearly visible is that if we had a set for this, you could set the ability at runtime

and then when the use ability public method is called, maybe by hitting a spacebar or clicking a mouse

button or something like that, then a switch is triggered here.

And depending on which enum we've got selected, a different behavior happens down below.

Now, the problem with this is that every time I want to add a new ability, I need to come into this

class.

If these abilities are more complicated, which they should be.

Then I'm going to have to add a lot of code into here, and it doesn't separate any of that out.

So the better way for us to implement abilities is for ability runner to have an ability field, still

a current ability field.

But instead, this ability points to an interface, an ability or an AI ability interface, which has

a use method and because it's an interface, didn't actually have any code in that use method.

It's just defining the contract for what availability should look like.

So then the ability run up word when use ability it would call use on the currently set ability, then

we could have a fireball ability which inherits from the ability interface and actually concretely implements

its use method.

And we could have a rage ability, which derives again from the ability interface and implements its

use method.

Now, if I were to go and change the names here, what we've just gone ahead and implemented is the

strategy pattern.

So if we swap out ability for strategy and we swap out use for algorithm, then it is exactly a match

for the strategy pattern.

And this is what I mean about Golden Handler syndrome.

If we'd been looking to fit the strategy pattern into here, that would be one thing.

But when you've got a problem and you go ahead and solve it with a sensible, object oriented approach,

you often find that you have stumbled across a pattern that you didn't realize.

So let's try and implement this, and we're going to factor out some of it, and I'm going to leave

some of it for you to do in a second.

So the first thing to do is I'm going to comment out this switch statement because we no longer need

that, but it will be a reference for what functionality we want to take elsewhere.

Current ability is currently pointing to this enum.

Let's switch that up.

So instead, and I'm going to do this all within the same file for simplicity's sake, but obviously

in reality, we would create different files here.

I'm going to create a public interface.

Of type, I.

Ability and this is just the C-sharp thing that we prefix interfaces with ability depending on the language

you're using, that might be different now.

Then we want to define a use method in here.

So that's just for sake of argument.

Say it's a void method use that takes no parameters.

And it's worth noting that you don't have to put public here.

In fact, it's an error to put a public in the interface because by definition, there's nothing private

in an interface.

Everything is public, so there's no point.

So then, instead of using the Enum, we're going to use our AI ability interface down here.

And that's going to be the current ability.

Obviously, we can't instantiate this to anything because we need some kind of concrete class.

So I'm going to go ahead and create a public class called rage ability that's going to inherit from

my ability.

In fact, not inheriting anything.

It is implementing AI ability and for it to properly implement liability.

It needs to have a use method so you can automatically do this with interface.

By doing control dots and hitting implement interface.

You can see it goes ahead and creates a public void use method that matches the signature in the interface.

So now we've got a rage ability.

We can use it anywhere where we take an AI ability type.

So we have this AI ability, current ability field.

I could go ahead and do new rage ability like so and that's going to give it an initial value then over.

We want to actually put some ability into that rage.

So I'm going to take this debug statement that we were previously using.

Cut it out here and put that into the use method.

So now that rage ability can be simply substituted in to our current ability and whenever we call usability,

we're going to do current ability, dot use like so.

And you may want to wrap this with some checks to see whether the ability is actually set to null because

if it's set to null, obviously there's no no implementation for use and it will cause an error depending

on whether you can ever have a situation where there is no ability enabled in your ability runner.

So there's a challenge to you.

I want you to go ahead and implement an AI ability class subclass for Ray, for Fiable now and for he'll

pretty much following in the steps that we used for the rage, ability pause video and a half ago.

OK, welcome back.

So this should be reasonably straightforward, almost a copy and paste job.

We're going to have a public class called Heal Ability, which basically implements the liability interface

again.

It's going to we can use control to go ahead and implement that interface automatically for us.

We can take the debug log for heal and stick it in use and then we can rinse and repeat for public class.

And this time we wanted, what's the other one?

I have the fire ball ability and the fire ball ability could also implement the eye ability.

In fact, it must, and that we can put the different code.

Now on this very simplistic example, it doesn't seem like we've necessarily gained very much.

But what's useful to know is that we one thing we could do with ability is we could pass in the ability

runa or we could pass in the current game object or anything that could link these abilities back to

the world.

So in Unity, for example, the game object might be very useful.

So with in use, we could pass the game object should be the current game object like so.

Now, obviously, this has gone ahead and changed the signature for all the classes.

So that's going to cause a compile error so we can go through and pass that game object in or just go

and change the code so that it has that signature on all of the abilities.

And we can pass in the current game object in usability so we can just passing game object like so.

So this means that these classes are now linked back to the world.

So if you wanted to launch particle effects and play sounds and all that sort of stuff, we can do that

we've got a place to spawn stuff.

We've got a reference to our world.

And now you can see that we could have very complicated functionality going on within each of these

classes.

And if we need to change anything about the fire ball ability, we only need to do it there.

We don't need to go and change this ability runner.

In fact, the ability to run a stay is very, very simple.

One more important thing to note here is that because we're only implementing an interface, we actually

have the ability to have these abilities be anything we like.

So at the moment, they are pure C-sharp classes, but the rage ability could actually be a mono behavior

like so and we could have the heel ability be a scriptural object, and that opens up a whole world

of possibilities.

That means the rage ability could be a prefab.

The heal ability could be a spiritual object.

And as long as you have a way of injecting that into your ability runner, as long as you maybe have

an array of sterilized fields or whatever goes, setting that ability is able to deal with this, then

you could do this in a number of ways, and it doesn't matter what they inherit from.

It doesn't matter how they do the job as long as they implement, not you.

The eye ability, that ability to use the ability, then they can be anything you want them to be,

and that can be immensely valuable.

If you want a configurable ability system, you might make your ability, scriptural objects, mono

behaviors or pure C-sharp classes, whatever you want.

If you're interested in this sort of stuff, then the RPG series on a special abilities.

The last episode in that series is all about creating ability systems, and we go into much more depth,

obviously, that I can do here in how to implement that sort of thing.

But for now, in the next lecture, we're going to go into some more depth on this mini ability system

into how we can use a different design pattern to make this even more flexible.

I'll see you that.