December 17, 2010

Design : Artificial Intelligence

This is a first technical draft on the AI that will be used in this game. This is not a definitive design document, so it's subject to changes during the development. However, it should give you a pretty clear idea of how the NPC will act and how the game will try to simulate a (more or less) coherent city. This document won't cover the combat part.

I've played around with a lot of AI systems in my life, from the simple decision trees to the neural algorithms. All of them are good. But they all have drawbacks or performance issues. In the case of GRA, with thousands of NPC who need to act coherently in a large city, we'll need something that's simple, very fast (CPU wise) and easily improvable (so new behaviors can be added easily). That's why I have picked a combination of Finite State Machine [FSM] and Smart Terrain (used in Stalker and The Sims).

Combat excluded, a civilian has different states corresponding to his needs, like:
  • Work : Need to find some work to earn money
  • Eat : The civilian is hungry an need to find a source of food
  • Sleep : Time to go to bed
And so on. 

The current state of a civilian will be determined by different factors (hunger, fatigue, funds, time of the day, and others, plus some randomization thrown in). What they actually do during each state will be to reach a zone of the map where they can satisfy their needs and start using the objects around until satisfied. Let's take an example in here and say we have an office worker who is low on funds, and let's call him Bob:
1) So, Bob is broke. He now realizes he has to work if he want to live (sad world, isn't it). 
2) Luckily enough, there's an office building nearby with an unoccupied computer
3) Bob switches to work mode and start pathing toward that location
4) Once Bob is at the work place, he locates the computer and start bumping into it (using it)
5) The computer recognize Bob as an office worker and give him a few dollars
6) Once Bob is satisfied or when he start becoming hungry he'll switch to another state

Easy enough, but what happen when, let's say John the corporation spy use the very same computer. Well, here again, all the work is done in the object itself. The computer will recognize John as a spy and will give him the secret document he was looking for. A burglar may destroy the computer and gain spare parts he can sell. And a repair man would repair a broken terminal and retrieve some money out of it.

As you can see, granted I explain myself well enough, most of the work here is done by the game objects. NPC simply path to a location corresponding to their need and start using the available objects in the area. It keeps the NPC AI code very short and adding new professions is simply a matter of adding new objects or altering existing ones. However, some of the interactions I'd like to implement (especially trade related) will still need to be implemented in the NPC AI code itself, that's why it's not pure Smart Terrain, but rather a mix of it and FSM. 

Now, regarding the pathfinding, here again I am using a hybrid method. Using the A* algorithm only would be an overkill, especially in a city map with large avenues. So, first and foremost, only NPC in the block the player is located use any kind of pathfinder, actions in other locations are simulated (it will deserve another article later). The PathTo method first try to find a path using a basic collision avoidance algorithm, if it fails, A* will kick in. The FollowActor method do the same, but if the target has moved since the last time the follower used it, first it will try to locate the target in a nearby tile before trying to find a new path. Also, as reaction speed isn't critical in such a game, i plan to add a limit to the number of time the A* can be called per turn. The NPC (if any) who didn't get the chance to call it will move in the general direction of their target location, if outside, or idle, if inside.

That's all for now :)

No comments:

Post a Comment