AI Programming questions
by Scott Army · in Technical Issues · 09/02/2005 (7:42 pm) · 7 replies
I'm not a programmer so this stuff is all greek to me, but I've been trying to figure out just what is feasibly possible for AI within Torque (at least as it pertains to my project). Ideally I'm trying to make a cross between a FPS and RTS.
Where everything gets hazy is trying to script behaviors for enemy and friendly units such that they do more than just run blindly and attack when presented with something they can attack. I'd like their behavior to be somewhat situational. It would be interesting to get enemies to run away on occassion or surrender. If they had greater numbers, they'd be more inclined to attack using a set formation.....and if the player adjusted so that he/she mowed down the bots....they'd assess the situation and adopt another strategy. Would this be handled by setting up some kind of heirarchy of if/then scripts that would fire at some random interval?
So as an example....let's say we want to make a weak unit....he can do any of the following:
1.) attack
2.) run away
3.) surrender
4.) hide
5.) retreat and attack
Each of these behaviors should be possible to trigger based on some random number generated. When the trigger arises, then, a random number would be generated and an action taken. Would this be an adviseable way to handle this sort of AI and is it feasible? I envision this being a tree pattern where at each branch it asks if a set of parameters is met and if so, branch in x direction, otherwise branch in y direction. This seems like it would give the illusion of being dynamic when really it isn't. So is this sort of control scheme possible and has anyone toyed with AI of this nature?
Where everything gets hazy is trying to script behaviors for enemy and friendly units such that they do more than just run blindly and attack when presented with something they can attack. I'd like their behavior to be somewhat situational. It would be interesting to get enemies to run away on occassion or surrender. If they had greater numbers, they'd be more inclined to attack using a set formation.....and if the player adjusted so that he/she mowed down the bots....they'd assess the situation and adopt another strategy. Would this be handled by setting up some kind of heirarchy of if/then scripts that would fire at some random interval?
So as an example....let's say we want to make a weak unit....he can do any of the following:
1.) attack
2.) run away
3.) surrender
4.) hide
5.) retreat and attack
Each of these behaviors should be possible to trigger based on some random number generated. When the trigger arises, then, a random number would be generated and an action taken. Would this be an adviseable way to handle this sort of AI and is it feasible? I envision this being a tree pattern where at each branch it asks if a set of parameters is met and if so, branch in x direction, otherwise branch in y direction. This seems like it would give the illusion of being dynamic when really it isn't. So is this sort of control scheme possible and has anyone toyed with AI of this nature?
About the author
#2
You might find it useful to study finite state machines. There are any number of tutorials on the net. ie generation5 - Finite State Machine Tutorial
A FSM can give you most of the behaviours you have listed. I would suggest getting AI functional at the unit/individual level before attempting to create the higher level functions. Provided you have a method whereby each unit can be given a task/goal you can create a higher level commander to make units cooperate at a later stage.
09/02/2005 (8:04 pm)
Scott,You might find it useful to study finite state machines. There are any number of tutorials on the net. ie generation5 - Finite State Machine Tutorial
A FSM can give you most of the behaviours you have listed. I would suggest getting AI functional at the unit/individual level before attempting to create the higher level functions. Provided you have a method whereby each unit can be given a task/goal you can create a higher level commander to make units cooperate at a later stage.
#3
Thanks for the link.....makes for an interesting read. It would definitely help from a design standpoint to understand how the mechanism functions.....now I just need an adept programmer. As a question, though....at the unit level, I could define a bunch of actions like stand, kneel, go prone, idle, walk, run, fire weapon. But how would these states relate to higher level states (like being alerted of enemies and deciding on a course of action)? Once the sentry is alerted, any behavior requires a large number of the actions to work in very specific and organized ways. How does someone control the flow and sequence of these complex actions?
09/02/2005 (9:26 pm)
@Michael:Thanks for the link.....makes for an interesting read. It would definitely help from a design standpoint to understand how the mechanism functions.....now I just need an adept programmer. As a question, though....at the unit level, I could define a bunch of actions like stand, kneel, go prone, idle, walk, run, fire weapon. But how would these states relate to higher level states (like being alerted of enemies and deciding on a course of action)? Once the sentry is alerted, any behavior requires a large number of the actions to work in very specific and organized ways. How does someone control the flow and sequence of these complex actions?
#4
It is the transitions between states that give you a lot of these higher levels of reasoning. Transitions are triggered when a certain combination of inputs is observed. By tuning the trigger conditions you can make very believable actions fairly quickly.
As an example, lets look at a tracking turret. It only has two states - Scanning and tracking. Assuming it starts in the scan state, we have to determine how it can transition into the tracking state. We might define the condition that it will track the first object to come within 50 units of it's position. Every update, it will check to see if their is anything within it's range. If there is, it transitions into the tracking mode and will follow that object. If the object moves outside 50 units then it transitions into the scanning state. This turret is pretty stupid as it will always follow the one object until it goes out of range.
You could make it smarter by having it do a 'threat analysis' of all objects in range and choose the object that is the most danger. Now we have a turret that will choose the most dangerous target within range and track it.
Want it to fire? We can have another state - firing. The firing state causes the weapon to fire and then returns to the tracking state immediately. The transition from tracking to firing would be along the lines of 'is the turret aimed at the object being tracked?'
By changing the inputs (maybe we only want to scan in one direction, ie bot sight) we can change the way in which the FSM operates. The choice of inputs is very much dependant on what you want the FSM to be mimicing.
It is possible to have a weighted random choice when determining state transitions. In the example above, we might give the turret two weapons. We might give it a 95% chance of firing a machine gun and a 5% chance of firing a missile. It is even possible to have these weighted values modified based on the object we are tracking.
Designing a good AI FSM is almost as much an art as it is a science. Start with the most common actions that you wish to perform and break them down into small steps. Once you have done this for a number of actions you should see that there are common steps within each action. The goal is to merge the steps required for all the actions into one FSM. This won't always be easy!
I suggest that you get hold a few books on the subject. I can recommend the 'AI Game Programming Wisdom' series and 'AI for Game Developers' is a good introductory book. I'm afraid this is a very complex subject and goes well beyond what I can provide here. If you can find yourself a good programmer you should be able to leave most of the grunt work to them and just work with them to define the actions you wish the AI to perform.
09/03/2005 (12:18 am)
Scott,It is the transitions between states that give you a lot of these higher levels of reasoning. Transitions are triggered when a certain combination of inputs is observed. By tuning the trigger conditions you can make very believable actions fairly quickly.
As an example, lets look at a tracking turret. It only has two states - Scanning and tracking. Assuming it starts in the scan state, we have to determine how it can transition into the tracking state. We might define the condition that it will track the first object to come within 50 units of it's position. Every update, it will check to see if their is anything within it's range. If there is, it transitions into the tracking mode and will follow that object. If the object moves outside 50 units then it transitions into the scanning state. This turret is pretty stupid as it will always follow the one object until it goes out of range.
You could make it smarter by having it do a 'threat analysis' of all objects in range and choose the object that is the most danger. Now we have a turret that will choose the most dangerous target within range and track it.
Want it to fire? We can have another state - firing. The firing state causes the weapon to fire and then returns to the tracking state immediately. The transition from tracking to firing would be along the lines of 'is the turret aimed at the object being tracked?'
By changing the inputs (maybe we only want to scan in one direction, ie bot sight) we can change the way in which the FSM operates. The choice of inputs is very much dependant on what you want the FSM to be mimicing.
It is possible to have a weighted random choice when determining state transitions. In the example above, we might give the turret two weapons. We might give it a 95% chance of firing a machine gun and a 5% chance of firing a missile. It is even possible to have these weighted values modified based on the object we are tracking.
Designing a good AI FSM is almost as much an art as it is a science. Start with the most common actions that you wish to perform and break them down into small steps. Once you have done this for a number of actions you should see that there are common steps within each action. The goal is to merge the steps required for all the actions into one FSM. This won't always be easy!
I suggest that you get hold a few books on the subject. I can recommend the 'AI Game Programming Wisdom' series and 'AI for Game Developers' is a good introductory book. I'm afraid this is a very complex subject and goes well beyond what I can provide here. If you can find yourself a good programmer you should be able to leave most of the grunt work to them and just work with them to define the actions you wish the AI to perform.
#5
Thanks so much for all the info. It sounds as though I could just sit down and plan out what types of actions should occur and under what circumstances....and then leave it to the programmer to set up. I suppose I'll set about writing up a basic unit/bot interaction portion to my design doc real soon, then. Aaaaah but I've had zero luck finding a programmer over the last five months or so which sucks. I'll have to get my animator friend to get on the models I've already made so I can post up some avi's of the assets we've been creating.
How difficult is it to implement FSM's into Torque's infrastructure? Would it require a ton of code rewrites or is it something that a programmer could simply create and drop into the existing code base without too much tweaking (aside from optimizing its performance, of course)? I only ask because I want to be as informative to potential candidates as humanly possible and I don't want to advertise a position and not clearly state what's needed skill-wise.
09/03/2005 (12:57 am)
@Michael:Thanks so much for all the info. It sounds as though I could just sit down and plan out what types of actions should occur and under what circumstances....and then leave it to the programmer to set up. I suppose I'll set about writing up a basic unit/bot interaction portion to my design doc real soon, then. Aaaaah but I've had zero luck finding a programmer over the last five months or so which sucks. I'll have to get my animator friend to get on the models I've already made so I can post up some avi's of the assets we've been creating.
How difficult is it to implement FSM's into Torque's infrastructure? Would it require a ton of code rewrites or is it something that a programmer could simply create and drop into the existing code base without too much tweaking (aside from optimizing its performance, of course)? I only ask because I want to be as informative to potential candidates as humanly possible and I don't want to advertise a position and not clearly state what's needed skill-wise.
#6
There are a number of resources available that would be of assistance in getting started. The AI Guard Unit is a good place to start (you need to be a Torque SDK owner to see this resource as there are portions of engine code). Any decent programmer should have no difficulty in dropping an AI system into Torque.
Getting an AI up and running is not too hard. The real work is making it do exactly what you want!
09/03/2005 (1:28 am)
Scott,There are a number of resources available that would be of assistance in getting started. The AI Guard Unit is a good place to start (you need to be a Torque SDK owner to see this resource as there are portions of engine code). Any decent programmer should have no difficulty in dropping an AI system into Torque.
Getting an AI up and running is not too hard. The real work is making it do exactly what you want!
#7
...keep chuggin' and never give up.
09/03/2005 (8:04 pm)
I am not a C++ programmer by any stretch of the imagination; and I have gotten rudimentary AI working with scripting alone. I looked at the above referenced Resource and extrapolated it. I did not touch the Source code at all and I have basic AI working. I feel all it really takes is an amount of time focused on the task at hand. I am a fairly disciplined person, so perhaps it comes naturally? I also don't mind reading code at all, so I guess it's ingrained in there somewhere, and noticing the patterns that occur over and over really helps. I was working in Japan for 6 months a long time ago and watched TV network news everynight[that's right, in a foreign language I didn't comprehend], I started noticing the dialog kept repeating the same words over and over, before long it started to make sense......keep chuggin' and never give up.
Scott Army