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]
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:
nextstate = BOMBTARGET;
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?
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!