Notes on the A.I.

Here’s some notes I was taking down while watching the behaviour tree video by Alex J. Champandard (part 1, part 2, and part 3).

Goals for the A.I.

  1. “Intelligent” enough to know how to preserve itself
  2. Compentent enough to finish goals assigned to it
    1. Adaptable to situations
      1. If it suddenly can’t do what is assigned to it, it should do some fallback action, perhaps wait until such time that it can do it again.
      2. If it can do multiple ways of achieving a goal assigned to it, it should look for the best way it can do it (HTN Planner)
    2. Fuzzy goals: give percentage as to how much attention it should give to each goal assigned to it (priority)
  3. Coordinate with allies to do joint operations (semaphores?)

Goals for the A.I. System

  1. Easy to use/understand (don’t we all want this)
  2. No need to bug the programmer every time: Once the system has been coded, let designers design behaviour without more coding (as much as possible). (How? By making the system composed of basic building blocks that can express up to the most complex ideas, like Lego, so the designer can use them in creative ways without asking the programmer to hard-code something all the time.)
  3. Easy to reuse:
    1. Reuse behaviour: Reference a (reusable) sub-behaviour within a behaviour.
    2. Use concept of cascading style sheets/inheritance: Reuse generic behaviours and just override for specific functionality. Can even use strategy pattern on lieu of this (override behaviours during runtime).
    3. Encourage creating small, modular, connectable behaviours.

A.I. Influence Maps

In order to help me more on the A.I., I’m trying to implement the technique of influence maps.

From aiGameDev:

Influence maps have been around since the very early days of game AI, tracing their history back to real-time strategy games over a decade ago. Since then, influence maps have become a cornerstone technique for game developers, and are even starting to become prevalent in first-person shooters as well (e.g. KILLZONE 2/3).


I’ve released my work on an MIT license. The git repository is here:

I’ll be working more on it as I go. Any expert help to guide me is appreciated.

More references:

A.I. Systems

My first try at an A.I. system was when I was making Death Zone Zero. I was inspired by the A.I. system in Dragon Age: Origins.

If you’re a programmer, one look at these screenshots should explain how the whole thing is set up.

To be clear about it, it works like one long if-then-else-if chain, but the important distinction is that you can add, remove, and change those if’s during runtime.

So its basically a list of conditions, with an action to do for each, when the corresponding condition is met.

You can also describe it as a priority list. It checks from the top first. If it found something to do at the top, the program won’t bother looking at the bottom conditions. Of course the program continually evaluates this long if-then-else-if chain (always starting from the top), so there is a chance the bottom entries can be triggered. It depends exactly on how lenient the conditions are.

Here is an example:

  1. Am I dying? Then I should escape from the enemy.
  2. (Assuming I’m not dying,) Is an enemy in attack range? Then I should retaliate.
  3. (Assuming I’m not dying and not being attacked,) Did I detect an enemy? Then I should pursue him.
  4. (Assuming I’m not dying, not attacked, & not seen an enemy) Then I have nothing to do, I’ll just wander/patrol the area.

That is basically the most common A.I. you’ll ever find in videogames. I’ll reword everything to make that clear:

  1. Am I losing? Then assume a defensive position.
  2. (Assuming I’m not losing,) Is an immediate threat found? Then do something about it.
  3. (Assuming I’m not losing and no immediate threats,) Am I seeing a potential threat on the horizon? Then take it into account.
  4. (Assuming I’m not losing, and no immediate or potential threats) Then improve myself and keep on guard.

You’ll notice each condition expects that the ones before it failed. This is essential in making it a priority list.

You’ll also notice the entries are ordered from most important to least. This is also needed to make sure the A.I. works as intended.

Building upon this, I had added the ability to add more than one condition for an action. The conditions would then be attached together in essentially AND operators. If one condition fails, the program won’t bother with the other conditions and move on to the next entry in the list.


What I had problems with back then, was how to make enemy A.I. do coordinated attacks (flanking, one distracts while the other attacks from the target’s blind spot), and to make an A.I. switch between different priority lists.

Swapping Priority Lists

Say the enemy can act stealthily if he wanted to. His abilities for stealth essentially mirror what he does while not in stealth: escape, attack, pursue, and patrol, but again, all as a stealthy variation. What I had been thinking then, is to add an action to make an A.I. switch to a different priority list if the situation calls for it.

Moving On

