My military AI-project

Started by
14 comments, last by UlfLivoff 20 years, 7 months ago
quote:
Have you checked out the work done in the Intelligent Agents lab at Melbourne Uni...


I have checked out a lot of military sources, but not this one -thanks for the tip!

quote:
Additionally, how do you plan on dealing with uncertainty within your simulation. You've mentioned that your AI will be FSM based. That's not very realistic and real soldiers will very quickly be able to discern an artificial enemy from a human one within the simulation, making the virtual environment less believable.



Well, I don't think that one can say for sure that a simulaton will be unrealistic just because I use FSM.

The thing is, I'm not using them like they do in quake II, with simple 'search state', 'attack state' etc.

Whats unrealistic in Quake II (I think), is using FSM for both handling decisions and actions - often resulting in predictable behaviour.

In Human Behaviour Representation litterature they often use different tools to simulate actions and decisions, so they can use the advantages of FSM but not getting stuck in the big mess of having a FSM managing everything.

'Millitary behaviour' is very situation dependent. for instance; the list of actions available at an observation post is very different from the list of actions available during the transport phase of a recon patrol (according to field manuals).
So it is very natural to use FSM to differ between these situations. Like "what kind of situation am I in?".
We might end up with multiple FSM to handle it all, the AI is still under development so things could change.


You got the short version of a very long story, I hope it made sence


Unceartainty will be handled with stochastic state changes in the based on psychological variables. i.e. A guy will not be able to handle his gun properly right after a grenade exploded near him - but after he has 'cooled of' a bit, he´s almost back to normal I think you could say it has some resemblance with Markov chains.

Best regards
Ulf Livoff


[edited by - UlfLivoff on September 3, 2003 7:50:26 AM]

[edited by - UlfLivoff on September 3, 2003 8:10:23 AM]
Advertisement
quote:Actually, I never understood why realistic shooting is so crappy implemented in all games on the market. I mean, get some statistics from a shooting range and implement it


Exactly but that would be annoying for most gamers, maybe not the shooting itself but the weapon behaviour. In Swiss Army, we have a Sig rifle, nearly the same as the one in Counterstrike, and we learnt to handle what they call "troubles". Sometimes a cartridge may get stuck in the (too hot, dirty) weapon and there are extra manipulations to perform (reloading,..). You''ll never see such random and frustrating events happen in a game. All things that would frustrate a player have to be implemented in your simulation
In a system like this, it is very important to determine the 'level of detail' i.e. what should be included in the simulator.

I pretty sure that that limit will be just above weapons jamming, because there is no meaningful way to siumulate actions to fix a weapon jamming. Possibilities would be a "fix-weapon jam" button, but how realistic is that? Then there's other factors which are more interesting, like simulating lack of sleep or food.

I fully agree that "annoying" factors adds a lot to the game.
But I think it will be implemented in another shape, like the pick-up truck not making it to the pick-up point etc.

If you want to simulate *everything*, there should be a bladder indicator showing how much the soldier needs to go to the toilet etc. so of course the line has to be drawn somewhere

Ulf Livoff



[edited by - UlfLivoff on September 3, 2003 1:57:11 PM]
quote:Original post by UlfLivoff
Well, I don't think that one can say for sure that a simulaton will be unrealistic just because I use FSM.


When I talk about a FSM, I'm talking about an agent function with a deterministic transition function. If we have different definitions of FSM, then our communication is buggered from the start. Assuming this definition, humans are quickly able to identify artificial agents by viewing repeated trials and observing the same behaviour. Do you plan on introducing stochastic decisions... or just relying on the complexity of the simulation to ensure that no repeated trials occur.

quote:Original post by UlfLivoff
The thing is, I'm not using them like they do in quake II, with simple 'search state', 'attack state' etc.


I wouldn't expect you to!

quote:Original post by UlfLivoff
In Human Behaviour Representation litterature they often use different tools to simulate actions and decisions, so they can use the advantages of FSM but not getting stuck in the big mess of having a FSM managing everything.


You might want to investigate 'JACK'.

quote:Original post by UlfLivoff
'Millitary behaviour' is very situation dependent. for instance; the list of actions available at an observation post is very different from the list of actions available during the transport phase of a recon patrol (according to field manuals).
So it is very natural to use FSM to differ between these situations. Like "what kind of situation am I in?".
We might end up with multiple FSM to handle it all, the AI is still under development so things could change.


