#### Archived

This topic is now archived and is closed to further replies.

# Rethinking orders

This topic is 5549 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
I am at work so I''ll keep this short.

Heuristics.

Basicly weight each action with a value and situations are used as modifiers. Add them up and the action with biggest value get chosen.

For example, A commander has a choice to fight or flee.
Action - Stay and fight 10
Situation - Out numbered -3
Situation - Ambush -2

Action - Flee 5
Situation - No backup +2

Stay and fight = 5
flee = 7
Our commander should flee.

Individual commanders can have diferent personas. If a commander is trigger happy then his ''stay and fight'' base action could 15 instead of 10 and would still be fighting in our example.

This would in turn efect gameplay as you wouldn''t send commander Trigger Happy on a recon.

##### Share on other sites
As always in these situations, we look first at real life and then make abstractions.

In real life, an order is issued to a commander in direct control, occasionally with a few constraints, who then decides exactly how to accomplish the objective. In other words, Freewill is always virtually at a maximum (depending, of course, on the level of constraint). The commander then evaluates knowns, such as the objective, identified obstacles, geographical data, etc and creates a plan or course of action.

This plan is then executed with continuous reevaluation (the plan will consist of a number of stage markers, so it would logically be reviewed at each stage attained without incident). If an unexpected quantity is encountered before a stage marker is reached, a decision must be made. For example, if the commander comes across enemy units, does he take evasive action or engage? It depends on his objectives - if stealth is an objective, then evasive action is the logical course. If the company is discovered while taking evasive action, then the new decision is whether to engage or retreat - evaluated in the light of higher objectives.

Obviously, the system "devolves" (ie, is abstracted to) a response evaluator taking bits of "knowledge" or "information" as input and generating a course of action as output. This level of inference is only necessary for the AI commander, while the individual troops can respond on a much more primitive level (avoid incident fire, gain strategic advantage, eliminate enemy, follow orders, etc).

##### Share on other sites
StaticVoid-
Good idea on the Commander''s set of "statistics" by which he can gauge the appropriate course of action. Since I''m not too familiar with GA''s or NN''s though, isn''t it possible to have the Commander himself alter these statistics?

For example, let''s say the Commander''s "stay and fight" statistic is set to 15. However, after several battles in which his units always get mauled, some kind of "fitness" metric is used to analyze his performance. Therefore the Commander slowly figures out, "gee, maybe it''d be better if I fall back this time", and his "stay and fight" score now drops to a 13.

##### Share on other sites
Oluseyi-
I''m guessing I''m going to have to come up with some sort of "World_Knowledge_Domain" which basically deal with the "evaulation" aspect of carrying out Orders.

For example, the Commander must have some way of evaluating the threat level of another group, he must understand the pro''s and cons of certain kinds of terrain, the pro''s and cons of which weapon''s are at his disposal, what formation is best to deal with certain groups etc etc. The other aspect I was thinking that you brought up was the problem of reevaluating steps.

In my game, real time phases are broken up by Order phases. Basically for a minute, the game progresses in real-time, and all Commanders and Units update their positions, their status, and their last actions in various Manager classes. During this minute, situations can arise that were not accounted for, in which case the Order may need to be reassesed. The trick is in figuring out how this reassesment is triggered.

Going back to my earlier ambush example, it would imply that the Commander continuously polls the environment updating his own internal knowledge of the world. When a new as yet unknown target appears...a corresponding change in his "knowledge" occurs. Now the Commander has to evaluate whether the priority of his Order overrides the threat, whether his own survival instincts kick in, or if an "Opportunity" presents itself (what if the target turns out to be a lightly guarded command headquarters for the enemy?).

Now, this seems like an awful lot of computing cycles going on, because each Commander is continuously polling the environment to check to see if there are any changes going on which may require a reassesment of his Orders. But I''ve already decided that the RealTime_Manager class will in turn go through a container class of all the Commanders in the game (I''m not sure what kind of container, but I''m guessing some kind of map would be best so that it can hold certain key values...though I''m not sure how fast maps are). Now that the RealTime_Manager has access to the Commander, it calls the Commander''s AI. This AI class in turn will do six things in this sequence: 1) Update World_Data 2) Update Status_Info (things like morale, UnitIntegrity, supplies) 3) Examine Order object 4) Do a Threat assesment 5) Do an Opportunity Assesment 6) Carry out action. All steps but 3 will cycle through the loop during the real time phase.