Then a lot of things happened and Death Zone Zero is currently on hold. Now that I am tackling A.I. systems again, I’m taking a pause and wondering how to do things again. I’ve heard about behaviour trees and how it’s very well suited for videogame A.I.

I ended up reading this #AltDevBlogADay article on behaviour trees, and chanced upon one of his references: the A.I. system in the PSN game, Swords and Soldiers (part 1, and part 2).

The more I read it, the more I realized, “This isn’t a behaviour tree, this is more like the priority list system I made up long ago”.

The A.I. system in Swords and Soldiers is very similar to the priority list system I made up long ago.

The nice thing about behaviour trees is you can create one that works exactly like a priority list.

The truth though, is that they can have a more sophisticated structure that potentially make them work a lot more “intelligently”. If the priority list is like an if-then-else chain, then the behaviour tree can add more, like a switch statement, nested if’s, and even loops. Behaviour trees are like a visual programming language but made for a more specific purpose (i.e. videogame artificial intelligence). Part of their charm is to make the design of A.I. a lot more accessible to non-programmers, the same way my priority list does.

The only problem is its a lot harder to understand. For that, I recommend the article I mentioned above.

There’s also this hour-long video about behaviour trees in An account is required, but subscription is free. You could, however, watch that same video for free, without registration, in this three-part series: part 1, part 2, and part 3.

Normal Map Problems in Blender

Normal map baking in Blender is very simple and straightforward but there are numerous pitfalls that are not apparent to the user that can make things broken.

No objects or images found to bake to

Generally speaking, if either of the high-poly object or the low-poly object you are baking to are set as not renderable, Blender can’t find it and thus, can’t bake anything. To make objects not renderable, there are many ways to do so:

  1. Set it as invisible from the Outliner
  2. Have either objects in a layer that isn’t set to be rendered. In the Render tab, there’s a section named “Layers”. That determines which layers will be rendered.

It doesn’t make sense to me at all that normal map baking has to depend on these things as if we’re rendering to a movie file.

The other possible reason is if the low-poly object doesn’t have an image assigned to it. From my experience you can just create a new image from Blender, assign it to the low-poly’s UVs, and you don’t even need to save it yet. That is enough to make normal map baking to work.

Overlapping UVs

Take care when baking into objects that have overlapping UVs. If you have a head whose UVs’ left side is mirrored to its right side, this can cause the baking to overlap as well.

Here, the objects have multiple copies, thus, it made sense for me to simply make them use the same UV space. I was baking the high-poly object you see in the bottommost copy of that object.

However, the normal map baking produced those lines you can see in the left side of the screenshot. Again, this is because the UVs are overlapping.

What I did, was to temporarily set aside the UVs of all the other copies of the object:

Then bake again. This will produce a clean result like the screenshot below. Then simply move the UVs back to their original positions.

Flipped Normal Maps

Things looked fine until I saw my object up close:

The left side of my character’s armor seems to be flipped from the right side. This is because in the normal map (shown in the right side), the UVs were split in half. And then the right half was rotated upside down (because I was saving space).

Here is how it looks like in Blender:

However, when you preview the normal map from Blender, it looks fine.

In the end, I was forced to remap the UV layout so there’d be as few seams as possible.

This resulted in having to reduce the size of my UVs to fit in the image, but so far, that’s the only way I see to fix it.

Rushing for the IGDA July Meetup

For the impending IGDA Manila July Meetup, I certainly won’t be able to rush my next immediate objective: enemy A.I.

So I’m spending the time doing some polishing here and there.

Here’s the soldier with normal maps (finally stopped being lazy about baking it):


It’s sitting at 11.5k triangles which I think is good, but I could probably shave off a few more without sacrificing much detail.

I’ll also add the really cool sounds that Raf had been making.


Gustave has joined your party!

3d artist, musician, and long time friend of mine, Rafael Urbina, expressed his desire to help make Victis a reality.

He’s also the inspiration for Gustave Musgrave, a key character in the story.

He sent me really awesome sounds one day and I was blown away that I am now officially including him in the team as sound/music guy.

I can’t embed sounds here in WordPress so until I get the time to incorporate them into the game, you’ll just have to trust me when I say the gunshot sounds are sweet.

W.U. 6: Melee Damaging

Check the video. The attacks now damage units. You’ll see the dummy red box has its health reduced when taking hits.

Its not quite visible in the video but I’ve also added swoosh trails on the weapon when attacking. Continue reading