Blog

Hi folks

Germain, our usual blogger, is out for tonight, so I will be writing the blog this week. This week was pretty much the same routine as the other weeks of the month. There is still no sign of our pterodactyl pet which escaped last week but we keep our hopes up. We spent most of the week either tweaking systems for the video or doing legal paperwork for our kickstarter. By the way, we suffered another delay in our big kickstarter registering quest. Our video will be ready any time now and we hope to have the legal permission of launching the campaign in the next few weeks.
Anyways, there will be no explicit list of our accomplishment because they are all kind of blurry system adjustments, but since we worked in the AI a lot and since it is one of my specialties, this blog will be about how to make a proper character AI.

First of all, many video games needs global intelligence system that gives orders to non-player-characters in a way similar to a player in a RTS game. Bad guys in a RTS and often in tactical role playing game are directed by a god-like or player-like intelligence. That type of intelligence is very different than the individual intelligence that makes every little guy run, attack or move. Today, we will talk about the individual intelligence, AKA character AI.

There are many ways of doing a character AI. The first and most simple one is to make your guys behave in a completely random way. In many basic 2D games, the simple fact that enemies behave in a unpredictable way makes them seem intelligent. A friend of ours programmed a simple 2D shooter once and didn’t bother creating a AI. His enemies simply chose, at any given time, between shooting, crouching, running towards the player or running away from the player. In the end, he received compliments for his elaborate AI because some player had seen enemies dodging bullets and running from grenades. If it works, it’s fine. Artificial intelligence in games is more about making the guys look intelligent than actually making them intelligent.

The second most straightforward way is the good old decision tree. A decision tree is always a good start because it is simple to design and to understand. Most of the time It can be drawn on a sheet of paper in a way that is easy to understand. It simply means that, at any given time, a character looks at the world and decides what to do according to a simple and static pattern.
For a university project, Germain and I made a weird 3rd person shooter RPG. I started off building a huge decision mechanism which could be modified in-game by the player and adapt to different situations. After a couple of weeks of development, it turned out that, with our game complexity, we only needed a simple two steps decision tree to choose between running and fighting.
Starting a game with a very simple decision tree AI allows to concentrate on other things. The tree will slowly grow as the game becomes more complex but in many games, it may just do the trick until the end.

The third and more complex way is to build a decision cloud (or a moving tree, if you prefer). This is what Castle Story use. If you are not interested in these sort of logical twists, you can go directly to the soundtrack of the week.
The general idea is to build a certain number of decision trees (let’s call them routines since they can be parallel and don’t necessarily banche in a predetermined fashion) and give any routine the ability to switch to a new one. For example, let’s say that, in a RPG, a character can choose, in any combat, between assuming a healing / supporting role or a fighting / attracting attention role. At any given time during the combat, he runs the routine for his current combat role (who will I heal, maybe I should boost someone’s strength) but he must also check if his role is still relevant and if he wouldn’t be better off switching to his fighting routine. These types of decisions may include general patterns that are harder to evaluate and can’t be checked every time he acts. Maybe it depends on a system of dialogues between characters that updates every ten or thirty seconds or so. However, if the first routine -the healing one- goes through all its tests and concludes that no one needs healing, support or hair brushing, maybe it would be appropriate that it changes its role himself.
One of the good ways to manage decisions clouds is to create a solid message system to pass arbitrary information between parallel routines. For example, in Castle Story, bricktrons have a four core decision system. One to decides their general purpose and actions (build, fight, run). One decides their specific actions (pick up a bloc, strike this guy). Another one carries the actual tasks the second one decided to do (you are in combat and you want to destroy this guy who is also attacking you: dodge, block or attack ?). Finally, a specific and mostly independent core helps the guys moving in a dynamic world where their goals may suddenly not be reachable anymore and were sometimes the best way to get the work done is to stop trying and ask someone else to do it for us. All these systems are linked together with a message manager.

Why don’t you try in drawing something like that on a single sheet of paper ? In these situations, I give this simple advice to programmers : gives clear and fleshed out names to you many routines and messages. Don’t make a system where you have to add orders like Order[8] and Order[25] in your todo list. It will be hell and you may sometimes get lost for hours in your behavioral bugs. Try something like “Drop everything” and “Run away”. Phrases and words might be longer to parse for a computer, but they are so much easier to understand for a human brain.
So that’s it for this week, I hope that short AI tutorial got you interested in the fantastic world of behaviour programming.

See you next week.

Team Sauropod