Global AI Interface

[SpliFF]

Thanks. I wish to finish my SupCom projects before getting too deep into the Spring internals. Once I have time though I am happy to get involved in engine development.

For now though I simply propose the list of functions above as requested in the topic title and hope others can make headway in the meantime.

[Mortuis]

I think that probablistic tactic decision would be very interesting. An AI which is "perfect" should not be predictable. So rather than having a perfectly calculated AI that will be predictable over time with the game, a random process could really make an AI opponent harder to beat.

[LoidThanead]

On the other hand, if the AI acts only randomly, it will not be much of a challenge. It will try to do a lot of stupid things.
Ideally, in my opinion, an AI should randomly select one of a number of 'good' strategies.

Also, an AI should be aware of the ultimate goal of the game. For example, when playing BA, it should take very good care of its commander, if the game is set to end when the commander is destroyed.
Is there a way to have the AI get game objectives or settings from the mod?

[hoijui]

Is there a way to have the AI get game objectives or settings from the mod?

hmm.. good point, never though about this so far. the only way for AIs to do this at the moment (and in the new interface aswell), is to read the mod option values. but that is not a good way to do it of course, as each AI needs code for parsing these things, and they have to support the mod specific options anyway...
maybe we would need a common format for some mod options, which the mod creaters could follow, and then we could have a callback function for AIs to fetch the mod options (this would be an easy one)

[LoidThanead]

In an ideal world, an AI developer could retrieve a set of objective objects from the engine. Each objective would specify a unit or area and what to do with it. For example, in BA, it might contain the unitID of the commander, and an enumerator value saying 'do not let this be destroyed.' Or in some other mod, it could indicate an area on the map (a point and a radius, or the coordinates of a polygon, maybe?) and a enumerator value 'protect' or 'reach with so many of unit x.'
Maybe we could even include optional time limits? 'Destroy building x within 10 minutes or you lose the game.'

Though, something like this could get complicated. How would we indicate an objectice like 'destroy all enemy commanders?' You would need to differentiate between hostile and friendly units. Maybe even between own and allied ones?
It would be ideal if every individual unit in the had its own, unique ID. (As in, you can still tell the difference between two units of the same type.) I don't know if this is already possible?

If we had something like this, it would be possible to create a truly all-purpose AI. It might not be perfect, but at least such an AI should be able to sort of effectively play nearly any mod, if the objectives are relayed properly.

[yuritch]

Every unit in Spring has both a unitdef id (identifying the kind of unit it is) and a unit id (identifying this particular unit), so specifying one or several units by their ids is very possible.

[hoijui]

hmm.. these objectives will only come from the mod, right? or could there be map specific objectives aswell? or even other stuff?
anyway.. the AI would just receive these things... it seems to be up to mod and map devs to define a way to define such objectives. guess it will end up in some LUA format

[LoidThanead]

Though, if AI developers could outline exactly what they'd need, it would certainly save time for anyone wanting to actually implement it.
The way to get people to implement additional features for you is to make it as easy as possible for them. (And as little work as possible.)
Besides, the clearer we outline what we'd like to have, the more likely we're to get something actually resembling it.

Your comment on maps got me thinking. Some types of objectives are inevitably linked to a map.
I have not played any mods besides BA, which is undoubtedly a shortcoming on my end, so I don't really know what mods are out there. However, I can imagine a 'defence' mod, where you have to hold a certain area for an x amount of time. This area would vary with each map. And if you played that same map with any other mod, the area would probably have a completely different significance, or none at all.
So objectives would have to be both dependent on the mod and the map? Mods would vary the objectives they give the AI depending on the map? Maps would hold map-specific objectives per mod? I don't see an easy way out of this one...

[hoijui]

Though, if AI developers could outline exactly what they'd need, it would certainly save time for anyone wanting to actually implement it.
The way to get people to implement additional features for you is to make it as easy as possible for them. (And as little work as possible.)
Besides, the clearer we outline what we'd like to have, the more likely we're to get something actually resembling it.

If in a special mod, you have to ensure that unit X survives, then of course hte AI has to know that, if it should work well. It does not need an AI dev telling this to a mod dev, for him to know that. Also, the mod devs know best what is special in their mods, and it is their duty to provide info to AI devs in a portable way, and therefore, it should also be them deciding how to store/transmit this data. it Is the AI devs duty to then use this data.

i would say, that AIs should receive all objectives from the engine directly. they may not even have to know which objective comes from the mod or the map or whatever.

maybe we should define a simple format for objectives.
for a start (pseudo code):

Code: Select all

