Well, finals are over so I can relax a little and get back to thinking of my game project. I was going through the annotated objects thread when I realized that I had a slightly different problem. My game requires a heavy dose of good AI. One of the critical aspects of this AI is that it must be able to make what I call Threat Assesments. When individual Units come into sensory contact with enemy Units, the enemy Unit type has to be assesed for how threatening it is. But herein lay the trick; in my game Units are customizable, and hence I can not hardwire code saying "This Unit has an Offense Value of 210 compared to my Defense Value of 50: Conclusion, find cover ". Technically, I could introduce variables like these (say Heavy Gear's example of Offenseive Threat Values, Defense Values and the like). Now the simple thing would be that when UnitA comes into sensory contact with UnitB, it simply calls a function like: /*ThreatClass is a data class member of a Unit i.e. all Unit's have a ThreatClass through composition */ class ThreatClass { public: int GetOffenseValue() { return Offense;} ; . . /* Other Get accessor methods go here */ void SetOffenseValue(int newValue) { X = newValue;}; . . . /* Other Set mutator methods go here */ private: int Offense; int Defense; int Mobility; int Sensor; } ThreatClass Unit::Sensor(Unit* pUnit) { ThreatClass TCV; int tempValue; tempValue = pUnit->ThreatClass.GetValue(Offense); TCV.SetOffenseValue(Value); . . . return TCV; }; Which then gives UnitA the data members of UnitB's ThreatClass. But is this realistic? If UnitB is a type of Unit that UnitA has seen before, then a simple function call like this is sufficient. More likely though UnitA has a database of known enemy vehicles, and will attempt to match this UnitB to all of the records in the database. If through visual spotting a match is observed in the database, then UnitA knows all the capabilities of UnitB. But if UnitB is not on any of UnitA's database (no one in UnitA's army has ever encountered UnitB before) then how does it obtain these values? Depending on UnitA's sensor types, how exactly does it know how dangerous something is? How thick its armor is? How fast it is? So this then begs the question, how do Units both retrieve data about another Unit's capabilities, as well as understand how dangerous it is in comparison to it? Simply making a function call to retrieve the data values is not sufficient if it is the first time this Unit has been encountered. Moreover, would other conditional modifiers apply to the ThreatClass data members? For example, perhaps the weapon on UnitB is a railgun which has excellent anti-armor capabilities, but is poor against scattered infantry. And what happens if UnitA happens to be an infantry Unit? In that case, it would lower its Threat Assesment against UnitB because it only has a weapon type which is less effective against UnitA. Another related problem is one of creating variants. For example, perhaps I've created two vehicles which have the same hulls, the same weapon, the same engine, but they differ in only one respect...the amount of armor. So perhaps UnitA thinks, "Aha, this is a Type97 Main Battle Tank, my M570 125mm rifle should have a pretty good chance of taking it out even against a front glacis hit". Afterall, UnitA has seen this type of Unit before, so why shouldn't it think this way? But when the shells start bouncing off the Type97A1 tank's hull, then perhaps UnitA might realize something was fishy. All of this suggests two things. One is that all Units (or their AI Commanders) must have access to a database of known unit types. Secondly, a Unit must have some Sensor capabilities which allow it to define certain ThreatClass members, but not necessarily all. Perhaps only through observation of the mystery Unit will certain ThreatClass values be revealed (for example, it may be obvious that a vehicle has a large bore gun sticking out of a turret, but that's all one knows...perhaps that weapon can only fire HE rounds and is useless against armored vehicles). Perhaps only when a functional Unit is captured that full details can be gleaned. Why is this important to me? Because I want the opponents to not know the full capabilities of enemy Units when they initially fight. He may have a guess ("it's a medium sized hull, with a 80-100mm gun, and it seems to be able to go about 45kph on a road") but the exact details will be unknown. And variant upgrades will make it that much sneakier.

---

The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley Edit: corrected a typo and some grammar [edited by - Dauntless on December 12, 2003 4:16:36 PM]

Hello Dauntless,

Ok you have custumizable units cool.
But should you still have at the base of all units an overall
stats for what the unit can do.
example max speed, how it can move, sight distance, rate of fire,
amout of armor, amout of damge per weapon, range of weapon, etc.

Then create a friend functions that bridge bewteen your units.
it these handle the exchange info, and these should come up with a list of outcomes that might happen fore each choice a unit has.
Ie. up to this fuction to figure out a a desicon tree of what to do.
Ie hide, stand and fight, take cover and fight, hit and run etc.
This function then return a list of possible outcomes and AI should then dicide what to do. If it thinks it needs tohold that bridge then it scarfacices the unit to hold that bridge, etc.

Well I just kinda of throwing out some ideas.

Lord Bart

I think the way to go is to establish three threat values, absolute, perceived and relative.
each of these is use slightly diffrently but they are all sequentially linked.

absolute threat: Is the rating used by the units owner, it dervied by knowing all the units cababilites. Its weapon, speed, armor, etc..

perceived threat: this is the value that is derived by an opposing commander based on the information gathered by observation and espionage? Whenever a new unit is encountered its capabailites and threat rating is set to zero. As new information is gathered these zero are assigned values. Such as if you see it moving you know its speed.

Relative threat: is calculated based on the percieved threat of an opposing unit, the absolute of the current unit, as well as any situational modifers. The releative threat value will be used by the units AI to determine its course of action.

so for example:

Team A
owner view:
Tank threat
Railgun 85
Reactive armor 45
Turbine engine 10
absolute threat 140

enemy view:
Tank threat
unknown 20(minium tank weapon value)
unknown 20(minium tank armor value)
Turbine engine 10
percived threat 50

Team B
owner view:
Jeep threat
Rocket 60
Reinforced Armor 10
Gas Turbine engine 25
absolute threat 95

enemy view:
Jeep threat
Rocket 60
unkown 5(minum jeep armor)
Gas Turbine engine 25
absolute threat 90


So Jeep B encounters Tank A, for the first time.
Tank A calculates RT=50
Jeep B calculates RT=45

Now as its stands both belive they have the advantage over the other and thus they engage in battle. However after they have exchanged fire a few times both side would know the others cababilites and jeep would realize its seriously outmatched and run for it.

Essiently the system I''m suggesting each unit would assess its options based on the relative threat value. In this way intellegance gathering would be important because without it you maybe overpowered be a seemingly weaker foe.


-----------------------------------------------------
Writer, Programer, Cook, I''m a Jack of all Trades
Current Design project
Chaos Factor Design Document

quote:

---

More likely though UnitA has a database of known enemy vehicles, and will attempt to match this UnitB to all of the records in the database. If through visual spotting a match is observed in the database, then UnitA knows all the capabilities of UnitB. But if UnitB is not on any of UnitA''s database (no one in UnitA''s army has ever encountered UnitB before) then how does it obtain these values? Depending on UnitA''s sensor types, how exactly does it know how dangerous something is? How thick its armor is? How fast it is?

---

The real question is not how to assess this. The only correct answer is that you can''t. The real question, is, how do you behave in the presence of incomplete information? Depending on how incomplete you information is, any of: abort mission, "test" the threat, or continue mission as if it was known that the new threat was acceptable. These are essentially the same options as an unknown enemy formation.

quote:

---

So this then begs the question, how do Units both retrieve data about another Unit''s capabilities, as well as understand how dangerous it is in comparison to it? Simply making a function call to retrieve the data values is not sufficient if it is the first time this Unit has been encountered.

---

The danger of one class of delivery system to another is usually consistent. Bombers are dangerous to fortifications, fighters are dangerous to bombers, helicopters are dangerous to tanks, etc. So the assessment is simply a matter of raw power (unknown) + what class of delivery system is this platform? This is usually pretty easy to guess. When you have no other information, whether something is land based, air based, or sea based is a pretty good indication of its vulnerabilities and strengths.

If a two-legged walker from star wars appeared on a modern battlefield, helicopters and/or tanks would be dispatched to deal with it (as if it were a tank). The dispatching does not usually involve infantry because helicopters and tanks are faster (if they''re outclassed, they are more likely to be able to get to safety), and there are fewer lives involved, not to mention being heavier armed and have more firepower. Once a weapon is destroyed, how much damage it dealt before taking it down and how much firepower was necessary to destroy it typically makes it obvious how large of a threat it is.

quote:

---

Another related problem is one of creating variants. For example, perhaps I''ve created two vehicles which have the same hulls, the same weapon, the same engine, but they differ in only one respect...the amount of armor. So perhaps UnitA thinks, "Aha, this is a Type97 Main Battle Tank, my M570 125mm rifle should have a pretty good chance of taking it out even against a front glacis hit". Afterall, UnitA has seen this type of Unit before, so why shouldn''t it think this way? But when the shells start bouncing off the Type97A1 tank''s hull, then perhaps UnitA might realize something was fishy.

---

They have the same class -- land-based mobile heavy armor. In a combined arms battle, the same units would be dispatched to deal with it, whether it was known or not that the new tanks have heavier armor. When this is discovered (when they see that their bullets are bouncing off of it), a similar unit with more firepower would be dispatched.

quote:

---

All of this suggests two things. One is that all Units (or their AI Commanders) must have access to a database of known unit types.

---

This implies a blackboard architecture for your AI (I think there was an article on this).

quote:

---

Secondly, a Unit must have some Sensor capabilities which allow it to define certain ThreatClass members, but not necessarily all.

---

Boost optional to the rescue.

I would like to expand on TechnoGoths perceived threat. Part of the threat should be scaled due to weapons vs. units. Setup a table.
25mm gun has multiplier of 1 vs infantry but only .2 vs armor.
Flamethrower has 1 vs infantry and 0 vs armor
Rail gun has .2 vs inf and 1 vs armor.

You get the idea. If the vehicle is sporting an unknown weapon ( to that unit) add a new line in the table and start filling in the info as its tested.

quote:

---

Original post by Thermodynamics
I would like to expand on TechnoGoths perceived threat. Part of the threat should be scaled due to weapons vs. units. Setup a table.
25mm gun has multiplier of 1 vs infantry but only .2 vs armor.
Flamethrower has 1 vs infantry and 0 vs armor
Rail gun has .2 vs inf and 1 vs armor.

You get the idea. If the vehicle is sporting an unknown weapon ( to that unit) add a new line in the table and start filling in the info as its tested.

---

I considered that part of the situational modifers part of relative threat. Since that depends on the 2 units involded.

-----------------------------------------------------
Writer, Programer, Cook, I''m a Jack of all Trades
Current Design project
Chaos Factor Design Document

quote:

---

Original quote by Flarelocke
The real question is not how to assess this. The only correct answer is that you can''t. The real question, is, how do you behave in the presence of incomplete information? Depending on how incomplete you information is, any of: abort mission, "test" the threat, or continue mission as if it was known that the new threat was acceptable. These are essentially the same options as an unknown enemy formation.

---

I was thinking about this very issue right after I posted this thread, and I started realizing that my real problem wasn''t so much how to retrieve the information, but in how to relate the perceived threat with the Orders that have been given to it.

I''ll get to this topic in another thread once I sort out in my head what exactly I''m trying to say

quote:

---

The danger of one class of delivery system to another is usually consistent. Bombers are dangerous to fortifications, fighters are dangerous to bombers, helicopters are dangerous to tanks, etc. So the assessment is simply a matter of raw power (unknown) + what class of delivery system is this platform? This is usually pretty easy to guess. When you have no other information, whether something is land based, air based, or sea based is a pretty good indication of its vulnerabilities and strengths.

---

Well, the problem is that it isn''t always consistent. Think for a second of tanks in a city versus infantry in a city. Out in wide open plains, tanks rule the roost against other ground elements. But put it in a city, and all of a sudden, it should become very afraid of simple infantry armed with RPG''s and molotov cocktails. Imagine for a second instead that you have some infantry going up against a vehicle armed with a gauss gun. The relative threat level should drop because gauss guns aren''t very effective against dispersed infantry, though they would be very effective against other armored vehicles. I''m trying to get away from Units as being derived types (Base class = Vehicle, derived classes are things like Main Battle Tank, Armored Personnel Carrier, Infantry Fighting Vehicle, Self-Propelled Artillery, or for planes things like Fighter, Interceptor, Attack, etc etc). Instead, vehicles in my system are really nothing more than HullModules in which other subsystem Modules (like OffenseModules which are weapons, or DefenseModules which are things like Armor or smoke screens for example) are plugged into.

So there still has to be some kind of way for Units to "discover" the capabilities of enemy Units.

quote:

---

Original quote by TechnoGoth
absolute threat: Is the rating used by the units owner, it dervied by knowing all the units cababilites. Its weapon, speed, armor, etc..

perceived threat: this is the value that is derived by an opposing commander based on the information gathered by observation and espionage? Whenever a new unit is encountered its capabailites and threat rating is set to zero. As new information is gathered these zero are assigned values. Such as if you see it moving you know its speed.

Relative threat: is calculated based on the percieved threat of an opposing unit, the absolute of the current unit, as well as any situational modifers. The releative threat value will be used by the units AI to determine its course of action.

so for example:

---

While I was thinking this issue through a little more, I came to the realization that there were many more factors that needed to be accounted in the Threat Assesment. Here''s just a list off the top of my head:

1) Terrain- Does the terrain affect weapon types or does it make escape less likely?
2) Quantity- How many enemy units within attack range?
3) Damage- Have Units from either side been damaged?
4) Morale- Are the Units in contact routing? Are they charging?
5) Discipline- Are you fighting crack troops or ill-trained fodder?
6) Leadership- Are the units under an inspiring commander or an incompetent one?
7) Situational Awareness- How are your flanks doing? Is another part of the battle going really well or really badly?
8) Fatigue- Closely related to morale is fatigue. If your troops are exhausted, they don''t fight as well, and route easier.
9) Supplies- are you out of ammo? fuel? Think not only of how this affects combat performance, but morale (would you want to face the enemy knowing you only have 5 rounds left but there''s more than 5 opponents?)

