Filtering damage

Creating a more complicated damage model is something you should always implement in the beginning of a game's development. You may not plan to need it, but when your design changes it's a good thing to have in place.

Why would we want this?
It may be that you want certain characters to respond to only particular damage types like fire, or high-velocity munitions. Or perhaps you want equipment to shield against a certain super-set of these types, like a flak vest that stops explosive damage.

The idea of this is relatively simple - you set up a system that enables a receiver to only take damage from the types that it is allowing. Whenever you create a character, you can specify what it is vulnerable or invulnerable to. When damage is sent, it carries with it the relevant information that allows this filtering.

The fundamental idea behind its implementation is that the designer is able to create damage types, such as explosive, blunt, fire, and sub-types such as grenade, bullet and so on. These are then processed by the engine and assigned to unique bitmasks for fast processing. You can then create weapons that deal this damage, triggers that watch for them (for example a destructible wall only vulnerable to explosive damage), and characters who can listen for these types and process them how you choose.

In an upcoming post I will outline the basic implementation of this system. Stay tuned!

How would we go about coding the memory marker?

In my experience the most important thing when coding this system in various forms is that your memory markers, in code and their references in script, must be nullable.

This provides us with a very quick and easy way of wiping these markers when they are no longer needed, or querying the null state to see if the agent has no memory of something - and therefore if we need to create it.

The first pass implementation of these markers simply has two rules:

1. You update the marker for a character to that character's location when it's been seen by an enemy.
2. You make the AI's logic - search routines and so on, act on this marker instead of the character

It's worth mentioning that each AI will need one of these markers for every character on an opposing team, and every object they must keep track of.

Because of this, it is useful to populate some kind of array with these markers.

Think too, about how you can sort this list by priority. When the AI loses track of a target they can grab the next marker in the list which may be an objective, or a pickup they passed.

When the list is empty, they fall back to their patrol state.

Memory markers

Memory is something that is often overlooked in combat games, more often than not when a character becomes aware of you in a combatative action game, they remain aware until dead. Sometimes they may run a countdown when they lose sight of the player and lapse back into their patrol state if that ends before they find them.

Neither of these techniques looks particularly intelligent. The AI either looks unreasonably aware of you, or unrealistically gullible, in that they go about their business after they've lost track of you for a few seconds.

A memory marker is a simple trick (The UE4 implementation of which can be seen here) that allows you to update and play with the enemies perception. It is a physical representation of where the enemy 'thinks' the player is.

In its simplest form, it has two simple rules:

• The AI use this marker for searches and targeting instead of the character
• The marker only updates to the players position when the player is in view of the AI

this gives you a number of behaviours for free- For example, the AI will look as if you have eluded them when you duck behind cover and they come to look for you there. Just from this minor change you now have a cat-and-mouse behaviour that can lead to some very interesting results.

It is also very extensible - in more complicated implementations (covered in future video tutorials) a list of these markers is maintained and acted upon. This lets us do things like have the AI notice a pickup when running after the player, and return to get it if they ever lose their target.

How would we script... The grenade-shooting moment from MGS5

https://youtu.be/tXf1xKiKKu0?t=20m35s

In one of the recent MGS5 gameplay videos, there is a moment where the protagonist throws a grenade, only to have their companion AI shoot it into a helicopter that was otherwise almost impossible to take down. It's the kind of over-the-top action we've come to expect from Hideo Kojima, but how would we implement something like this into one of our own games?

There are of course always an enormous amount of ways this can be done. Here, we'll look at just two:

1. As a script attached to the helicopter
2. As a more generic action available to the companion AI

The key here is to really start thinking about how we would structure the underlying code to give us the building blocks we would need to not only script this event, but many like it. Let's think about the steps involved.

As a script attached to the helicopter

We might want to attach this script to the helicopter if it's a non-generic action that can only occur when the helicopter is present.

1. First we would want a generic way of testing for certain objects based on proximity to other objects, in our case, the helicopter
2. We would then want a system that let us query by object type, so again for us, this would be the grendade
3. We would probably want to extend this to check to see who threw the grenade, and check for the player as the owner
4. Next we would want to check that the grenade was on the same side of the helicopter as our companion AI
5. The companion AI would then be sent a signal to shoot the grenade
6. Finally we would add the approprioate velocity to the grenade and destroy the Helicopter

With this piece of logic we could write an event that would happen naturally if the player ever ended up in this particular situation. More importantly though in writing generic functions to let us query for objects, owners, positions and so on, we give ourselves the ability to script more events like this, that are equally as unique, very quickly.

Maybe we could make it even more generic though. Let's take another approach.

As a more generic action available to the companion AI

In all honesty it might be a better idea to code this as a generic action that the companion AI possesses, so that they can use this on multiple types of enemies. This is now not then a scripting task, but it's still good to think about the steps involved.

Here we would probably want the AI to be constantly positioning in a way that is helpful for the player, again this will be something core to the way the AI is coded so is not really a scripting task. You can see in the demo that the AI jumps next to the player before jumping away, signposting her position so that they can better choose to use the action. Then, when a grenade is thrown, the AI will perform a cone check to see if the grenade is going to move in between her and an enemy, and if it does, shoot it towards them. This will give the AI the ability to shoot multiple objects at multiple enemies given the right positioning, and in doing so may result in some interesting opportunities for emergent gameplay.

In actual fact there is an extra step in the video - the player actually asks her to perform this action, but it's not really relevant to the core of the explanation.