Jump to content
  • Advertisement
  • entries
    44
  • comments
    44
  • views
    59553

AI in Caveman

Sign in to follow this  
Norman Barrows

1473 views

Caveman ai:

ai in caveman has been through three major versions.

the first version was just quick and dirty code to get things going. like
all code of this type, it quickly grew and evolved into an ugly mess.

the second version of the ai was a more traditional setstate/runstate
type affair. setstate selected one of about 14 or so AI states for an
entity, depending on what was going on. runstate was a big switch
statement that executed the code for the various states. one problem
with the traditional setstate/runstate model is that it only has one
state variable. so if you have multiple states at once you must have
different states for each combo.

the third and current version of the AI uses a different approach.

it uses prioritized condition checks to determine what to do. as soon as
a condition is found it should react to, it does so, then returns. no
setstate/runstate. as soon as condition is found, the equivalent setstate
is therby determined and the appropriate runstate code can be immediately
executed.

it also uses multiple AI state variables (mostly booleans) in lieu of a
single AIstate variable as in setstate/runstate. so it has AI state
variables like in_collsion _recovery, in_collsion_avoidance,
taking_missile_fire, orders (goto, attack, follow, etc.), and so on.
this allows an entity to be in multiple states at once such as:
"in_collision_recovery" while moving to attack due to
"taking_missile_fire" while "following" another entity. when they finish
collision recovery, they resume moving to attack. when done attacking,
they resume following the entity. without the need to push and pop states
on and off a state stack. the condition check priorities cause them to
automatically resume a lower priority state once a higher priority
state is no longer in effect.

the prioritized condition checks work as an expert system.
the condition handlers (code) in turn are each mini expert systems in
handling their condition. implementation varies depending on the condition
being handled. most are rule based systems. some are state machines. the
handlers in turn may call even lower level expert systems for tasks such
as selecting best weapon to use, etc.

all told, the game implements about 18 different types of ai depending on
the entity type and whose side they're on. so for example, AI for a pet
dire wolf is different from that for a wild, subdued, or captured dire wolf.
and AI for a traveling companion caveman is different from that of a neutral,
hostile, thief, hired warrior, or band member caveman.

there are four basic types of AI for animals:
1. defend - the animal will stand its ground and defend itself if approached.
2. maintain_distance - the animal will attempt to maintain a safe distance
from all threats. if approached, it will flee.
3. attack - the animal is predator. when hungry it will go hunting, feeding
on nearby carcasses if available, or attacking other animals not bigger than
itself. when not hungry it just hangs out.
4. defend_location - the animal will defend a specific location in the game
world. used by quests where animals guard treasure. if far from the
location, the animal will move to the location. if at the location, it will
attack all who approach.

Avian AI is completely separate from that for ground animals, although it
takes the same form.

All animals include "graze" as one of their possible AI moves. its usually
the last choice - IE when there's nothing more important to do.
"graze" cycles between stand, wander, flock, and migrate states periodically
at random. its an example of a condition handler that uses a state machine.
wander simply moves to a random wander_to point. flock moves towards the leader
(the first animal of a given type appearing in the entities list). in the case
of the leader, flock becomes stand. migrate is only used by the leader. the
leader moves off in a migrate_direction determined by the type of animal (so
they still migrate the same direction even if the leader is killed). if a
leader is killed, the next active animal of that type becomes the new "leader".

note that leader migration behavior in combo with flock behavior leads to emergent herd migration behavior! ; )

model the little stuff right and the big stuff happens on its own! - well at least sometimes - if you do it right.

multiple AI states vs setstate/runstate is another example of this. by tracking _multiple_ states (which setstate/runstate does not do) - IE by modeling state in greater depth than setstate/runstate - you automatically get emergent push-state, pop-state type behavior with no pushing, popping or state stack required.
Sign in to follow this  


4 Comments


Recommended Comments

You'd find screenshots would make the entries a lot more compelling to read as well.

But its your journal, man, not criticising and I do try to read your stuff. I'm always impressed that you actually have a project alive, well and working. More than can be said for most of us smile.png

Share this comment


Link to comment

Your post formatting makes it really hard to read your stuff.

 

 

Sorry about that, i don't really format. its just a core dump from my brain to the editor, with a little cleanup.

 

This latest round of journal entries were things that were starting to back up on the list of things to post, so i did a whirlwind writing session and knocked them all out right quick, but with very little editing.

Share this comment


Link to comment

You'd find screenshots would make the entries a lot more compelling to read as well.

But its your journal, man, not criticising and I do try to read your stuff. I'm always impressed that you actually have a project alive, well and working. More than can be said for most of us smile.png

 

 

Not quite sure what screenshots would highlight a review of AI versions in the game,

 

but i do have perhaps as many as 100 new screenshots from recent play testing, a fair amount of which hasn't been seen before - even by me - until it happened in the game. And i only take screenshots of the good stuff. i used to be an award winning amateur photographer, so i'm always on the lookout for a good picture. Sometimes its quite hard. more than once, while maneuvering to get that perfect photo, i'll get too close to the action and end up dead! such is the life of a paleolithic combat photographer! <g>. I'm still trying to get a good shot of a saber tooth attacking you. they kill you so fast i can never hit print screen in time! <g>.

 

i'll add "post new screenshots" to the todo list. they're definitely cool. none of them are staged, its all actual game play. and some of the stuff looks like its right out of national geographic or Jurassic park or something.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!