So there does indeed need to be some kind of algorithm developed which includes all of these factors to derive a Relative Threat level. However, I don''t think we have to go into a Perceived Threat level because the Relative Threat Level must be measured against two primary things: The AI Commander''s Cluster''s capabilities (a Cluster in my game is a grouping of Units which is led by an AI Commander....Clusters in turn make up BattleGroups) and the Order which has been given (either by the Player to the Commander, or by a higher ranking AI Commander).

I''m starting to think that there are two seperate questions I''m asking here. The first is how a Unit can gather information about enemy details, and the second is that once as much of this data is gathered as possible how a Plan of Action is formulated depending on the comparison between the Relative Threat level and the Goals and Prioritizations of the Order object that has been given. As Flarelocke pointed out, perhaps the greatest issue is how the AI reacts to "missing" or unknown information.

You'll still need to include percieved threat since that is the threat level that your side has derived about an enemey unit. As to relative threat there can be be any number of calculations you can do it. It all depends on how much detail you want to include in your gae.

From there you just can just use AI strategies to define actions for diffrent Relative threat ranges.

for instance Cowardly AI:

RT:=Action
-100 to 0 = retreat
1-20 = hit and run
21-100 = engage and persue.

Aggressive AI:
-100 to -80 = hit and run
-79 to 20 = engage
21-100 = persue

