Regarding the fitness metrics for commander learning, I have a suggestion. After each battle, have a debriefing session where you can replay the whole conflict. During the replay, your commanders would highlight their key decision points and reveal the factors they were considering, and the alternatives they were exploring. As you say Dauntless, different orders have different goals, so any decision they make will presumably be weighed against several goals, i.e. survival of the unit, accomplishment of the mission, etc. The commanders can reveal how each of the possible alternatives scored against each of these goals, and which goal was judged to be the most important at the time. Having reviewed these inputs into the decision yourself, you can then point out what you would have done in the same situation.
I have not done much AI programming myself, but from what I have read, this sort of personal involvement in the learning process of a neural net can be very effective at imparting the teacher''s own style. This is something that would not be achieved by using a coded fitness metric, because that would have nothing to do with the player (and it''s probably asking a bit too much to expect the player to write such a thing with the scripting system). Of course the down-side to this approach is that the commanders would not learn anything during the battle itself, only during the debriefing.

Plasmadog

Interesting idea. That would definitely allow the player to "teach" his Commanders what he liked and didn''t like thereby reinforcing behaviors. The downside is as you mentioned the AI not learning in the game itself.

I really need to study more about AI, but there don''t seem to be many books on the subject. I''m mostly concerned at this point as to what qualities the AI Commanders will need to effectively use them, hence this post being in Game Design as opposed to AI. In other words, I need to nail down the problem domain so that I can figure out what the AI is capable of, and how it will do it, and what it will require to implement it.

Actually, I think that if you were to use some sort of hard-coded fitness metric, you could get some sort of in-battle learning, and then refine that during the debriefing. But I suspect that combining the two methods might be problematic. It might require that any lessons learnt during a battle be temporary, and forgotten as soon as the battle is over. I say this because if you were to make a correction during the debrief, it may somehow invalidate any in-game lessons that were learnt after that. That''s just a gut feeling I have. Maybe someone with a better understanding of neural nets could clarify this?

The real drawback to this method is that in order for your "lessons" to make sense, you''d really need to see all the inputs into the AI''s decision making process. As I understand it, most strategy game AIs use techniques that don''t quite reflect the way a person would think about the situation. So, you would either have to come up with some more human methods (which will probably run slower), or you have to reveal the dodgy techniques that the AI is built on. Tough call.

By the way, every year at about this time (just after the GDC), Game Developer magazine usually has a write-up on the state-of-the-art in AI techniques. If you haven''t already, you should check out the past articles. I have found them to be an interesting source of ideas.

i once made a ''game'' where you appointed commanders and seniority, and the commanders would draft other units and commanders into their squad, and then function semi autonomously.

-all squads are built for a reason, therefore, you need some amount of intelligence (prefereably 100% knowall and everything) about the enemy and scenarios.
-having your ai formulate its own scenarios in real time is a bad idea. instead, you need to have a base of scenarios which can be generalized.

IN REAL LIFE, the weapons, formation, and methods a squad uses are determined by specific scenarios.

by scenarios, i mean modes that a squad can go into. for instance, if your squad needs to capture a bridge, then it goes into a ''capture building'' mode.
in this mode, you will have any number of sub scenarios that can be triggered by various events, and dictate formations, methods, victory conditons, etc. such as ''take bridge'', ''gaurd/fortify bridge'' or even ''destroy bridge'', if it was a capture or destroy mission. notice the use of the logical OR there.

if you have a commander, then he understands the generalized capabilities of his force. when he wants to do something, he queries his sub commanders, they intern query their sub commanders, etc. when a base-commander receives a query, he can examine his force and determine if it can do or aid in the task, and send his answer back up the chain.

you need tactical and strategic scenarios. the higher a commander is, the more strategic scenarios he has, and the less tactical ones he has. the lower a commander, the more tactical scenarios he has, and the less strategic.

Strategy is the long term stuff, the overall goal stuff. for instance, "take the gold mine so they run outta money", is a strategy. the tactics are have 2 guys snipe cover the entrance and perimiter, have 3 guys take out the power and raid the com center, and have 1 guy keep the chopper ready. tactics are very complex because they are layered very complexly. for instance, the 3 guys in the com center have specialized tactics, like formations.

the commander is the guy that formulates the proper scenario, and may also create a rule base. every unit is actually a sort of commander, but, all commanders answer to a higher commander, like yourself. if two guys break from the squad to go snipe the entrance, then one of them has senority, and can order the other one around. this is very important.

