When we talk about AI in games,
We're not really talking about artificial intelligence,
We're talking about decision trees.
Specifically, decision trees created for computer-controlled actors
that are there for one purpose, and one purpose only,
To make your game more engaging.
[INTRO]
So with that in mind, what actually makes for good game AI?
Game AI is really just a marketing term for NPC behavior.
And, as designers and programmers, when we're crafting behaviors for NPCs,
there's only three vectors that we're really looking to succeed on.
Is the player able to learn or intuit these behaviors?
Do the behaviors create interesting decisions for the player?
Is creating these behaviors an efficient use of resources;
are you getting enough bang for your buck?
So let's look at each of those and talk about what they really mean.
First,
How do you make NPC behavior learnable and intuitable for the player?
To answer that I first need to dispel one commonly held misconception.
Complex AI does not equal good AI.
Complexity is not interesting.
Or rather, complexity by itself is not interesting.
You'll often hear video game marketing talk about a game having "the most complex AI ever developed",
but that doesn't necessarily mean that it's better.
Or even GOOD.
I mean, if I came up to you and said, "Hey, check this out!"
"I have devised the most complex stairway ever built"
or
"This is the most complex set of instructions ever made for preparing microwave burritos",
does that mean that I have designed the best stairs or microwave burrito instructions?
It does not.
Those things are not necessarily going to do their jobs better, just because they are more complex.
And game AI is the same way,
especially if you want your AI to be learnable.
Learnable AI or NPC behaviour
is behaviour that the developers have crafted with the idea that the player will over time,
come to understand exactly how that NPC behaves.
The simplest example of this would be the enemies in 'Super Mario Bros.'
These creatures have almost no code happening under the hood.
All these Goombas and Koopas require to function is a single line of script that says,
"move left and if you collide with something, reverse direction"
But because they are so predictable, once the player learns how they work,
then the player will be able to make perfectly informed decisions around them.
Super Mario Bros. is interesting not because of how the enemies react to you,
but rather how you react to the enemies.
And as with all games with learnable NPC behavior,
part of the engagement and player progression is in slowly learning them more deeply.
When you first start playing Super Mario Bros.
You will almost immediately figure out that goombas move left,
which allows you to begin making decisions for how to deal with them right away.
Soon, you'll also learn that they will fall in pits if you let them.
And eventually, as you begin mastering the game, you'll get a sense for exactly how fast they move.
As you learn each of these elements,
your mastery over the game increases,
and your interactions with these enemies become more refined.
Now 'Shmups' represent a much more complex version of this
In most Sh'm'ups, like in SMB,
There's actually no decision tree running the AI.
The enemies don't change their behavior in reaction to what the player is doing,
but, the behaviors defining:
how enemies move, the patterns they shoot and when they shoot them
are FAR more complex than the behaviour of the Goomba.
These gains gear themselves towards players who revel in learning those patterns
and figuring out how that knowledge combines with the game's mechanics, to allow them to overcome every obstacle.
So that's Learnable AI.
Intuitable AI is different though.
Intuitable AI is actually responsive;
It has actual decision trees running under the hood.
The simplest example of this is "the enemy in an FPS that dives for cover when you throw a grenade"
This enemy won't ever dive for cover unless you do that.
It is responding to what you do.
Somewhere in the code, there is a line that says something like
"if (grenade is within damaging radius) && (cover is nearby) then
leap (behind (nearest cover))"
i'm sorry
The NPC is making a decision based on what you did.
But, because it's responsive, it won't always be 100% predictable.
Unlike the "Sh'm'up enemy" who constantly zips to the same place and does the same thing,
The "FPS soldier" may leap to a different cover depending on where they are when you throw the grenade.
And once they're at that cover point, well, all bets are off.
Now the enemy has gone somewhere that the designer could not have anticipated them being,
and if you had thrown that grenade ONE second sooner, they might have jumped somewhere else.
And if you hadn't thrown that grenade at all, well, who knows where they might have ended up.
This means that "the shooter NPC" needs a behavior tree
in order to adapt on the fly to whatever situation it ends up in.
Often these trees are as simple as,
"if (out of cover) then {run to (nearest cover)}
else if (in cover) then {pop-up every three seconds, shoot for one second, duck back in cover}
But the key to these behavior trees,
even if they end up involving more complex stuff like squad coordination behavior or flanking movements,
is that they need to be intuitable by the player.
Even though the player doesn't know exactly where the NPC is going to dive when they throw that grenade,
when they do see that NPC dive,
they should be able to understand what it's doing and why.
If they can intuit it, then they can respond and play around the NPC's actions.
And that is essential if your NPC is gonna meet the second requirement,
that it creates interesting decisions for the player.
Your NPC behavior not only has to be learnable or intuitable,
it also has to highlight the core of your game.
Is it there to allow the player to make heady strategic decisions?
Or to enable them to show off incredible feats of coordination and dexterity?
NPC behavior also has to take into account where in the game it's going to be featured.
The earlier in the game the enemy appears, the more room it has to give the player for error,
and the broader the player's options in addressing it have to be.
Later in the game, NPC behavior may serve to drive the player towards more interesting play styles or mechanics that they might have overlooked.
Overall though,
whenever you're creating a new behavior or a set of decisions for an NPC, you simply have to ask yourself,
How does this set up an opportunity for the player to make interesting decisions within the game?
Once you have learnable or intuitable behavior that is successfully creating interesting decisions,
then comes the Final, Fundamental Design Question™,
How can you get the most bang for your buck?
How can you deliver on these behaviors efficiently?
Don't use enormous decision trees when a basic script could get the job done just fine.
Don't try to model absolutely lifelike behavior, when something much simpler would be more engaging for your players.
Don't create one super complicated enemy behavior set, when you could be more easily creating two simpler enemies,
that would provide a wider range of options, and make the player feel like there was more variety to your game.
This is how all game development works, and the building behaviors is no exception.
Always ask yourself if the manpower and CPU resources required for the thing you're building could be better used elsewhere.
But for all of this, there's one thing that I've still not discussed,
and it relates to gaming AI's future.
So far we've talked about using NPC behaviors to increase the mechanical engagement of the player,
their engagement with the play of the game,
but we haven't talked about the next frontier,
How do we use AI to increase emotional or narrative engagement?
Fret not, this is something that James is deeply interested in
and something that he is actively working on in his consulting life.
If you folks are interested, let us know! We can definitely come back to this.
Until then, see you next week!
subscribe to extra credits, they make loads of videos like this one
subtitles by thomas holman-layne
E N D