This is long, so I grouped suggestions by type and then documented what the actual API requests would be.
Coordination with other AI, or a human player:
Although we can get the damage done to the AI's unit with UnitDamaged() this appears untrue for Ally units. If an AI is assisting another player, we would need a way for them to communicate or get information from ally units. Getting information on ally units would probably be the simplest method, and AI's can be programmed to respond using GotChatMsg to things like "help defend" or "assist attack 5" "help metal" based on getting ally info. For the first command all that is necessary is knowing when ally troops are damaged, and their unit ID. For the second command, assisting an attack would involve knowing the GetFriendlyUnits() for allies, but it would not know which units to assist. If the ally could share group listings, and the position of each unit in a group could be reference, the AI could send troops to assist. I did not see the ability to share metal for "help metal" but it could possibly be done by calling the same function that the UI uses.
Calculating Combat effectiveness:
UnitDamaged returns the attacker, but not the weapon type. If we know the weapon type it would allow us to estimate which unit armor is more effective versus which weapons. For example, Lasers vs Mavericks in OTA.
The AI interface does not have a means to know how much damage its units do to the enemy, which unit they are, or information about the unit. The targeted unit may be different from the damaged unit.
We can calculate range by radar, line of sight, etc, but not hit or miss. For all we know, we are shooting terrain.
Movement:
InitPath returns the path from one point to another, and estimates could be gathered from the rate of movement (barring changes in velocity from collisions) so that appropriate lead time could be used for artillery, rockets, nukes.
GetElevation may be used to identify chokepoints, but in practice we would need to know the difference between submarine, ship, kbot and vehicle chokepoints. This may be a lack of knowledge on my part, but I don't know if the paths are flagged for specific unit types or not. If it is, then we could determine vehicle chokepoints vs kbot chokepoints using path information. Also, the width of the available path may also be important. The AI may want to select a wider vehicle only path for all troops so they don't get killed one by one. (side path in Hells Path)
Suggested API calls:
Coordination
AllyUnitDamaged() return unit data on ally when ally unit damaged (toggle this on/off for performance reasons?)
GetAllyGroups() return a list of each players groups, one array per ally.
GetAllyUnitGroup() Return the int ally group id for a unit
GetUnitByAllyGroup() return an array of units belonging to a group, so the AI can fetch location information
Combat Efficiency
UnitDamaged() add int weaponID to the list, or some other more appropriate mechanism that can be referenced by unit data. If the AI tracks this information separately that is fine, but how will a unit that fired, but was destroyed before the attack hit be referenced? I don't know when the unitIDs are removed.
UnitDoesDamage() An optional (for performance) callback that returns damage done, weapon id (or better), damage, location of unit damaged, etc. One array per unit damaged.
? UnitMiss, UnitAttack? How can we determine hit or miss? The time it takes from weapon firing to weapon hit? We can lookup weapon reload time, but not weapon fire to hit time. This is important if we calculate lead times for weapons. We could also assume that if we had a unit fire event per weaponid, that we could just wait until the UnitDamaged returned, and count the time. If the time exceeds a certain value, count it as a miss. This approximation may create problems for rapid fire weapons, and I doubt we want tracking numbers for each bullet fired in the AI. A UnitMiss(or UnitDamaged with 0 damage) and UnitAttack should be sufficient to get the information we want.
Movement
Uncertain how paths work at this time, this information may already be provided.
Engine
I noticed that the game could be recorded, and we can set whatever time value we wanted up to 50x game speed. Could we have a UI-less game for testing purposes? That way we could script games to run all night long for testing, scan the logs for exceptions, win vs loss and so on without actually watching. If we want to watch how one game crashed, we could view the recorded game.
These are my initial reactions to reading the API, I don't know if this is the current API because I have not verified it in CVS. I am reading some code from CVS now, but I didn't research this to that point yet. Please treat mistakes leniently, and I am open to all suggestions and criticism.
Suggestions to the AI interface
Moderators: hoijui, Moderators
ahem.
Nearly everything you said can already be done bywork arounds or usign existing calls. For example a choke point can be a sub point by testing the average hgiht of the bottom and tops against the water height, etc.
Paths for pathfidnign arent unti type specific, thus tot ell what theya re you need to have the unitdefinition of the original unit using the path.
However i do suggest one addition you suggested, which weapon destroyed the unit.
I also think that an explosion() event is needed, and perhaps a GetDecals(), afterrall if an AI comes across a trakc ro a large epxlosion makr it should coutner those into its decisions, afterrall if my lone fark was to come across lots of big vehicle tracks I'd be worried that there'd be heavy tanks nearby.
Nearly everything you said can already be done bywork arounds or usign existing calls. For example a choke point can be a sub point by testing the average hgiht of the bottom and tops against the water height, etc.
Paths for pathfidnign arent unti type specific, thus tot ell what theya re you need to have the unitdefinition of the original unit using the path.
However i do suggest one addition you suggested, which weapon destroyed the unit.
I also think that an explosion() event is needed, and perhaps a GetDecals(), afterrall if an AI comes across a trakc ro a large epxlosion makr it should coutner those into its decisions, afterrall if my lone fark was to come across lots of big vehicle tracks I'd be worried that there'd be heavy tanks nearby.
i will probably make a few units to test out what works and what doesn't... Can you confirm that is the appropriate setting?
Another item of note: I was able to use a krogoth to make my own path up a hill after enough explosions deforming the terrain. This seems obvious perhaps, but the implications are big.
Also, another map an enemy commander blew up and made a little lake in the middle of my base. It is possible to completely block someone off using terrain deformation techniques.
Another item of note: I was able to use a krogoth to make my own path up a hill after enough explosions deforming the terrain. This seems obvious perhaps, but the implications are big.
Also, another map an enemy commander blew up and made a little lake in the middle of my base. It is possible to completely block someone off using terrain deformation techniques.
How would an AI read that information?
The interface documented how to send messages, but I don't see a function call to receive them. Are they autocollected? some callback function? My suggestion was being able to read messages from users... another way of doing this I suppose would be ".ai stuff" but I personally don't think every AI programmer should have to write commands in order to receive information.
The interface documented how to send messages, but I don't see a function call to receive them. Are they autocollected? some callback function? My suggestion was being able to read messages from users... another way of doing this I suppose would be ".ai stuff" but I personally don't think every AI programmer should have to write commands in order to receive information.
There are a few things I want to be able to do at chokepoints:
1. Fortify a nearby area (found the checkpoint, now build turrets to defend it)
2. Make them more accessible through mine laying, extraction, construction with bulldozers, or ranged attacks. A nonblocking way to increase height would also be nice.
3. Block off a checkpoint and make it not accessible. Dragons teeth are pretty effective at this, but they can also be destroyed.
4. Flag the chokepoint for use in tactics like snipers and rockets in the hills.
About the data:
MaxSlope has legal values 0-255 with 10-20 being typical. It is defined for buildings as well as units, and used for placement. (Rest of this post is about me getting a clue, and trying to share it with the patient readers. Some speculation on algo mixed throughout.)
There is a type based definition in Moveinfo.tdf (gamedata folder for OTA) that sets default values which can be modified.
Based on the interface, data storage in maps, and data storage in units I have some ideas, but they keep changing faster than I can write them well at the moment. Will post again soon...[/code]
1. Fortify a nearby area (found the checkpoint, now build turrets to defend it)
2. Make them more accessible through mine laying, extraction, construction with bulldozers, or ranged attacks. A nonblocking way to increase height would also be nice.
3. Block off a checkpoint and make it not accessible. Dragons teeth are pretty effective at this, but they can also be destroyed.
4. Flag the chokepoint for use in tactics like snipers and rockets in the hills.
About the data:
MaxSlope has legal values 0-255 with 10-20 being typical. It is defined for buildings as well as units, and used for placement. (Rest of this post is about me getting a clue, and trying to share it with the patient readers. Some speculation on algo mixed throughout.)
There is a type based definition in Moveinfo.tdf (gamedata folder for OTA) that sets default values which can be modified.
Code: Select all
[CLASS1]
{
Name=KBOTSF2;
FootprintX=2;
FootprintZ=2;
MaxWaterDepth=12;
MaxSlope=11;
}
[CLASS2]
{
Name=TANKDS2;
FootprintX=2;
FootprintZ=2;
MaxWaterDepth=100;
MaxSlope=32;
}
ahem,
There is a GotChatMsg(const char* msg, int player) itnerface function in both GroupAI and GlobalAI interfaces.
Also choke points, I think you're usignt he rong idea there. Look over voronoi diagram research, I'll be posting a great mass of it soon.
In a voronoi diagram as described in gabbas research, if based on obstacle configuration sapce, the vertexes of the diagram represent open spaces, and the lines represent corridoors. By analysing the level of firecover a path provides, its trafficability and its visibility, you can tell much more than wether it's a choke point or not.
Also be aware that nto everythign needs an extra callback function, especially after the readfile functionw as added allowing us to manualyl parse the definition files and pull out extra tags the engine ignored.
There is a GotChatMsg(const char* msg, int player) itnerface function in both GroupAI and GlobalAI interfaces.
Also choke points, I think you're usignt he rong idea there. Look over voronoi diagram research, I'll be posting a great mass of it soon.
In a voronoi diagram as described in gabbas research, if based on obstacle configuration sapce, the vertexes of the diagram represent open spaces, and the lines represent corridoors. By analysing the level of firecover a path provides, its trafficability and its visibility, you can tell much more than wether it's a choke point or not.
Also be aware that nto everythign needs an extra callback function, especially after the readfile functionw as added allowing us to manualyl parse the definition files and pull out extra tags the engine ignored.
Where is Gabba's Voronoi diagram research? I see spatial systems, but most of the diagrams are based on points with space around them. Is this similar to playing minesweeper? hit a few dots and see where the change in elevation is?
In looking up how units move, I found that some units would experience difficulty while others would not. A smooth slope of 15 would be impassable to most vehicles but traverseable by kbots.
I have been thinking on this a lot, and I know there is a lot of math that can help, but I was busy trying to prepare the information. I think we would need a new Voronoi diagram for each unit's MaxSlope, and possibly another for each Weapon ID. Also, it would need to be recalculated for terrain deformity, wreckage and trees.
I am not only looking for chokepoints, I am trying to figure out what can be altered. Why not blow up a mountain if it is in your way and you have the firepower? Why not reclaim wreckage? Why not blow up or bulid dragon's teeth on Hells Pass?
Thanks for the GotChatMsg info, I figured there was something. The general issue I see with just clicking the map is that may only convey one type of information: attack. I need to look into this more of course, I am still very new to Spring as well.
In looking up how units move, I found that some units would experience difficulty while others would not. A smooth slope of 15 would be impassable to most vehicles but traverseable by kbots.
I have been thinking on this a lot, and I know there is a lot of math that can help, but I was busy trying to prepare the information. I think we would need a new Voronoi diagram for each unit's MaxSlope, and possibly another for each Weapon ID. Also, it would need to be recalculated for terrain deformity, wreckage and trees.
I am not only looking for chokepoints, I am trying to figure out what can be altered. Why not blow up a mountain if it is in your way and you have the firepower? Why not reclaim wreckage? Why not blow up or bulid dragon's teeth on Hells Pass?
Thanks for the GotChatMsg info, I figured there was something. The general issue I see with just clicking the map is that may only convey one type of information: attack. I need to look into this more of course, I am still very new to Spring as well.
Look at his pdfs he posted, specifically the ones he said where of great relevance to AI researchers. It talks about configuration space and generating it from the map and obstacle polygons. It then talks about using those polygons to generate voronoi diagrams.
And yes a deformability calback would be nice.
And yes a deformability calback would be nice.