a basic grunt unit should have NO scenarios available to him. instead, he has personal tactics and orders. a low level guy should not have to do ANY thinking about tactics, commanders think about tactics. for instance, he doesnt decide to snipe officers from the tower, instead, his commander tells him to climb the tower and snipe officers.

he does however have reactant responses, if he is attacted, discovered, or comprimised, then he can fall back on his training or other orders.

there needs to be a heirarchy of trainning, and orders.
you will ideally have a series of trees and such.
for isntance,
//orders (single branched) action to do
kill ''nationA'' or
kill ''enemies in area A'' or
retreat

//rules A (single branched) used to determine if action is legal
protect = not comprimise

protect nation
protect self
follow orders and protect squad
kill enemies

//rules B (multi branched) used to determine action sub actions/ overrides
//branch priority is broken left to right by OR
accomplish objective and hide
accomplish objective and protect squad or hide and protect squad
accomplish objective or protect squad and retreat or retreat

Plasmadog

That''s another good idea. Have both kinds of implementations...a hard coded set of rules that will gauge whether the Commander did the right thing or net, as well as briefings on what the unit did or didn''t do right. Although I was thinking that in the debriefing method, the programmer would have to create a sort of log for each commander on it''s various which may incredibly memory intensive. I haven''t picked up the latest GameDeveloper mag yet, but I will when it comes out.

EvilCrap

Good ideas. I was thinking of something along similar lines. As a sort of rough draft, I imagined there to be two basic considerations for officers. There is a letter code signifying the type of Commanders, and a number designating the actual rank. There are 4 basic "types" of Commanders, F for "Field", O for "Operations", E for "Echelon" and S for "Support". So for example you could have the following kinds of Commanders:

F1 2nd lieutenant, field commander platoon size (unit)
F3 Captain, field commander company size (OU)
04 Major, field operations for Battalion size (CG)
E7 Brigadier General, commanding a Division (CG)
S2 1st Lieutenant, liason officer assisting an E7

F types are the basic low grade officers that actually interface with the smallest units, or actually command the smallest defined Organized Unit. These are the kinds of officers that fight along side by side with the grunts at the frontline. They operate almost solely at the tactical level. They may do some limited plan formulations, but are basically reactionary officers rather than proactive in their actions. They await orders from higher up.

O types are Operational officers, and what I mean by this is that they are middle men between the low tactical level concerns of the field officers, and the warroom type generals that do the strategical planning. They have to be able to turn abstract concepts from the high level E type officers, and turn them into slightly more concrete actions for the field officers. Most of these officers also are on the frontlineline, but in more secure areas. These Commanders are generally attached to specialized COU''s, Command Organized Units and are not often found organically attached to a fighting OU.

E types are the very high level staff of officers that fight in war rooms in modern eras or way in the back lines in older times, though in some cases these Commanders can be in the frontline. They do the very abstract level of thinking and are generally the first points of contact with the player''s avatar. Because usually only very highly ranked officers can be E types, they generally have access to lots of resources as well.

S types are a catchall for commanders that serve specialized roles. This can be Communications officers, Intelligence Officers, Liason Officers, Air Controllers, Artillery Coordinators or any other specialized task that is not organically attached to a fighting OU and which have specialized as opposed to generalized capabilities.


Why all this level of detail? Different types of commanders need to be programmed differently. The E types will be thinking of very strategic orders on a massive scale and in non-concrete terms, whereas the F commanders have to actually interface with the OU to make it "behave". The other question is probably, "why not just factor this all into rank? the higher the level of rank, the more abstract they are." That''s true, but there are two reasons not to do that. One is that I want a customizable Army, so therefore one Army might be organized like this:

F1,F2,F3,O4,O5,O6,E7,E8

and another like this:

F1,F2,O3,O4,O5,O6,E7,E8,E9

See the difference? The latter army has a lot more "middle management" and more high level commander types, but not many field officers.

So the next question is probably, "what does rank signify, what capabilities does it give?". At its most basic, rank gives access to interface with units, with OU''s, and at higher levels, CG''s. Rank also determines access to other military support services such as how directly they can call in reinforcements, what kinds of close combat support (artillery, close air, orbital, etc.), medical evacuation, or other kinds of support.

Hopefully things are starting to get more clear on how exactly the commanders will work, and what capabilities I''d like them to have. Hopefully it''s also becoming more clear what is required for Commanders to interface with units, OU''s and CG''s, but I''ll save that for later