Skip to main content

AI Theory

I've been working on the AI for the game the last couple of days.

[Don't worry, every thing is OK...]
In my smaller games AI was pretty simple. They had a simple game mechanic, try to walk in to the player and kill them. So basically they have a single type of behavior.

[I'll eat your brains!]
That's fine for simple enemies like zombies, but what about more complex characters?
Well, I've written a couple of different behaviors, we could call them:
  1. roaming
  2. seeking
  3. fleeing
  4. fighting
  5. following
  6. waiting
[while: guarding]

The behaviors are encompassed in a finite state machine. Each state can transition in to others, depending on the behavior. So a waiting agent sees an enemy they become alerted and try to attack, they transition to the seeking state.

After testing I'm confident I've got the bugs out of each of them.
But there's a problem. How to choose which behavior to use at any one time? How to know which state to enter next?

[trolls ahoy!]

If an agent sees the enemy, obviously they will do something different depending on whether they are an archer, a wizard, a dragon or a troll or whatever. When they lose sight of the enemy, which state should they return to? Clearly no single set of 6 states can fit all those scenarios.

Right away I'm back to the previous situation of wanting a state machine to manage my state machine. But again, I don't want to go down that road. Once I start looking for the complex solution, I'll get bogged down and never finish.

One simple possibility would be to have character attributes like self.default_state or self.alerted state, but then behavior becomes split between the states and the character so adding new characters means partly writing new behavior. I want all behavior to be managed from within the state machine. I don't want behavior entangled with specific agents types, but rather modular and easy to assign even during game play.

So I'm going to use inheritance to solve the problem.

[Do I need to draw you a picture?]
Firstly, some of the above states can be merged. Seeking, Fleeing and Roaming are all the same behavior, only one finds the closest tile to the target, one finds the tile furthest away from the target, and one chooses a random unvisited tile. So I now have a single state, Navigation.
[Navigation; You are here!]
Then I go back and create new states like Roaming(Navigation).
This inherits all the behavior from navigation but uses a different rule for deciding the next square. Fleeing(Navigation) and Seeking(Navigation) do likewise. *

The next step is to create specific versions of those states for a particular AI type. For example ArcherRoaming(Navigation) with some tweaks to the __init__ function to tailor how it transitions to other states. There's also a special custom exit check, to see if there's some special reason to not be roaming around. This reduces it down to just a few lines of code, rather than re-writing a specific behavior for archers.

After that I have to plan how those states will interact and which states are needed for each AI archetype. I'm using flowcharts for that:
[Inside the mind of a dungeon guard]

A little more complex now than:
try to walk in to the player and kill them.
Of course It's not difficult to go further, if I have archers who patrol instead of guarding I can reuse most of the states from archer, but subclass them again as ArcherRoaming instead of ArcherWaiting.

Where this gets really useful is being able to have switchable behaviors. By having a custom exit check we can give some AI archetypes the ability to switch to a different archetype. If we have a party of heroes and I want to give them orders I can do so through dialog choices or through hotkeys. It just asks them to switch to a different behavior archetype.

Become an archer, cast magic, follow me!
Scout ahead, serve drinks, sacrifice yourself for the good of the party!

* At this point I also diverged in to two different kinds of navigation, single tile navigation for close in to the target avoiding obstacles and tile chunk navigation which gives smoother movement (because it uses a shorter route to the target) but is worse at avoiding smaller obstacles. Then I get Attacking(TileNavigation)and Hunting(ChunkNavigation) two different behaviors for use when at different ranges from the target. However I don't want to add to the confusion here.


Popular posts from this blog

Back to Vinland.

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.

Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.

Map screen designs

I've been working some more on the map window. Right now you can only see the base, it doesn't show items, enemies or even doors on the map yet. These would be decals.

In the top window you can see the modified result of last night's tile based map. It looks good but there are some visual artifacts related to the problems I encountered yesterday, and as well it takes much more code and time to calculate.

The second window uses a cheap trick to fake an beveled look from a smoothed version of the 32x32 map. It uses black to mask unexplored areas.

Finally the third version is meant to look like a had drawn map. I'm using a cross hatching texture to distort it and unexplored areas are shown as blank map paper.

There's going to be a mechanic in game where you need to use some paper every level in order to activate the map for that level. From there it will fill it in automatically. Paper will be pretty rare so it might be worth keeping it safe for the more complex level…

Infantry combat and entering buildings.

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game.

Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work.

For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that.

In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation since the en…