thats just a rought example. But Like i said it will be determined by implementation.

-----------------------------------------------------
Writer, Programer, Cook, I'm a Jack of all Trades
Current Design project
Chaos Factor Design Document



[edited by - TechnoGoth on December 12, 2003 10:09:55 PM]

quote:

---

While I was thinking this issue through a little more, I came to the realization that there were many more factors that needed to be accounted in the Threat Assesment. Here''s just a list off the top of my head:

1) Terrain- Does the terrain affect weapon types or does it make escape less likely?
2) Quantity- How many enemy units within attack range?
3) Damage- Have Units from either side been damaged?
4) Morale- Are the Units in contact routing? Are they charging?
5) Discipline- Are you fighting crack troops or ill-trained fodder?
6) Leadership- Are the units under an inspiring commander or an incompetent one?
7) Situational Awareness- How are your flanks doing? Is another part of the battle going really well or really badly?
8) Fatigue- Closely related to morale is fatigue. If your troops are exhausted, they don''t fight as well, and route easier.
9) Supplies- are you out of ammo? fuel? Think not only of how this affects combat performance, but morale (would you want to face the enemy knowing you only have 5 rounds left but there''s more than 5 opponents?)

---

That''s pretty good. From the Art of War:

quote:

---

Therefore, appraise it in terms of the five fundamental factors and make comparisons of the seven elements later named.