class Objective {
   int id;
   string name; // [optional]
   string description; // [optional]
   float importance; // 0.0 = unimportant, 1.0=game-loss/win
   // or
   int importance; // 1=low, 2=middle, 3=game-loss/win
   int target; // 1=map-area, 2=unit, 3=unitDef
   // depending on target, some of the following
   // will be important
   int obj_map; // 1=defend, 2=capture
   int obj_unit; // 1=protect, 2=kill, 3=capture, 4=positionAt
   int id_unit;
   int obj_unitDef; // 1=protect, 2=kill, 3=capture, 4=build
   int id_unitDef;
   int obj_unitDef; // 1=protect, 2=kill
   int limit; // 1=none, 2=time, 3=event
   int limit_time; // seconds
   int limit_event; // 1=unitDied, 2=unitCaptured, ...
}

yeah, this is ugly...
someone else should do it :D

[LoidThanead]

If in a special mod, you have to ensure that unit X survives, then of course hte AI has to know that, if it should work well. It does not need an AI dev telling this to a mod dev, for him to know that. Also, the mod devs know best what is special in their mods, and it is their duty to provide info to AI devs in a portable way, and therefore, it should also be them deciding how to store/transmit this data. it Is the AI devs duty to then use this data.

You are right, in that an AI developer should not try to tell a mod developer what data to send. However, in order for communication to be effective, it would be benificial for both parties to work together to put together a format that ensures the mod can send whatever information it wishes to the AI, and that the AI will know what it means. Basically, the Objective pseudo-code you provided is already a good step in this direction.

i would say, that AIs should receive all objectives from the engine directly. they may not even have to know which objective comes from the mod or the map or whatever.

I agree. The AI has no need to know which objectives come from the mod, and which from the map. What I meant to convey was that I wonder how the generation of mod and map dependent objectives would work behind the scenes, since I see this becoming rather complex. Then again, I know very little about the internals of mods and maps, so I could be completely wrong.


Your Objective draft seems to cover all mentioned points, and even some more.
I'm a little curious about your reasoning behind the 'importance' field? In my opinion, only restrictions that are directly related to winning or losing classify as objectives.
If something is of 'middle' importance, this means that it is not strictly nescessary to accomplish this task to win the game, nor will it cost you the game if you fail at it, am I right? If so, the described task is probably something that helps the AI play well, some kind of hint? Something like this could be useful indeed for effective AI play.

[hoijui]

I'm a little curious about your reasoning behind the 'importance' field? In my opinion, only restrictions that are directly related to winning or losing classify as objectives.
If something is of 'middle' importance, this means that it is not strictly nescessary to accomplish this task to win the game, nor will it cost you the game if you fail at it, am I right? If so, the described task is probably something that helps the AI play well, some kind of hint? Something like this could be useful indeed for effective AI play.

ehh yeah, good idea! it could be "ab-"used to give AIs hints :D
maybe it should be specially marked then as AI-hint, cause the other objectives could/should be used for players too.
the importance:
well there are games, where yo uhave optional objectives. if you fullfill/pass them, you may get a special unit or osme money or whatever.

[LoidThanead]

I had no idea there were games with bonus objectives. I should really play some diferent mods. :)

Perhaps it would make sense to include the details of the reward as well?

Code: Select all

int reward_type; // 1 = resource, 2 = unit, ...
int reward_resource_type; // 0 = metal, 1 = energy, 2 = money, ...
float reward_unit_type;
float reward_amount; // amount of the specified resource or unit awarded

The only problem with this is that this only works if there is only one type of unit or resource being given. Maybe it should all be int/float arrays instead of just ints/floats?

[slogic]

I had no idea there were games with bonus objectives. I should really play some diferent mods. :)
...

Before planning an interface for objectives you should first get the full info about possibilities of mod & map (i do not personally aware of them). What objectives can they make right now? If any, then any designed interface will loose. So, AI will support a limited number of mods & read mod/map config directly. This will be USUAL behaviour in current conditions (when mod/map can have versatile objectives).

[AF]

May I remind people that there is no point in asking for features to be backported to the legacy AI interface, and it is counter productive

Why?

Because the legacy AI wrapper that implements this interface, sits on top of the C API.

The new C++ wrapper interface also sits as a wrapper over this API.

Therefore there is nothing stopping you from instantiating the core objects using the static methods, and using the new C++ wrapper interface alongside the legacy APIs.

• A more modern OO thought out interface is available
• No need to convert every single callout to the new interface
• Both interfaces can be used interchangeable as well as the C API for a third
• More information
• Things missing from the legacy API are made available immediately without dredging through the C API or waiting for it to be added in a new spring release