Why not use direct planning methods for each agent. Since you're working in a military environment, sufficient hardware is not an issue. If needs be, you could use a PC for each artificial agent and have them communicate with the central world server a la SOAR. You could even implement a SOAR-bot as your core AI. I'm sure John Laird would like to see SOAR get used more than it has been!

quote:Original post by UlfLivoff
Unceartainty will be handled with stochastic state changes in the based on psychological variables.


Your text was cut off for some reason... I take it you were saying that uncertainty would be handled by stochastic changes in the FSM? If that's the case, then FSM is not the correct label for that architecture... at least not within the AI community. FSM is normally reserved for deterministic transition functions.

quote:Original post by UlfLivoff
I think you could say it has some resemblance with Markov chains.


Yes, it does. The FSM is just a singular case of a larger class of functions... of which the stochastic state machine is the broader case for discrete systems. All of the transitions are governed by a single equation that describes the evolution of information in the system (in this scenario, information reflects the known state of the agent at any time)... and interestingly enough, Schrodinger's Equation (from quantum mechanics) is another special case of this governing equation (called the differential Chapman-Kolmogorov Equation ).

I suggest you look at Tom Dean's work, particularly on learning stochastic maps . A map is another name for a state machine, often used in the engineering community. If you need a bibliographic reference, I can provide it when I get home tonight... I don't have my .bib file copied on my work machine (I should fix that)!

Cheers,

Timkin

[edited by - Timkin on September 3, 2003 9:57:33 PM]
Hi UlfLivoff,

From what I''ve seen you have a very impressive concept going here. I am currently with the Canadian Armed Forces and was Infantry for 6 years. What are all the overall factors you are using to plot your smart routes for you men to follow?

ie. Day-light/Moon-Light, land elevation(hills and cliffs), water depths(you can wade through water levels about chest or neck high, unless you are carrying non-water resistant equipment, etc), wooded or high grassy areas, etc... Indeed many, many factors to take into account that a ground soldier would consider valuable to avoid or use to his advantage.

Also a main factor that wasn''t mentioned at all is known location of the enemy(or other hostiles). This could effect what side of the hill or ravine you are walking along for instance.

As a former grunt myself, I must say, this is a very interesting project. I hope you can meet your deadline.
I apologize for the confusion. Hopefully, this post will make it more clear.

First of all, the decisions will initially be handled by a FSM according to Timkin's definition. This is an obvious choice, given the extremely formalized training manuals.

This will lead to 100% perfect behaviour, since everybody is behaving excactly like it's written in the manual.

Everybody who's been in the army knows that that is very unrealistic

After that, the model will be extended to deal with non-perfect behaviour. Instead of just having a simple determenistic transition function, the function will check the soldiers parameters. Based on this, there is a possibility that the soldier does something wrong. this means the system will be handled by a stochastic state machine. The stochastic state machine is not used from the beginning because we think it would be a mess to implement and (especially) debug a stochastic system as we implement the formalized infantry bahaviour.

Regarding predictability, one must remember that infantry behaviour is very predictable by nature. That's why you can take eight soldiers from different parts of the country and make them work as a team from day one.

I believe that the modular nature of complex tasks, with coordination by the squadleader, will result in a behaviour that is not easily predictable by a normal computerplayer. But if he's a sergeant in a NATO country, the behaviour will be very predictable, but thats the way it should be

Seeing is believing, so I´ll get back to this when I have a demo to show you. (but don´t hold your breath, he he)

quote:
WILL at RedAnt:
What are all the overall factors you are using to plot your smart routes for you men to follow?


Please check out poster 1 in my initial post. It carries a (very brief) description of my 'tactical pathfinding'.

When it comes to pathfinding, I've found this article to be very usuful.

I believe it deserves a link in 'articles and resources' on GameDev.net

Regarding the deadline: this is what I'm going to work on in the years to come, so the deadline is merely a master-thesis deadline, not a project deadline

Thanks for your comments so far!

(I'll get back to the rest of Timkins comments)

Best regards
Ulf Livoff

[edited by - UlfLivoff on September 4, 2003 7:23:15 AM]

This topic is closed to new replies.

Advertisement