Help and suggestions needed...... we are developing an aerial combat game ( a flying shooting ) and i was assigned to do the AI portion of it. i have decided on using a parallel two state FSMs , one for the locomotion and another for the shooting decision plus there will be two Bulletin Boards so that the players could communicate with each other ... again for respective FSMs. There will be a graph to represent the game Map for AI. There will be an AI engine that manages the AI players, plus provides the platform for team effort via a bulletin board. Is this a good approach ? Could other AI techniques be used for this type of game? and we have decided to breakdown the AI commands to the user input states like UP, DOWN, SHOOT, etc for GAme logic section to handle? Please suggest on this idea.....

Steering behaviors, my friend. Trying to turn towards a defined point.

Quote: Original post by Innocuous Fox
Steering behaviors, my friend. Trying to turn towards a defined point.

OK so now I am gonna use steering behavior but that still does-not complete the total AI solution , does it?



I mean there will be planes to provide the lowest level of steering behavior i.e. locomotion and then let's say I have a another level to provide the steering behavior so as to provide the desired trajectory to reach the goal.


Now I am a bit confused about the Action selection part of steering behavior, the one layer that actually tells or decides what action to take. Should I use a FSMs as I initially posted to equip the Action Selection layer of Steering behavior or are there any other solutions to this problem?

Also what will be perfect for such games, an AI on different threads or an AI that runs along with game logic portion but separately from rendering thread?

I have a suggestion for you concerning the architecture; and I'm assuming you are using a OO-language and taking advantage of its OOP features.

I strongly suggest you apply the "Application Layer - Game Logic - Game View" architecture to this. In essence, your application layer is what is responsible for how the application runs on your target platform; be it PC, PS3, XBox, whatever. This is where you keep the code for initialization and shutdown which is specific to Windows (or another platform), and how you run the application and communicate with the host operating system. You keep that totally separate from the actual Game LOGIC, which is responsible for everything from how your aircraft work to managing overall game states to managing AI behaviors. Keeping these separate means you can more easily port your game to another platform by writing a new application layer, and not totally re-writing the important game logic (though some changes may be necessary). And it's up to you how to best break up the sub-systems, like control input, networking, AI, rendering, etc.

But here's where the "Game View" concept comes into play:

You're going to have a class definition for whatever the entity (i.e., the aircraft) is. And it has the capability to move control surfaces of the aircraft so it can pitch, yaw and roll the aircraft. But don't make the critical mistake of implementing this directly based on control input. You'll have to come up with a way to decide how much force a control surface can apply across any given axis, and you'll want to be able to deal with this not by some sort of floating-point force value (like directly applying x-amount of yaw force to the plane), but by percentage of of flight CONTROL force (such as pilot pushes right pedal in 30%). Simply think of it in terms of how far the pilot has moved the stick/rudder pedals, and NOT in terms of apply x-amount of roll force. Kinda weird to explain, but hopefully you catch my point. And there are several reasons for that. Number one, an aircraft reacts differently to pilot input at different speeds, and this approach makes handling that much simpler. But one of the biggest issues is that you need human AND AI pilots to work just the same, and you will likely want networking (for online play).

If you implement this through a "game view", then both human and AI pilot fly their aircraft in the same way, as opposed to trying to directly decide on how much force to apply across some axis from direct control input values. Your physics system decides on how much actual yaw/pitch/roll results from x-amount of control surface movement. And one of the biggest benefits of sticking to this architecture is that a remote player, in online play, uses the same view path as a local human player. Their data just comes from the server, instead of straight from control input.

Hopefully, my bad breakdown of this wasn't too terrible and you get the gist of it. But this can greatly increase the efficiency of your design and implementation, and make it much easier to maintain. And to give credit where credit is due, I learned about these concepts from Mike "Mr.Mike" McShaffry. :)

You might want to stay away from a complex physics model where you model the flight controls because this may turn out to be too much work. It depends on the kind of game you are making. If you are making a simulation then by all means use a actual physics-based flight model. But if it is an arcade-style game such as Blazing Angels, it maybe easier and result in a more fun game if you just use steering behaviors to determine the motion of the airplane directly, not through some kind of flight model. Steering behaviors produce realistic-looking motion without alot of code and make it easy to implement group behaviors such as formation-flying and flocking. However, they only determine the direction and velocity of an entity, not it's orientation. So you will have to develop a model for how the airplane is oriented based on it's velocity. For instance, if the airplane has any kind of horizontal velocity, i.e. it is turning, then you can make the airplane bank accordingly. For pitch and yaw, you can just use the direction.

And it is a good idea too to keep the shooting decisions and AI on a separate layer from the locomotion system.
So you can write the logic for that code without including lots of details about what the physical motion of the plane is. For instance, you will not check velocity and position to decide if the plane should switch from a Navigate action to an Idle action, you will just query the locomotion system or use an Observor in the locomotion system to determine how the AI knows when the plane as arrived on a waypoint. If you implement this in a modular fashion so that the two systems are separate and independent, then it will be easy to switch to a new form of locomotion implementation without having to change the AI code.
It also makes it easier to test each system separately.
I did this on a football game and it really helped to managae the complexity of the AI and get the project done faster.