Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    271
  • comments
    969
  • views
    189643

AI is a bitch...

Sign in to follow this  
Sir Sapo

116 views

Hey everyone!

This is a pretty small/meaningless entry, but I had to take a break from AI coding, because I can only take it for so long. Anyways, I decided I would go over how the AI works for the planes in A22, and hopefully in the process I'll solve some of my problems...

The AI Pilot
Initially I was coding all the AI code for the planes into the "Airplane" class itself. This worked fine until I need a bunch of special variables and functions which started to clutter up my already crappy code, so I took a step up and created an AI object, which I have aptly named: "AI_Pilot". The AI_Pilot is an object that sits at a higher level than the airplane it controls, so it contains a reference to its aircraft, which allows for a direct interface between pilot and plane. Upon the initialization of any NPC aircraft, a corresponding AI_Pilot is created and handed the reference to the aircraft.

Finite State Machines FTW!!
The AI_Pilot uses a finite state machine to decide what to make its aircraft do. For the uninitiated, finite state machines are among the simplest AI techniques, composing of a finite number of "states", each state containing instructions on what to do in that state. The machine can switch the current state, and therefore cause the AI to perform differently. Here are a couple of states for the AI_Pilot in A22: TRAVELING, EVADING, SETTINGUPBOMBRUN, LANDING, TAKEOFF, FORMUP, TERRAINFOLLOWING, DOGFIGHTGUNS, DOGFIGHTMISSILES, etc, etc. As you can see, the goal is to have a state for every possible scenario the AI_pilot may encounter, so that it can handle itself well in any situation. Obviously this is impossible for a game like A22, but we're going to try[grin]

Orders
While the states directly control the actions of the plane, the AI_Pilot's "orders" help decide what state to be in. This is the interface that will allow the play to command his wingman, or any other friendly units under his control. By setting the pilot's orders to "ATTACKALL", every single combat state is enabled, allowing the AI_Pilot to bomb, strafe, and generally devastate anything it sees. On the other hand, setting the orders to "FOLLOWME" will disable all the combat states (except emergency ones such as SAMEVASION"), and the pilot will follow his designated leader. Here are some of the orders available to the player in A22: FOLLOWME, ATTACKALL, ATTACKGROUND, ATTACKAIR, ATTACKMYTARGET, LOITER, RTB.

State Based Transition
As you have read, the states are an essential part of the Finite State Machine (hell, they're even in the name), but how is the current state decided upon? Well, the states themselves dictate whether to change states, and for that matter, which states to switch to. For example, there is a state called "SETUPFORBOMBRUN", in which the plane will fly to a point that allows for a bomb to be dropped on a target. Within this state is the criteria for transitions out of that state, for example:

if(WayPointReached())
nextstate = BOMBTARGET;
else
nextstate = NO_TRANSITION;

In that code snippet, the pilot checks to see if it has reached the waypoint that will allow it to bomb its target, and if so, it switches to the bomb state, but if not, it stays in the SETUP state until it reaches that waypoint. Pretty simple, eh?

State Oscillation
This is the problem I've been having with the current system, and it is a drawback of any system that uses such precise state transition criteria. State Oscillation occurs when an object is really close to the criteria for 2 or more states, and the state it switches to affects the object just enough to meet the criteria for a different state, which affects the object back to the initial criteria, so it switches states back, etc, etc. For example, there are 2 states that often clash in my current system: EVADE and TERRAINAVOIDANCE. In the EVADE state, the pilot picks a random direction every second or so and flys toward it, to try and evade a SAM or enemy plane. The TERRAINAVOIDANCE state takes over the airplane and pulls up to avoid it crashing into the ground. Often times, the EVADE state is called when the aircraft is really low to the ground, this often results in the AI_Pilot attempting to dive lower to the ground to avoid a threat, then the TERRAINAVOIDANCE takes over, and climbs, then, after TERRAINAVOIDANCE is satisfied with the altitude, it hands control back the EVADE state, which all to often dives down again, and the process starts over again. This is a minor problem, but one that is causing me a lot of headaches, because all it takes is one twitch reaction like that, and the whole illusion is lost.

Well, I hope you guys enjoyed this slightly more wordy, and slightly less pretty entry. I know I enjoy technical journal entries, so hopefully you guys do to! Peace Out!
Sign in to follow this  


6 Comments


Recommended Comments

How about introducing minimum state durations? That way the plane will 'lock' into evading that SAM site before trying to avoid the terrain, or vice-versa. A slightly more difficult solution would be to detect the jittering states and have an alternate state that handles a 'compromise' between the target action of the two conflicting states.

Share this comment


Link to comment
FSM's definitely make the process a bit cleaner to work with AI. It sounds like you've got it nicely planned out so I would not think you would have any horrible problems getting it working with A22.

Great job!

Regards,
-Dave

Share this comment


Link to comment
Sounds very complex, but HopeDagger's suggestion sounds valid, with minimum state durations. However, in the EVADE/TERRAINAVOID situation you talked about, that could result in the plane crashing, which could add to the realism of the pilot :p

Cheers
Jacob

Share this comment


Link to comment
Guest Anonymous Poster

Posted

Why don't you just make the evade state more intelligent? I.e. not flying directly into the ground.

Share this comment


Link to comment
I don't like the idea of a minimum state duration because there are situations when the AI should switch states quickly. I think you should rewrite the evasion state to avoid diving below a predetermined altitude (one that is high enough to avoid state flickering).

Very interesting entry. I liked reading it. [smile]

Share this comment


Link to comment
Quote:
How about introducing minimum state durations? That way the plane will 'lock' into evading that SAM site before trying to avoid the terrain, or vice-versa. A slightly more difficult solution would be to detect the jittering states and have an alternate state that handles a 'compromise' between the target action of the two conflicting states.


Yeah, I do have a 'reactiontime' variable that effects the time between state transition checks, but unfortunately, the reactiontime required for some states to be non-jittery messes up the other ones by making them not respond quickly enough (ie. EVASION/TERRAINAVOIDANCE vs. DOGFIGHTGUNS/DOGFIGHTMISSILES).

Quote:
FSM's definitely make the process a bit cleaner to work with AI. It sounds like you've got it nicely planned out so I would not think you would have any horrible problems getting it working with A22.


Thanks, I've been planning this one out for awhile, so it shouldn't be that big of a hurdle.

Quote:
Sounds very complex, but HopeDagger's suggestion sounds valid, with minimum state durations. However, in the EVADE/TERRAINAVOID situation you talked about, that could result in the plane crashing, which could add to the realism of the pilot :p


Problem is, when the pilot crashes 90% of the time, you lose that immersive feeling[grin]

Quote:
I don't like the idea of a minimum state duration because there are situations when the AI should switch states quickly. I think you should rewrite the evasion state to avoid diving below a predetermined altitude (one that is high enough to avoid state flickering).

Very interesting entry. I liked reading it.


Yep, thats how I ended up fixing it, by adding some special case code to stop those 2 states from being so close together. Its just going to take a bit of time to make sure every possible state meshes well with all the others.

Thanks for the comments!

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!