Using the Gameplay Ability System | Unreal Fest Europe 2019 | Unreal Engine

Using the Gameplay Ability System | Unreal Fest Europe 2019 | Unreal Engine

>>Matt Edmonds: Hi, everybody, and welcome
to the Gameplay Ability System. I am Matt Edmonds, speaker.
A bit more about myself and the contributors
in just a minute here. But first, a little bit about
where we are from, Splash Damage. Our studio was founded
by these three once young men. That is Richard,
Paul, and Arnout, respectively. These were the founders
of the studio. Obviously they are back
at Quakecon 2000, full of life and energy,
as we all were back then. This is our awesome studio
and building in Bromley, Southeast London,
on one of London’s many, many sunny days —
plenty of sunny days. For those who know Seattle back in the States
or Hamburg in Germany, those were the two places
I was before this. You may think I have a secret
love for gray skies and clouds, but they are all lovely cities,
like Prague is as well. Quickly on that point, I have been dying to ask
this this whole convention. Who, if anyone, is actually
from or works here in Prague? Is anyone out there?
Yes, great. Find me afterwards. We need recommendations
for restaurants. Thank you guys, I am glad to
see there are some natives here. But yeah, it is a great place, and London has been very nice
to me since I have been there. I will not talk you through
all of this; you guys can see it
as it scrolls by. But this is a lot of the
background of Splash Damage. These guys are huge fans
of these kinds of properties, and obviously making our own
games internally when we can, which is going to bring you
to the parts here, where myself
and the contributors all came to this talk from, are these unannounced
original IPs. Unfortunately,
I cannot really talk to you or show you directly, of course,
what we are working on. We are all used to it. But again, working with Gears,
as they currently are, and the recently announced Master Chief collection
for PC. A lot of exciting stuff there,
all Unreal, though. Every project in the studio is using Unreal
to one extent or other. Let me move past that here,
about us, myself. I stamped over my own title
with the logo, but I am Matt Edmonds,
of course, again, over 19 years now in AAA games. The younger people there,
watch out. It can go very fast
in this industry. The better part of half of that
has been in Unreal, and the better part
of that half in UE4, for the last five years
since it launched. Right before starting at Splash,
I wrote and published with Packt Mastering Game Development
with Unreal Engine 4, Second Edition.
Since then, of course, have been a technical
lead there with the teams. Again, I am not sure why
my logos are all out of place, but one of our internal teams benefitted from
Alejandro and Raghav, this tech designer
and programming pair who did some of the slides
I will present here today. Then Alberto, another one
of our great tech designers, and Alvaro Sanchez,
who is here somewhere, worked with me on one of
our other internal projects. Again, this talk is
basically a distillation to give you guys essentially
a concentrated dose of what we did as four talks, three hours
with about an hour of kind of Q and A internally afterwards,
when we realized that these two independent teams
came to the same conclusion — we should be using the Gameplay
Ability System, or GAS. We are using it
in a little bit different ways, we wanted to do
some knowledge share, and then the next thing
you know, I found myself roped
into putting it all together to talk to you guys here
at Unreal Fest. Just quickly, for my benefit,
again, who has used
the Gameplay Ability System, or is actively using it? Good amount of you. Okay.
Then some of this will probably be review
in this first part, but the one thing I would
encourage you to take away is the kind of benefits and the arguments that I will
make in the second half. These will help, I think,
anybody to evangelize this to producers,
financial groups, whatever. Producers love
pulling in a schedule, financing loves
pulling in budgets If you need to make
that argument and you are having a bit
of difficulty selling this, even internally, some teams
do not want to learn this. They have an easier way, they think,
of doing these things. I will try to help you with
that part in the second half. First half, though,
let us quickly jam through, getting you up to speed with what GAS is,
and what it does. We will go through
some basic concepts, kind of show you guys the ropes
with a quick Heal Ability. Then some advanced tips
and things to consider that this particular team
came up with, as well as a few references,
again, for those just getting started; you will want to grab this slide
later and check out those links, just to get some good head
start on the basics. Then — glossed over that one —
then sort of my contribution, in a lot of ways,
is onto the value of using it, and comparing it
to your other options. What is GAS? An end-to-end system
for programmers and designers, making it gameplay. There are a couple of things
to unpack there, so give me a second here. Really, the first is that
to get the most out of it, to fully and properly utilize
it, you are going to need
to write some code. You can use some pieces of it. There are some parts
that you can do Blueprint only, but if you do that,
you are really not getting the full benefit
out of the system; you are just kind of taking
advantage of, again, some of the Blueprint
implementation. In addition,
you are going to want to find, what is that balance
between working with a designer, working with a programmer, how do we find
what works for us, especially everyone’s project
is going to be different. GAS is also very easy
to prototype with, once you do understand it. You can quickly
do a lot with it, once you are proficient,
and that is a good thing. GAS is network-ready
out of the box. It is built
for multiplayer games. Most of the situations
you can think of that you might have
had to handle in the past. We will talk about
that a bit more. It is pretty well built-in
to the concept to handle it. Again, it is easy for big teams
to work on. You are not working in
one megalithic Blueprint, or something like that.
Obviously we can merge code, but that means that you are only
doing all of this work in code. As it is,
it is pretty well-distributed, you can work on
in individual pieces. Different people can check
these things out, check them in. You can build broad very quickly,
very easily. Some concepts: First thing
you are going to need to get to know is the Gameplay
Ability System Component. Again, one important thing
to remember from this, you can only add this guy
from C++ right now. If you go looking for it
in a Blueprint to add it as a child component, you are going to find
a couple of related things, but not this guy. This is the key to using it
on your Actors. The Gameplay Ability.
This is the logic of a gameplay mechanic. But again, as it was stated here
in this slide for me, everything can be
a Gameplay Ability. A little broad there,
but the point is, if you can think of something
you want to do in gameplay, across almost every game
that I imagine everyone out here is sitting there could think of
that they are going to work on, likely,
almost certainly, you can do it through
the Gameplay Ability System, and I will try to show you
why you probably should. Gameplay Effects. These are
what your Gameplay Ability sort of does to alter the World, make things happen
in that World. You can think of them
like a Data Asset, you are setting them up,
you are firing them off, you are letting them
do their job. Gameplay Tags. These are used
all over the place. Again, they are similar
to Actor Tags. I am sure everyone
that has probably not used GAS yet has probably seen it,
or at least utilized these. Again, we can handle
the different abilities, and how they interact
with each other. We will go into this
a bit more in the next section; I have got what I think is
a pretty cool summary of these concepts too, there. Attributes. Again,
just think health, damage, am I stunned?
Whatever happens to be going on. These are modified
by those effects. Gameplay cues are
what you are going to use for your visuals, your audio. Again, we will show
a quick example of triggering one of those off,
too, or how those are mapped,
actually. Here in our Heal Ability, again, you are adding
an attribute here in code. Next macro, obviously,
that you can see is just giving us
some nice getters and setters, and then adding it
to that actual Actor. Once again,
you need to do it in code. But once you have actually
added it in code, the good news is,
you can kind of pass it off and let,
hopefully, a designer — ours are usually
technical designers — start working with that ability,
then, on the Blueprint side, which is coming up. Here is a very simple ability,
which is this deal over time. We will get into the details
of it in just a second here, in the next slide or two. But what this thing is doing,
if you can see, this is the actual Blueprint
event graph of the ability. You make a Gameplay Ability,
Editor side, go into its event graph. You have got
this activate ability. That activation
can be associated with an input directly,
so you can actually just, again, map those
when you make the ability, or you can trigger it off
of anything else. My example always is like,
if you respawn, you get a 10 second
invulnerability. You have an XP boost
for 30 seconds and a speed buff for some time. You can also trigger
all of these in one simple way. Right here we are
at the activate part, but on the Character, with the component,
you can simply say, activate all of the abilities
with the tag “Player.respawn.” All of those will
immediately fire for you, the system handles it
automatically. You can also activate abilities
individually by the Class, which is very similar to what is
going on here with this effect. When this ability fires,
it is firing off one effect from its Class
on its target, then it ends. This is about as simple
of an actual ability as you are
probably going to see. But let us check out, though,
what that effect is doing. This is kind of where
the magic happens. At the top here, you can see,
okay, we have got a duration that can be instant, infinite,
or an actual duration. In this case
we picked a duration, if you can read that. It is a pretty big screen,
I hope you guys can read it. We said, let this thing last
for three seconds. Then what is it doing? It has got
a modifier down there, and that modifier
is going to add to health 0.2, along with a curve table
that sort of defines what, again,
these kind of values map to, adding health
over that 3 seconds. The modifiers, though — and you are going to see this
in a lot of places, and I am going to reference
it quite a bit in the next minute or so — you have got the tags,
in this case Requires Tags, Ignore Tags. Require Tags,
in this case, is on the Source. I am the one
producing this effect. If I do not have all
the required tags on myself, it fails,
the effect does not happen. If I have any
of the ignore tags, the effect fails,
it does not happen. Similarly, you can do the exact
same thing for the target. If it requires having
certain tags, if those are not there,
the effect does not do anything. If it has got
any of the ignore tags, effect does not do anything. You can really gate
these things, again, based on immunities,
and again if you want to block stacking,
and all sorts of things, it is definitely
all ready to go. But next one here, there is
a really important section on your effects for, again, managing all
of these different tags. Just to make sure
I do not forget anything, the granted tags —
actually, the first ones here, gameplay tags,
are those of the effect. This gameplay effect has tags
associated with it, so obviously,
you can imagine something like, there is an ability
that blocks healing; if somebody throws that on you, you have got an effect running
that is healing — I am sorry, then someone tries
to put an effect with healing on you,
it is not going to happen. Again, you can gate
all of that behavior. But really, this one —
getting ahead of myself — this one is to say,
what tags do I associate with? Spoilers: If we jump
ahead to the very bottom line,
there is the Remove Gameplay Effects
With Tags — that is a way, of course, of saying,
when this effect happens, everybody with the things I say
I should remove, I clear off. Again, buffs, or debuffs,
or whatever. There is all kinds of uses
of these in different types of games. But going back through them
in order, the granted tags are — these are tags that I put onto
whoever I am affecting. While I am affecting
this Actor, you gain these tags. What else have we got? There are the
ongoing tag requirements. Similarly, if you have to have
one of these tags, or you must not have one of
the ignore tags, if any of those breaks,
the way to consider this one is that
it will not remove your effect, it is just going to disable it. Your effect stops
doing anything, having any effect — no pun intended —
on your Actor, if one of these ongoing
tag requirements blocks it. But it remains on there. If that tag then disappears,
it, once again, will continue
affecting as normal. Application tag
requirements — that is this effect,
when I am applied, if I require things on
who I am applied to, once again, check. Or again,
if I am supposed to be ignored, if other tags are on me, check all of those
when I am applied, and fail if any of those are set
for this entire effect. You have got the ones for
individual modifiers up above, and you can add
a whole bunch of modifiers. These ones are for
the entire effect itself, so you have got
a lot of control, as long as you are willing
to take the time, learn how all this works. Our cue —
this is another one where, again,
if you are looking at this, at least it is big enough that you guys
can kind of read it and see a little bit about
what is going on there. The Editor,
you will find under Windows, in the Gameplay Cue Editor —
one thing I did not mention that I really should
have off of the top — all of this is made available
if you go into your plugins, go find Gameplay Abilities —
click the checkbox — viola. It has been experimental
for about a year. But if you have
played certain games, like Paragon or Fortnite — you might have heard of it.
They are using this. They are using this internally
everywhere they can, Epic is. When they found out
we were using it too, just because we kind of
came to our own conclusions, that is part of the reason I am standing here
in front of you guys right now. But this Editor
becomes available once the plugin is installed,
just from, again, Window, go find that
Gameplay Cue Editor. What you are doing here is associating tags
with these handlers. Again, it is just more,
basically, Blueprints that you can do
what you need to do in there. But this is where you will add,
again, all of your visual effects,
all of your audio, and as you can kind of see here, you can kind of specify that as,
this happens when it is applied, this is ongoing while
it is on me, while active. Or here is something specific I want to do
when I am actually removed. Again, all of your visuals
and audio are here. There only kind of problem —
and there is a bullet point coming up about this — is, again, it is all in this
sort of flat list, which is not the easiest thing once you scale up
and get a lot of these. But it works.
It does what you need it to do. Some tips from the guys: you can handle cooldowns
very easily through tags. Again,
read that out to your UI. Just say, hey, this ability
is on cooldown for six seconds, and tick down your UI,
like you guys would all expect. You could set immunity,
like I said, while this is active on this guy
they cannot be stunned, or they cannot be healed,
or all those different things you would expect
from MOBAs and MMOs, and lots of these
types of games. But also again, works perfectly
good for shooters where, like I said,
soon as you respawn, do not let people
spawn camp you, just give them
a three second immunity so you have a chance
to go find some cover. Gameplay effects can be
stacked as well. One point I like
to point out is, you can also prevent
stacking with this. You could say anytime
a healing ability is added to somebody, it removes
all other heal tagged abilities, so you only ever have
one of them active. But again, if you like,
you can, of course, add as many as you want. Gameplay tasks,
which we will go into in the next section
a little bit more, do asynchronous work for you. Get ready for that, there is
definitely a way you can say, go turn on something and get back to me
in the Blueprint side, whenever this finishes.
If you do get some complicated
attribute calculations, you can always override
this in code. They give you the option,
which is always nice. Now, this is a theme
that will keep coming up, and hopefully I explain it well. If not,
anybody just come find me, and I will do my best to say, here are
our experiences with it, for those that have not been
already through this. There is a considerable
learning curve, especially, again,
content side — a lot of designers are not used
to working like this, per Se. Any of us can probably,
right now, that are doing the job
making Gameplay know a way
we can get stuff into a game. We all have some tools
and abilities to get stuff in there.
The trick is here that you are going to
have to invest, and say, okay, how did they set
the Gameplay Ability System up? How do all of these different
things interact? How does this scale when I have
hundreds of abilities, and they are all putting
different tags on people? What happens when one of them
does not work the way I expect? There are a lot of things that
you are going to have to manage and internally take in.
But hopefully, I make the point by the end here
that it is worth it. Speaking of,
there are lots of files. As you get
all of these effects, get all of these attributes,
get all of these different pieces all working together,
it can get easy to get lost. You are working
in one single ability, you think you have got it
all figured out. Something goes wrong, and you are, like, oh God,
where was that other effect? Or, oh, it is not reacting well
with this one that I set up, that you did not expect them
to have a conflict, but again, because of the tags
you set up or something — they do.
There is a bit overhead there. But to me, that is going to
happen in any game where you have dozens or
hundreds of abilities like this. The gameplay cue,
as I pointed out I think already,
is a little bit rough. But again, it works.
It gets the job done. Communication between
GAS and non-GAS systems is generally one way. That is the best way
I can put it. GAS is perfectly happy
to kind of start things, listen for things, wait for things, tell you
when something has happened. But if you are going
to try to say, oh, is GAS running?
Like, is there an ability? Oh, I want to see that ability, and I want to inject
that this should change — nah, just do not.
You are not doing yourself any favors
to try to dig in like that. Again, here are these
references that — I will give a second here
for pictures, of course, but naturally,
these slides will get posted, so you can hopefully get
a less shaky cam version of this after today.
Okay. Now we will change
gears a bit. Again, I am going to compare
with alternatives so that you guys, whatever project
you are working on, whatever studio you are at, you can make the right decision
for you, I hope,
based on some of our experiences that I can share here.
First thing, though, is again, a practical real-world
example of, what did we do
where we could see it one way, see it the other way? Then in this case,
that is a reloadability. I will walk you through it
as if we did not use GAS, here is how we would do it, and here is basically
how anybody would do it, as far as I can tell
at kind of a high level. Then we will say, okay,
now with GAS, and let us just break down
what happened between the two, real quick. Then here is the part
with cost-benefit analysis, which sounds
like producer speak, but it is not boring,
I promise. This is sort of my most
direct contribution to this, the slides I actually had to put
together myself from scratch, instead of sort of absorbing
and modifying to share out here
in this condensed form. But we will compare
my experiences working on a couple
of other AAA games where we did
this ourselves, and what did I learn that hopefully
maybe you do not have to. We will do
a little bit of wrap-up, then everybody can go get
some coffee for the last afternoon sessions. Without GAS,
what would you typically do when you are starting?
You are waiting for an input, you get an input-activated event
somewhere, your Character,
whoever is doing this, and that triggers
your set of logic. But first, of course,
you are going to have to say, can I do this on the client? Your client is saying,
do I have the ammo? Am I doing something else
important? Does this make sense? Then you are also going to have
to figure out at this stage, who is responsible for that?
Do you want gameplay programmers doing all this stuff
where something — you know, again, we are trying
to do a Gameplay Ability, for lack of a better word, we are trying to do
something in the game. Who is responsible for saying,
yep, we can do it, or no. Again, do you expose this
to designers? Do you put it in Blueprints?
Who is tagging this? Somebody has got
to be responsible. Once you decide on the client,
yep, we are good to go. You are going to have to send
something to your server in a multiplayer game. Hey, by the way,
I am doing this thing. Change the State of the game for
everybody else that is playing. You can send an RPC. Then you either wait
for a response, which none of us do because
all of us hate lag in games; normally you just proceed
assuming it is going to work, and then you deal with it
if it does not. But that is really the crux
of this first thing we will get to at the end. Again, if you happen
to be firing at the moment, somebody tries
to trigger a reload, still going to have to wait
for that animation to finish. Again, there is a number of ways
you can gate on this. Pick yours. But then, of course, once you
actually start the reload, you are going to have to prevent
firing at that point, so again, they do not interrupt
or so something they are not allowed to
in the game. You just set a flag,
or do whatever works for you. Play the animation montage —
you know, we are doing our thing,
getting our ammo put in. Then either you are going
to need a call-back, or a timer, or you wait a certain
amount of time, whatever. Again,
your preferred method is — I usually actually do like
to set timers. I am a little paranoid
about animation events, especially if you put them
right at the very end. I have just had
too many years with Unreal where you play
through the animation. Every once in a while,
it seems like it just misses that animation event at
the very end of the animation. If you are going
to use animation events, pull it in a bit. Just a little piece
of advice there. Whatever works for you, guys,
though, you say, okay, at this point,
in this bit of gameplay, we are actually popping the ammo
into the gun, it is officially reloaded,
no going back. This gameplay change
has happened. Again, now you need to actually
wait for that animation itself to finish, because whatever else you do
after the counter increases and whatever, now you are back
to some animation State — same kind of thing. Re-enable your firing
on the client, you know,
allowed to shoot again. Here is the thing, though.
Again, everybody, probably, who has worked on
a multiplayer game like this has probably dealt
with this scenario. What happens
when you told the server, hey, the client looks good,
I am going to reload now, okay? Wait a few hundred milliseconds,
whatever, the server comes back —
it is, like, no, no no no no. If you are looking at what I am
seeing, you cannot reload. [Sighs] The server is going to say,
no, I have rejected this, I am not going to do it, and your State
is not going to change. Now it is all up to you,
on your client’s side, to figure out,
what does that mean? Okay, great. It is a pain. Again, everybody can do it
in different ways, but when that stage fails,
the red block, it is annoying. Do we wait
before you actually do it, make any visual changes, again, actually incrementing
your counter to hear back from the server?
How long do you wait? What if you do not hear back
from the server? Uh-oh. Do you rewind and rubber-band,
and we all love this in games where
you think you are doing a thing, and then all of a sudden
you find out you are about a half
a second earlier, because you did not
do that thing. It feels horrible as a player.
Not my favorite. Again, what if you try to —
you are going to have to handle what happens
if you try to start shooting while you are
in the middle of a reload. What happens
if you try to reload when you are
in the middle of a reload? You know, it is all on you to handle
all of those edge cases that there are probably
a dozen more that
are not going to make that list. Let us try this again
with GAS, and just see what it gives us. First, you can automatically
and intrinsically associate the reload with an input;
you just build the ability, and you say,
when this input happens, you execute your ability.
That is nice. Again,
that is all done for you. A good way to think
about tags is, think of them like conditions, most of the way
that we use them. You can use them
for all kinds of other things, but that is really the easiest,
most general case is, while I am doing this,
do not allow me to do this. When I am doing that,
do not do this. If I am not doing this,
also do not allow me to do that. Again, they are great for gating all of these things
in one place. You can kind of look at them
and see, if any of these is happening, do not let those
other things happen. Also, if you need to do
something really specific, you can always override
CanActivateAbility. It is good to know, too.
It is in there. Now what happens when we want,
again, from the client’s side, once again, say yep, it looks like we should
be able to do a reload. Create a prediction key. These things, again,
are built into the system, they are there to save you
from all of the problems I was just talking about. Send that PK to the server
associated with this ability. Say, by the way, server,
here is my PK, here is the thing
I am trying to do. Let me know what happens. The server will activate
the ability locally with its simulation version,
your Actor, and see how it goes. Server can come back to you
and say, yep, I have caught up
and it all looks good. Or it can say,
no, I tried to do this, and for whatever reason
on my server State, this ain’t gonna happen. Again, there is plenty of little
output things in Blueprint, which you can use then
to actually interrupt this. Handle it however you want.
But in this case, one thing we are doing
that we are doing before, if we are in the middle
of shooting, how do we wait? Well, let us just set
one of these ability tasks in there that says, hang out here until
this ability tag is removed. Because oh, hey,
we are in the middle of firing? Great. Okay, we will wait
until firing tag gets off, then continue on
and begin the animation montage and start the actual reload. Here, we are using a gameplay
effect and applying a tag,
of course, that is — actually, in this case,
we are firing — sorry to inhibit firing
is what I mean. Going forward,
no more shooting. You do that, of course, as soon as you
start this reload. Again, also associate
all of this with your prediction key. It is very straightforward
to actually do in the system. Animation, yeah, is then
played by another task. Another nice
asynchronous task, we just say, okay, kick off this montage.
Tell me when it is done. Or, not even tell me
when it is done. This one actually just
lets you play, because we are going to wait
for an event. With another ability task which
just sits there and spins until, ah, by the way,
I just found out that from, again, sorry,
animation trigger that, by the way, you are now
reloading, or reloaded. Change your ammo using Change
the Attribute, of course
using another gameplay effect. If you guys, once again, hopefully this
is big enough you can see. Here we are just saying,
what is my current ammo? Set it up to 30.
There you go. Again, the animation is still
being played by that task, and it will tell you,
by the way, I am done, or I got interrupted, or — yeah, again, it handles
all the cases there for you. If you need to do something
specific, again, play a hit reaction, force yourself back
into a base State, sort of an idle, or whatever —
it is all there for you. But normally, of course, again,
you are just going to finish your animation montage
and move on. Again, re-enabling firing is
going to happen also right here, because we are taking one stack
of inhibited firing off when we finish reloading. That automatically
lets you start shooting again. Again, let us compare
our two graphs here. Once again, we are going along,
we send off the prediction key. We are still doing some things
on the client side, maybe this montage, etc. Oh no, we rejected that key. Well, on the server side,
it ends. You are not going to get
your reload done. It comes back
and tells you with events — with the reply
from the prediction key, by the way, nope, did not work. Automatically removes
all of the effects and prevents all of that
on the client. It just basically
cleans itself up by default. If there are different things
that you want to do when that happens,
you can hook into that, but it is pretty well
handled out of the box. Again, with GAS, overall
structure looks kind of similar. Of course you are doing, again,
the same things, you are trying to reload, you are trying
to play an animation, trying to make it look
right on the client, and make sure it is legal
with the server. But with GAS, again,
this is a bit more declarative. For those of you that worked with kind
of declarative systems, you will probably know
what I am talking about. If you do not,
just kind of summarize — you set up
what you expect to happen; you set up everything the way
you think it ought to go. You push it off to the system, and then you just let it do
what it does. The good news is, again, Epic is using this on shipped
titles, others are using it, you have got
the support of the community, you have got tools,
you have got people you can ask. It is a lot better
than trying to figure all this stuff out on your own,
if something ever goes wrong. If you ever find a bug, make a pull request,
get it to the rest of us. Here is my summary
of all of these things that, hopefully,
is a bit helpful for you guys, again, new to it
to wrap your heads around it. Tags for me are the if. Attributes here are the what —
what is changing? What is the gameplay effect that is getting altered
through this process? The effects themselves
are essentially your how. How is this changing? Oh, by this amount,
at this time. The tasks,
the asynchronous tasks that you can set up
are sort of the when. Let this go by, seven tenths
of a second later — click — you actually have reloaded. The abilities themselves
are the why. What said I should do this?
As I put it, If, what, how, when, why —
all in a row. Hopefully that kind of
makes it clear. These are how you use
these things. They are all there.
They work. The system is really robust,
it is pretty darned powerful. But it does look like — if you looked at that graph
that I showed you — like there is just
more stuff going on. But really, again,
it is more options and safety. They are trying to keep
a server, multiplayer-based, multiplayer game
from having the problems that we have all
had doing this ourselves. I know I have. Interruptions,
server rejections, stacking, or not, all of these things
are built in. They are there for you. You can just explore a bit,
you will find them. They work. If you build one ability,
the first method, you get one ability. If you take the time
and actually learn GAS, you have got a lifetime
of building abilities. It is the give a fish,
teach a fish thing. But it really is true. You can carry this forward
from your own projects internally to new projects, or, God forbid any of you
ever move to a different studio, you can take it there
and make the argument, we should be using this,
and here is why, because you are
familiar with it, you have seen what it can do. Real quick now,
I am going to jam through, let us compare these
to the real-world cases in my life,
and why I am convinced. Hopefully you guys will be too,
but make up your own minds. Now, GAS versus not. The two examples that I am
going to walk you guys through here,
from my background, was Guardians
of Middle Earth in 2010, 2011, WB came to us and said, “Hey, we need a game
for The Hobbit movie. Can you guys — you are pitching
MOBA in Lord of the Rings, can you jam that out in
Monolith’s tech in 18 months?” The three of us were,
like, yes. Just give us a team, we can find
a way to make it happen, and we did. But that was the first person
in Shooter Engine, and I was the one responsible for writing all
of this gameplay side. Gates of Epica was what I was
working on most recently before the book,
and coming to Splash Damage, and was meant to be a
AAA experience brought through UE4
to players on mobile, launched in Europe for about
a year before they shut it down, as InnoGames went back
to strategy games. If you try to find it now,
you will not really be able to. But you can find some videos. We did a lot of cool stuff,
but it was a lot of effort. Let us compare this
to the internal work our two teams were doing,
and the pace they are on for actually getting comparable
work done on a AAA game. There is a bunch of little
numbers over here behind me. You can trust my math. The thing I am
going to focus on, right here, when we are making a MOBA
in Lord of the Rings. We pitched it
as it is League of Legends in Lord of the Rings. They are, like,
“Great, go do it!” We took their first person
Shooter Engine and said, okay, we have got to figure out
how to make this happen. There were a lot of challenges, I could spend a lot of time
talking about this one. But we did get it out on time,
Xbox and PlayStation, and later some other guys
ported it to PC. The two things to think about, I am going to be talking about
the unique Character abilities, sort of the unique
Gameplay Abilities, both player and PCs,
in this case was 88. But all of these things
had to be modified by hundreds of potions,
power-ups, boosts, all of that fun stuff. All of these things had to be
accounted for and tracked as, again,
buffs that stack, and all those fun
things in a mobile. I totally forgot to actually
go over the numbers. When you see P/D, that is Programmer
and Design times. I usually, again, since I do not
have exact numbers, but I did live all of this,
I always give estimates and a low
and a high, confident that somewhere in
the middle is the actual truth. Hopefully in here, you guys can see that
prototyping was not too bad, especially for me.
I just sort of banged this out, and we had some style sheet
type things in Monolith Editor. I just said, okay,
here are some conditions, and then here are some effects.
Here is a timer delay, and here is a next condition
and next effect. By the way, play this animation
when you do it. I set that up relatively
quickly, got it to work. But getting a designer up
to speed on it took some time. Had a great designer
on that project who did a ton of work
and was amazing. But again, you can see how much
time we spent debugging, all the rest of it. The number I am
going to emphasize here, and going forward,
you are probably already seeing where this is going.
How much of that effort were we able to
take into future projects? None.
It is all in that game, and then it has gotten
kind of thrown away ever since. Gates, again, we wanted a
Diablo-style game with the big, five-zone, single-player
experience, asynchronous, but partially synchronous,
boss battles, with raid-style boss battles where
you could join all your friends. You could take on this boss
for a day-long fight, and use more unique abilities. Again, you will have to trust me
on those numbers. 162 abilities between the NPCs,
the unique players, and the bosses that we actually
put into that game. The one number — I do not have
a laser pointer thing — but the one number I would
point out with my finger here, that 52 to 56 is pretty tight, and I know that because
I pitched originally something similar to what I did
in Guardians of Middle Earth. But it was rejected because
we did not have any designers that could actually use a tool that I would provide them
to go broad. We just did not have
designer bandwidth. One of the guys on my team fell on this sword
and volunteered, he said, “I bet I could just do this
with Blueprints and maybe some C++,
switching back and forth. Design will just tell me
what they want, I will code it up, basically, then we will do these,
however many we need.” We needed 162. It was a year of his life,
doing nothing but this. As you could probably guess, he was a little burnt out
by the end of that, and never wants to do
anything like this again. I told him up front, I said, “If you are really sure,
go for it. But know what you are
committing yourself to, because it is just
a huge amount of work.” That was literally
all he got to work on for a solid year.
Poor guy. Thanks Andre! What reuse do we get
out of that? Well, there is
a little asterisk, as you can see over there. Really, we learned just how
much work this really does take if you are going to do it
yourself with gating this stuff, C++,
back and forth to Blueprint. We are going to have
to put some delays in, we are going to have
to pass control of who is doing what in this flow, and take care of that
all over a network as well. What were we on track for,
for doing this in our GAS games? Again, I cannot really
specifically speak to what those were,
but there is a lot of action, and some co-op, and killing
different large things, or fighting — you know, again,
huge enemies and things — okay, cannot really
go into those details. But for a similarly-scoped —
I am just going to kind of split the difference
for sake of argument — we put in here
120 unique abilities. Again, any of those genres, I am happy to argue
with any of you guys that this probably
your best choice. If you are making
the small puzzle games with three mechanics, then just do it
however you want. But if you are getting up
into that 120 kind of number, you are probably going to want
to switch over and start learning this. The prototypes,
you are going to notice here, the prototype numbers
are a bit higher, and there is a bit of a range. It kind of depends on how
tech-savvy your designers are, how quickly your programmers
kind of pick up the concept of, I am sort of building
out the framework, then I am passing it off
to a designer. Then I am sort of building
out some framework, then passing it off
to a designer. You have got to get
a little bit of that setup done on a programming side, but once you are used
to this cadence, you can pass those off quickly. Designers can tweak everything
very quickly, iterate it very quickly,
into the game. Expect that, though, that you are
going to take some time to actually have to learn this
and start getting it right, figure out
what works for you guys. But as you probably can guess, those low-end
and high-end numbers that we are tracking
for scheduling are actually both pulled in — there is a summary of this
in the next slide. Look at that — you can take
whatever you did and learned, as well as the actual assets
from prototype into your production. From shipping a game
into the sequel — all of this stuff carries on,
as well as people debugging it, learning the tips and tricks. How do we figure out
when something went wrong? What do we do about it? Here is the big reveal. As you can see,
the low and high-end both pulled in quite a bit for us
on our schedules, when we were tracking these, compared to what I have done
in the past. There is a big of that
unpredictability, as you start to learn, like, how do we debug
when something goes wrong? You are going to have to learn
a couple of techniques of your own that,
again, help you guys figure out
where those problems are. It is, of course,
easy for multiple designers to be working on similar things and one stomps on the other’s
foot, but there you go. Ready for, again,
the big reveal: you will get to reuse this,
not just on this project, on your next project,
throughout your studio. You can start sharing it
like we did, take it forward. Like I said, inject it now.
The sooner, the better. You are going to, I think —
convince me if I am wrong — I think you are going to believe that that was
the right decision. Just a real quick wrap-up,
and like I said, we are hitting coffee,
I think, after that. But I will be around,
myself and Alvaro here. Look for me in the blue shirt. I am happy to answer questions,
deep-dive any of this. I have the original four talks
that we did internally as well, including, like,
a chaining melee attack, if you want to see
how that was implemented. We actually have videos
and animation that I could not put up here
on the big screen. But I am happy to share those
with you guys. GAS gives us this framework,
lets you go broad. It is great for that. The community, and obviously
the biggest ship title right now all are using it,
so you know it has got support. Do you have to use it?
Of course not. If something else
works better for you guys — obviously I am not here
to force you, to try to twist your arm. I am just telling you,
here are what our experiences, and hopefully you make
a similar decision, because the more people
using this, the better. Knowing its capabilities, again, allows you
to make those decisions. You can go to a producer. You can go pitch
this project internally. You can go pitch this project
to external publishers — whoever you have got to do —
and sell them on it. You can say,
we know how to do this, we can predict it is going to
take two gameplay programmers, two designers,
and in eight months we are going to have all
this gameplay that we are promising.
You will know that. Again, for me,
that is just huge. Again, it solves a lot
of problems that I, for one, would rather
not keep solving again — been there, done that.
Would rather let Epic do it. Thank you guys for that. One last bonus —
the GAS jokes never get old! You can use those forever. Thanks for watching. Like I said,
we are right at the time limit, but come find us. Talk to us! [Applause] ♫ Unreal logo music ♫

7 Replies to “Using the Gameplay Ability System | Unreal Fest Europe 2019 | Unreal Engine”

  1. For those who haven't seen it, someone from another studio also just gave a talk about how they integrate the GAS with AI. Lots of good info and they have a Github repo with some sample code:

  2. That was a really great overview. Although this doesn't really tell implementation of GAS, it provides you with everything you need to wrap your head around the concept and the Gameplay Ability System. Thanks for the great session.

Leave a Reply

Your email address will not be published. Required fields are marked *