My concern with this is that it''s not really simultaneous action for all the Commanders. Instead one Commander goes through all the steps, then the next Commander, etc etc. I suppose I could do steps 1-5, then store the action away...then and only then have all Commanders execute the action. This way, the actions of the first Commander won''t trigger the Threat Assesment stage of the 5th Commander that goes.

##### Share on other sites
quote:
Original post by Dauntless
For example, the Commander must have some way of evaluating the threat level of another group, he must understand the pro's and cons of certain kinds of terrain, the pro's and cons of which weapon's are at his disposal, what formation is best to deal with certain groups etc etc.

In real life, yes. In a simulation, however, we abstract this. Each unit/group/object should define its own advantage and disadvantage - potentially in several categories - and its affiliation (including neutral), such that evaluating the threat/potential gain becomes simple arithmetic. The base values and rules for appreciation and deprecation of [dis]advantage should be developed by the designers and placed in data that is dynamically bound to the game world (meaning that new units can be added or values can be tweaked without needing to rebuild the game engine).

quote:
In my game, real time phases are broken up by Order phases. Basically for a minute, the game progresses in real-time, and all Commanders and Units update their positions, their status, and their last actions in various Manager classes. During this minute, situations can arise that were not accounted for, in which case the Order may need to be reassesed. The trick is in figuring out how this reassesment is triggered.

Asynchronous execution. It's like the collision detection thing where people wonder if it makes sense to have all their 1000 objects polling the environment for collisions every frame. The solution in each case is to forecast when the next "collision" will occur (even if the Commander is unaware, the game world knows that given his current trajectory he will encounter hostile forces as juncture X). Every time trajectory changes, a recomputation of the altered group's impending collisions occurs (constrained to a reasonable radius, so you're not performing the equivalent of seeing whether a car in Brooklyn, NY will hit a pedestrian in Trenton, NJ) and the new value is entered into the world data table. At the point where a collision is registered, the Commander is then messages to reevaluate circumstances.

I keep coming back to this thing of maintaining "internal" knowledge "externally"...

quote:
[Text intentionally omitted; context established.]

My concern with this is that it's not really simultaneous action for all the Commanders. Instead one Commander goes through all the steps, then the next Commander, etc etc. I suppose I could do steps 1-5, then store the action away...then and only then have all Commanders execute the action. This way, the actions of the first Commander won't trigger the Threat Assesment stage of the 5th Commander that goes.

Look up round-robin processing (also look up multitasking). You let each task execute for a short amount of time, save its state and move on to the next task, giving the illusion of simultaneous execution. You can implement it manually, or you can resort to multithreading to accomplish it (note that eventually the overhead of context switches in multithreading make it less than ideal). I've also read about it being done using sockets (wait, accept, block-type thing).

[Edit: Formatting.]

[edited by - Oluseyi on March 18, 2003 8:41:16 AM]

##### Share on other sites
The more I think about it, the more I think it would make more sense to have the World_Data and Status_Info classes be external managers which the Commander has access to. I think it''d be easier for the RealTime_Manager loop to query a seperate World_Data_Manager and Status_Info_Manager to retrieve the necessary information rather than go through each and every Commander object. Now, if I do make the World_Data a friend of the Commander class...should it be a two way relationship, or would this mess up the very data encapsulation properties that make it an advantage? Personally, I don''t really see the World_Data class ever needing to access the Commander directly, but the Commander does very often need to access World_Data.

As for the multi-taksing bit, I guess that''s what I was crudely envisioning when I thought about doing steps 1-5, saving the data, for each Commander, going to the next Commander, and so on until all Commanders have gone through steps 1-5. Then step 6 gets executed for each Commander.

Oh man, my head hurts already thinking about this stuff...and I haven''t even really thought about how the AI works, or how I''m going to link all of this to the graphics component....sigh. I definitely think creativity is my stronger suit as opposed to programming (not saying that programming ISN''T creative, but it''s also a lot more formal and technical than my brain wants it to be)

• 10
• 17
• 9
• 14
• 41