The first of these five factors is moral influence; the second, weather; the third, terrain; the fourth, command; and the firfth, doctrine.

By moral influence I mean that which causes the people to be in harmony with their leaders, so that they will accompany them in life and unto death without fear of mortal peril. [i.e. morale]

By weather I mean the interaction of natural forces; the effects of winter''s cold and summer''s heat and the conduct of military operations in accordance with the seasons.

By terrain I mean distances, whether the ground is traversed with ease or difficulty, whether it is open or constricted, and the chances of life or death.

By command I mean the general''s qualities of wisdom, sincerity, humanity, courage, and strictness. [leadership in your list]

By doctrine I mean organization, control, assignment of appropriate ranks to officers, regulation of supply routes, and the provision of principal items used by the army [This encompasses discipline and supply]

...

[The seven factors:]
If you say
which ruler possesses moral influence,
which commander is the more able,
which army obtains the advantages of nature and the terrain,
in which regulations and instructions are better carried out,
which troops are the stronger,
which has the better trained officers and men, and
which administers rewards and punishments in a more enlightened manner, I will be able to forecast which side will be victorious and which defeated.

---

The quantity, fatigue, damage, and situational awareness are dealt with in another chapter (you never start a war fatigued or damaged, and quantity is pretty obvious). By my count, the only thing your list omits is weather/season/climate.

It seems to me that all of these factors are important in all decisions that need to be made, and not just in assessing the threat of a particular unit in a particular situation. So we need some more general way of utilizing these factors. Perhaps some sort of "absolute" threat level, modified by conditions. Somehow this solution seems inelegant to me.