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

Vinland 1936

What have I been up to this month?

Well you can see it in a couple of development blog videos, here, here and here.

Vinland 1936 is a game I've been working on (on and off) for about 3 years. It is somewhat based on the old Nirval interactive game, Blitzkrieg;

I hope you've played it since it is one of the best games ever!!! (IMHO)
Blitzkrieg was a real time tactics game. You didn't build a base, or spawn units. It wasn't about rushing the enemy. You got a small number of troops and vehicles that could be replenished or repaired if you had access to a supply base and the right supply trucks, but couldn't be replaced if lost. Once your vehicles were destroyed and your infantry killed you were finished. You couldn't just churn out some more from your factory and have another go at rushing the enemy guns. This made you invest a lot in each of your units. They really mattered.

It was also procedurally generated. Each mission (except for the historical missions) was…

Reboot / Remake / Restart

Although the roguelike project was going well I had a few issues with some parts of the code, and the sheer size of the project was something I could see stretching away in front of me for years with no guarantee that people would actually want to play it when it's finished.

It's time to try something a little less ambitious.
I'm going full rogueLITE!

Using a lot of the code from the roguelike project, I started making a more limited game.
There will be a single character, combat will be more arcade like, there will still be a chance to upgrade and develop your character's stats, but they represent only a single class and have fixed equipment.

I've got a fun character, an interesting setting and an exciting story lined up. It still utilizes my low poly style, but things are going to be a little more cartoony.

Game play involves mostly chucking bombs at the enemy.

But there's also a lot of platforming, jumping from multiple levels is part of the game. And you ca…

Telling a story; Creating a Compelling Narrative.

Telling a story; Creating a Compelling Narrative. In this blog I will talk about my own recent brush with story telling and go on to talk about how tools from creative wring can help you to better author the narrative in your games, whether they have a traditional linear narrative or a procedurally generated interactive narrative.

Narrative and structure in traditional fiction  last week I started writing a story set in the world I'm developing for my game Vinland: 1936.

I hope the story will help me to flesh out my game world and develop my own expanded universe which will be a good place to set my games in the future.

After about a week of work, on and off I've progressed the story to outline stage. For each character thread I have half a dozen chapters which plot a course through the events of the story. Each thread is told from the perspective of a different character.

Actually I started writing as soon as I had my outline, but I've since gone back and deleted what …