If we're gonna have any chance of an AI we need an engine interface and I'd prefer to build a basic AI interaction layer between the Engine and the General co-ordinators in control of the units to handle things such as threat overlays before anything else. In other words what information do we need fromthe engine how do we intend on gettign it and in what form should it arrive as? Perhaps some input on what the SY's have already done would be especially useful.
And before those of you start pouncing on me sayign that teh SY's have said no support for skirmish AI or what not, I say to you, what chance is there of a future version of spring with support for an AI if we dont discuss it now?
AI Engine Interface
Moderator: Moderators
From the engine the AI requires positions and types of each unit, to be assessed from the threat/value data tables, so that the threat/value of each square can be determined.
At the same time the values of the resources at maximum for each grid in the matrix need to be determined, to allow for the offensive/defensive matrixes to be accounted for. The resources need only be determined once to set up the defensive matrix, while the offensive matrix will change depending on the control of the square in the threat matrix.
Possibly a control percentage value should be introduced, using the number of enemy buildings, or units on the square, and the number of friendly units to determine who controls it. If it is completely in hand, as are the surrounding squares, it's threat value is 0, and it's ignored in the offensive matrix.
The first set of values should be update every other second, and come in a single packet, unless there is no change, and a single digit will be sufficient to relay the message.
The second set of values needs to come once only for the defensive, and then it can be dropped again in a single packet. The offensive value should be changed everytime there is a percentage change in the control percentage. Because of the frequency that this happens, it might require a I/O digit for each unit, instead of mass data packets, because of the sheer numbers that can be brought to bear.
Unless anyone has a better idea?
At the same time the values of the resources at maximum for each grid in the matrix need to be determined, to allow for the offensive/defensive matrixes to be accounted for. The resources need only be determined once to set up the defensive matrix, while the offensive matrix will change depending on the control of the square in the threat matrix.
Possibly a control percentage value should be introduced, using the number of enemy buildings, or units on the square, and the number of friendly units to determine who controls it. If it is completely in hand, as are the surrounding squares, it's threat value is 0, and it's ignored in the offensive matrix.
The first set of values should be update every other second, and come in a single packet, unless there is no change, and a single digit will be sufficient to relay the message.
The second set of values needs to come once only for the defensive, and then it can be dropped again in a single packet. The offensive value should be changed everytime there is a percentage change in the control percentage. Because of the frequency that this happens, it might require a I/O digit for each unit, instead of mass data packets, because of the sheer numbers that can be brought to bear.
Unless anyone has a better idea?
I'm thinking thre are other things needed if you deal with terrain threat matrixes that should have a factor such as height and flatness of a grid sector.
Who controls the sector should be gaged so that fi your threat value 2/3's fo the total value of that sector then you control it, half and it's contested a 1/3 or less means loosing the sector.
And so I go back to the dual matrix system and maybe with betternames than offensive and defencive. Threat and Value(or maybe something else as here we have threat values and Value values) or soemthign else along the lines of worth or importance, I beleive my original words where strategic overlay so I'll use that.
Ai wants:
Higher strategic values for own sectors and it wants to keep control of high value strategic areas. Resources and factories occupy these areas so unit types are needed aswell as unit production stats.
To lower enemy threat values and keep away from areas of high threat values.
So we'd need general terrain features such as how flat it is and how high it is.
I'm saying that each sector of the threat and strategic overlays/matrixes should be about the size of a krogoth gantry, and the AI builds buildings on a grid of squares at such a size placing the buildings on flat squares with no building in the centre, the AI should also Issue commands to atatck all units in a sector rather than a specific unit. But I aint too sure about what that means in terms of what information is needed save what I've already listed.
Perhaps the AI should make use fo the Experience systems discussed in soem of the other threads so experienced untis are a bigger threat so an exp value is needed.
And when you say unit type do you mean Aircraft ship or kbot? or Maverick peewee or pelican?
As for units I think the AI should handle all mobile units save construction units and thigns liek commanders as groups, in other words you'd have an array fo group structures each with a small array of simple unit sructures
I'm gonan have to seperate this up into the different AI layers on new threads
RAW VALUES
unit type
resource stats
Terrain flatness
Terrain Height
unit positions
unit health
unit experience
metal values
DERIVED VALUES
threat matrix
strategic matrix
unit groups inside ones own faction
Enemy unit destination // you cant just see a huge mass of units and ignore the direction its going in can you?
Who controls the sector should be gaged so that fi your threat value 2/3's fo the total value of that sector then you control it, half and it's contested a 1/3 or less means loosing the sector.
And so I go back to the dual matrix system and maybe with betternames than offensive and defencive. Threat and Value(or maybe something else as here we have threat values and Value values) or soemthign else along the lines of worth or importance, I beleive my original words where strategic overlay so I'll use that.
Ai wants:
Higher strategic values for own sectors and it wants to keep control of high value strategic areas. Resources and factories occupy these areas so unit types are needed aswell as unit production stats.
To lower enemy threat values and keep away from areas of high threat values.
So we'd need general terrain features such as how flat it is and how high it is.
I'm saying that each sector of the threat and strategic overlays/matrixes should be about the size of a krogoth gantry, and the AI builds buildings on a grid of squares at such a size placing the buildings on flat squares with no building in the centre, the AI should also Issue commands to atatck all units in a sector rather than a specific unit. But I aint too sure about what that means in terms of what information is needed save what I've already listed.
Perhaps the AI should make use fo the Experience systems discussed in soem of the other threads so experienced untis are a bigger threat so an exp value is needed.
And when you say unit type do you mean Aircraft ship or kbot? or Maverick peewee or pelican?
As for units I think the AI should handle all mobile units save construction units and thigns liek commanders as groups, in other words you'd have an array fo group structures each with a small array of simple unit sructures
I'm gonan have to seperate this up into the different AI layers on new threads
RAW VALUES
unit type
resource stats
Terrain flatness
Terrain Height
unit positions
unit health
unit experience
metal values
DERIVED VALUES
threat matrix
strategic matrix
unit groups inside ones own faction
Enemy unit destination // you cant just see a huge mass of units and ignore the direction its going in can you?
I disagree on the size of the grids. The main threat and value grids should be at least screen size, as should the offense/defense grids. The build grids should be much smaller.
Second, whether the AI knows what units are on radar is up to the builder of that particular AI. I'm assuming intimate knowledge, for simplicity.
The control percentage is there to estimate the priority of the fight. If the AI controls more than fifty percent of the sector, then the mopping up begins, using the heaviest of units, usually reserved for base defense, while any surviving skirmishers move on. If the AI controls less than fifty percent, it begins sending in addition assault units.
The system I propose uses five separate, and interlinked grids. Threat, Value, Offensive, Defensive and Build grids.
Matrix one: This is the Threat Matrix which keeps track of threats, both incoming, and stationary. It needs for each square in it's grid, the following information: Unit type, position, health and experience. From these values it can determine: Probable Destination, and threat value. The threat value is split into offensive and defensive values. Health and type determine defensive value, type and experience determine offensive value. These values are determined for all sides for each square, and are available to the player, though only the final values.
Matrix two: This is your Values Matrix, and requires the total metal in the square, as well as the maximum amount of energy generated using the basic structure for the terrain. Solars, and Tidals. This is also where the offense/defense values for the defensive matrix are determined. The defensive value is the amount of resources the enemy is trying to protect, along with the offensive power of the defensive units and buildings in the square. The max resource values are available to the player, as are the defensive values for each square.
Matrix three: This is the Offensive Matrix. This uses the defense and offense values generated in the Threat Matrix, to determine the effectiveness of an attack by your forces against an enemy. This uses the value and threat matrixes to determine the most valuable and least defended target to strike.
Matrix four: This is the Defensive Matrix. This uses the defense and offense values from the Threat Matrix, to identify the next likely target of the enemy, and shore it up with standing defenses, and mobile base defenders, such as Sumo's, or Bulldogs. The Value Matrix is used to determine where the next set of the defenses should be laid, to protect vital resources.
Matrix five: This is the Build Matrix. It uses all other information to decide where to place each building. For example, high threat squares would require nearby factories, to produce units to aid in the battles, while defenses should be lain in areas with a low defense, and high value rating. The grids for this are much smaller, subdivided roughly into DT sized squares, with several included flags, which are:
Terrain Type
Elevation
Slope
Metal
Features
Obstructions
Terrain Type is obvious, since you can't build Tidals on land, or solars on the sea.
Elevation is determined on all four sides, in relation to adjoining squares.
Slope is the difference in each side, and is also effected by cross joined squares, such as those on an angle.
Metal is a yes or no question.
Features are things such as Geothermal vents as well as Mexx radii. The latter has two variables. Mex, and Moho. If Mex is tripped, the Moho will still be built by the AI. If Moho is tripped, Mex is tripped by default.
Obstruction is simple, and complex at the same time. An obstructed square can be one of two things. Obstructed Reclaimable (OR), or Obstructed Unreclaimable (OU). OR objects are trees, rocks, unit wrecks, enemy buildings. OU objects are friendly buildings, anything without an assigned metal or energy value, and certain units, like the commander.
Factories are special buildings in regard to the matrix. If they are actively producing units, and are within two squares of the nearest non controlled zone (NCZ), they are flagged OU. If they are inactive, and at least two squares of the nearest NCZ, then they are flagged OR. Air plants are extended to four squares of the nearest NCZ.
Perhaps splitting this up is a good idea. I'm starting to ramble.
Second, whether the AI knows what units are on radar is up to the builder of that particular AI. I'm assuming intimate knowledge, for simplicity.
The control percentage is there to estimate the priority of the fight. If the AI controls more than fifty percent of the sector, then the mopping up begins, using the heaviest of units, usually reserved for base defense, while any surviving skirmishers move on. If the AI controls less than fifty percent, it begins sending in addition assault units.
The system I propose uses five separate, and interlinked grids. Threat, Value, Offensive, Defensive and Build grids.
Matrix one: This is the Threat Matrix which keeps track of threats, both incoming, and stationary. It needs for each square in it's grid, the following information: Unit type, position, health and experience. From these values it can determine: Probable Destination, and threat value. The threat value is split into offensive and defensive values. Health and type determine defensive value, type and experience determine offensive value. These values are determined for all sides for each square, and are available to the player, though only the final values.
Matrix two: This is your Values Matrix, and requires the total metal in the square, as well as the maximum amount of energy generated using the basic structure for the terrain. Solars, and Tidals. This is also where the offense/defense values for the defensive matrix are determined. The defensive value is the amount of resources the enemy is trying to protect, along with the offensive power of the defensive units and buildings in the square. The max resource values are available to the player, as are the defensive values for each square.
Matrix three: This is the Offensive Matrix. This uses the defense and offense values generated in the Threat Matrix, to determine the effectiveness of an attack by your forces against an enemy. This uses the value and threat matrixes to determine the most valuable and least defended target to strike.
Matrix four: This is the Defensive Matrix. This uses the defense and offense values from the Threat Matrix, to identify the next likely target of the enemy, and shore it up with standing defenses, and mobile base defenders, such as Sumo's, or Bulldogs. The Value Matrix is used to determine where the next set of the defenses should be laid, to protect vital resources.
Matrix five: This is the Build Matrix. It uses all other information to decide where to place each building. For example, high threat squares would require nearby factories, to produce units to aid in the battles, while defenses should be lain in areas with a low defense, and high value rating. The grids for this are much smaller, subdivided roughly into DT sized squares, with several included flags, which are:
Terrain Type
Elevation
Slope
Metal
Features
Obstructions
Terrain Type is obvious, since you can't build Tidals on land, or solars on the sea.
Elevation is determined on all four sides, in relation to adjoining squares.
Slope is the difference in each side, and is also effected by cross joined squares, such as those on an angle.
Metal is a yes or no question.
Features are things such as Geothermal vents as well as Mexx radii. The latter has two variables. Mex, and Moho. If Mex is tripped, the Moho will still be built by the AI. If Moho is tripped, Mex is tripped by default.
Obstruction is simple, and complex at the same time. An obstructed square can be one of two things. Obstructed Reclaimable (OR), or Obstructed Unreclaimable (OU). OR objects are trees, rocks, unit wrecks, enemy buildings. OU objects are friendly buildings, anything without an assigned metal or energy value, and certain units, like the commander.
Factories are special buildings in regard to the matrix. If they are actively producing units, and are within two squares of the nearest non controlled zone (NCZ), they are flagged OU. If they are inactive, and at least two squares of the nearest NCZ, then they are flagged OR. Air plants are extended to four squares of the nearest NCZ.
Perhaps splitting this up is a good idea. I'm starting to ramble.
And I disagree with you there, You ahve left many a prospect fo confusion and redundancy. In the big TAI thing I'll be postign when i finish it I'll be sayign why I chose that particular grid size. All overlays have the same general grid size and I ahve put in a compromise for thse who want to deal with whole screen sectors and not krogoth gantry sized sectors. For exampel I can tell the threat of a grid sector whats in it and I can attack sectors themselves and the units inside them based on threat value. Having a screen sized sector would make such abilities useless unless you had hundreds of units and easy access.
And this multi overlay system of threat value as well as offensive and defencive is useless, both the latter can easily be extrapolated from the first two and are just redundant. Can you dynamicaly merge your sectors in these overlays? And if so how? I'd like to see that maybe it'd give me a few more ideas.
And I beleive that units on the radar but outside LOS should effect the AI, I am here to sort out an AI and cheating omniscient AI's do not come into it
And this multi overlay system of threat value as well as offensive and defencive is useless, both the latter can easily be extrapolated from the first two and are just redundant. Can you dynamicaly merge your sectors in these overlays? And if so how? I'd like to see that maybe it'd give me a few more ideas.
And I beleive that units on the radar but outside LOS should effect the AI, I am here to sort out an AI and cheating omniscient AI's do not come into it
-
Anonymous Joe
- Posts: 21
- Joined: 01 Nov 2004, 03:33
Well I think I had outlined all that in a thread somewhere before the boards got nuked...
But basically the above PLUS:
Unit marching orders (where its going, how fast, and a ETA if available)
Unit building orders (whats its building now, and the queue)
Unit meta status (experience level/kills/gaurding/patrol/repairing...)
Visibility(can this unit be seen from here, or is it a radar dot?)
A map matrix, with values describing terrain mobility for various classes of units, spawn points, and possibly mapper defined 'interesting' points.
(for calculating attack routes, and locating optimal base building points)
Game meta data (game type, standard-war, CTF?, teams, ect...)
resource data + maps (how much X does player Y have, places on a matrix that show resource spots)
and a Unit Library, with ALL the info about a unit (so the AI can decide how/what to attack with what. Ex: Seaplanes Vs. Submarines... Artillery Vs. distant buildings...)
Also possibly pre-defined strategy for a map, and rally points IF they are going to exist in a map.
Basically I would like a set of data sturctures and functions that can be called by the library/script with ALL game data visible. read-only of course.
Its the AI-Authors job to decide wether or not to cheat.
Clan-SY can impliment the AI interface however they like. (so long as there IS one)
But basically the above PLUS:
Unit marching orders (where its going, how fast, and a ETA if available)
Unit building orders (whats its building now, and the queue)
Unit meta status (experience level/kills/gaurding/patrol/repairing...)
Visibility(can this unit be seen from here, or is it a radar dot?)
A map matrix, with values describing terrain mobility for various classes of units, spawn points, and possibly mapper defined 'interesting' points.
(for calculating attack routes, and locating optimal base building points)
Game meta data (game type, standard-war, CTF?, teams, ect...)
resource data + maps (how much X does player Y have, places on a matrix that show resource spots)
and a Unit Library, with ALL the info about a unit (so the AI can decide how/what to attack with what. Ex: Seaplanes Vs. Submarines... Artillery Vs. distant buildings...)
Also possibly pre-defined strategy for a map, and rally points IF they are going to exist in a map.
Basically I would like a set of data sturctures and functions that can be called by the library/script with ALL game data visible. read-only of course.
Its the AI-Authors job to decide wether or not to cheat.
Clan-SY can impliment the AI interface however they like. (so long as there IS one)
It does seem redundant, but separating the processes of offensive and defensive command structure means that the AI will be able to focus on individual components of assault, and base construction, and not get stuck attempting to build a base, and attacking the enemy, and being unable to do either.
The multiple matrices are separated into command, control, and informational layers. Threat and value matrices are the information layer. The offensive and defensive matrices are control layer, and the build matrix is the command layer.
The idea in the multiple matrices is to allow the programmers to set up call functions for redundant information. This should simplify the writing of the code, while maintaining functionality.
As for not being omniscent, simply add undetermined values for units that have not been sighted, or that aren't currently insight, and use them as base values. So ground units of a certain speed have certain offense/defense values, and those of different speeds are assigned different values. Air units would have one assumed value, no matter what they really were. Sea units would probably be mistaken as ground units, unless you want to allow for terrain knowledge.
Merging the sectors? I'm not sure what you mean.
The screen size sectors are for the AI only. The computer can instantly access any of it's units without moving it's own screen, and so it can react on those scales. Humans on the other hand can only see what's on the screen, so this would let us focus only on what is on screen. I would include a sector lock for the camera, that would center the camera on the sector with the largest portion of itself on screen.
The multiple matrices are separated into command, control, and informational layers. Threat and value matrices are the information layer. The offensive and defensive matrices are control layer, and the build matrix is the command layer.
The idea in the multiple matrices is to allow the programmers to set up call functions for redundant information. This should simplify the writing of the code, while maintaining functionality.
As for not being omniscent, simply add undetermined values for units that have not been sighted, or that aren't currently insight, and use them as base values. So ground units of a certain speed have certain offense/defense values, and those of different speeds are assigned different values. Air units would have one assumed value, no matter what they really were. Sea units would probably be mistaken as ground units, unless you want to allow for terrain knowledge.
Merging the sectors? I'm not sure what you mean.
The screen size sectors are for the AI only. The computer can instantly access any of it's units without moving it's own screen, and so it can react on those scales. Humans on the other hand can only see what's on the screen, so this would let us focus only on what is on screen. I would include a sector lock for the camera, that would center the camera on the sector with the largest portion of itself on screen.
First off, I'm not sure why an AI interface discussion thread has deviated so far into the realm of implementation. The matrix systems that are being discussed here should not be handled by the server, but rather created by the AI itself with the information the server gives it. Anonymous Joe had the correct type of data needed to be passed to the AI.
The first question that needs to be asked is where the AI will be implemented. The options are client side and server side. Assuming the server is run on a member of the game and not the lobby server itself, server side is not a problem. C++ can start a new process and open input and output pipes to it, creating an interface similar to a network connection but much faster. However, several complex AI's running could slow down the server, and only 1 type of AI could be run without some special considerations.
The second option is client side, either as an independent client or as a spawn of a standard client. A client spawn would act similar to a server side AI, but with pipes to a standard client. The main concern with this is either the networking protocol would need to tag where the information was directed or a 2nd socket (or whatever networking interface is used) needs to be opened. An independent client, unreliant upon other spring programs could be written simply with the knowledge of the protocol depending upon the amount of work the actual client does to make the game run. If the client does most of the actual computing work with the server simply collaborating and verifying everything, the SY's may need to build a framework to make an independent AI possible. If the client is just a graphics drawer and command communicator, an independent client AI my be possible without any help from them at all.
The first question that needs to be asked is where the AI will be implemented. The options are client side and server side. Assuming the server is run on a member of the game and not the lobby server itself, server side is not a problem. C++ can start a new process and open input and output pipes to it, creating an interface similar to a network connection but much faster. However, several complex AI's running could slow down the server, and only 1 type of AI could be run without some special considerations.
The second option is client side, either as an independent client or as a spawn of a standard client. A client spawn would act similar to a server side AI, but with pipes to a standard client. The main concern with this is either the networking protocol would need to tag where the information was directed or a 2nd socket (or whatever networking interface is used) needs to be opened. An independent client, unreliant upon other spring programs could be written simply with the knowledge of the protocol depending upon the amount of work the actual client does to make the game run. If the client does most of the actual computing work with the server simply collaborating and verifying everything, the SY's may need to build a framework to make an independent AI possible. If the client is just a graphics drawer and command communicator, an independent client AI my be possible without any help from them at all.
By dynamically merging grid sectors I mean, if half the maps sector values stay the same, therefore those grid sectors that lay side by side with the same values merge into a larger grid sector or 'supersector'. Thus meanign you can have more grid sectors for less resources. Aswell as a few other consequences that could be of use.
As for simplifying things for coding later i beleive this to still be redundant and I think that it is possible to completely seperate building units and attacking units.
As for simplifying things for coding later i beleive this to still be redundant and I think that it is possible to completely seperate building units and attacking units.
I would have thought that there aren't that many things you could actually request of the engine before you get into the realms of AI implementation. The list of raw values early in this thread mostly sums it up. If anything I prefer to think of it in human terms. What would the player be able to see?
I would anticipate there being two different interfaces. Firstly a cheating AI interface then a non-cheating AI interface. The cheating interface would probably be the first to be implemented as it would likely be a lot easier. The non-cheating interface would come afterwards. By and large both interfaces would give access to the same data but the non-cheating would place an additional 'security' layer between the engine and the AI, preventing the AI from seeing everything and forcing it to explore in order to gather information.
Here's what I would expect the interface to provide:
Map:
Elevations (V)
Resources (V)
Basic Unit Data:
Types, Weapons, Stats
Build Tree
Unit-Map Data:
Unit types, locations & velocities (V)
Unit health, ammo (e.g. nuke), veterancy (F)
Unit orders (+queue) (F)
Explosions/Projectiles (V)
(V) = only where visible for non-cheating AI
(F) = only applies to friendly units for non-cheating AI
I would anticipate there being two different interfaces. Firstly a cheating AI interface then a non-cheating AI interface. The cheating interface would probably be the first to be implemented as it would likely be a lot easier. The non-cheating interface would come afterwards. By and large both interfaces would give access to the same data but the non-cheating would place an additional 'security' layer between the engine and the AI, preventing the AI from seeing everything and forcing it to explore in order to gather information.
Here's what I would expect the interface to provide:
Map:
Elevations (V)
Resources (V)
Basic Unit Data:
Types, Weapons, Stats
Build Tree
Unit-Map Data:
Unit types, locations & velocities (V)
Unit health, ammo (e.g. nuke), veterancy (F)
Unit orders (+queue) (F)
Explosions/Projectiles (V)
(V) = only where visible for non-cheating AI
(F) = only applies to friendly units for non-cheating AI
Yes, then the sectors merge that way. A sector is only updated if it's changed since the last update. Otherwise it's ignored. A flag would be added to determine if it's changed, and which matrix information has changed, so that only that particular matrix needs to pay attention. Only the values matrix is updated across the board, but it only occurs once at the start of the game, because of the differences in screen size. Any other time, it's only in a particular sector, and probably because of a terraforming operation.
The build matrix uses a similar method, except the values are not updated unless they're changed, and sectors under a building foot print are counted as a single sector the size of the print. Any over hang is counted in and considered unbuildable.
Having the Matrices seperated into the three C.C.I. layers means that you can have an AI access only whatever information you want it to. And making it so the matrices only update on LOS information shouldn't be difficult.
It's supposed to be redundant AF. Otherwise the computer will forget something, and be rendered ineffective. Sometimes the simplest solution is the best, and in this case, that's to be sure every piece is operating from the same information. It also makes for less information to be gathered, since it's being reused. This means the processor isn't putting as much effort out to keep the AI fighting, and can be used for other things, such as the rest of the program.
The build matrix uses a similar method, except the values are not updated unless they're changed, and sectors under a building foot print are counted as a single sector the size of the print. Any over hang is counted in and considered unbuildable.
Having the Matrices seperated into the three C.C.I. layers means that you can have an AI access only whatever information you want it to. And making it so the matrices only update on LOS information shouldn't be difficult.
It's supposed to be redundant AF. Otherwise the computer will forget something, and be rendered ineffective. Sometimes the simplest solution is the best, and in this case, that's to be sure every piece is operating from the same information. It also makes for less information to be gathered, since it's being reused. This means the processor isn't putting as much effort out to keep the AI fighting, and can be used for other things, such as the rest of the program.
The good thign about computers is they dotn forget things. To keep thigns simple you want to have as few sources to pool your data from as possible while at the same time getting the most data you could possibly need, which is efficient and memory saving not to mention faster.
Also dynamic grids wouldnt work that simply, what fi the AI wants to query grid sector number 30 but wait a sec didnt that merge with 33 26 and 24 and finally became grid sector number 24? So how dow e address that missing sector? And what happens when I want to split the sectors up again? Do I rewrite allt he values for the entire matrix so they're ordered properly? Well I have a solution to that in my post for the AI Agents thread which is really where this stuff should be posted. I'm guessing I should hurry up with that
Also dynamic grids wouldnt work that simply, what fi the AI wants to query grid sector number 30 but wait a sec didnt that merge with 33 26 and 24 and finally became grid sector number 24? So how dow e address that missing sector? And what happens when I want to split the sectors up again? Do I rewrite allt he values for the entire matrix so they're ordered properly? Well I have a solution to that in my post for the AI Agents thread which is really where this stuff should be posted. I'm guessing I should hurry up with that
So divide the Supersectors during the merge into Subsectors 1, 2, 3, and 4. Doing it my way would eliminate the need to merge them, and let you store them in a block of undisturbed sectors until they change.
But the AI will have to drop things from memory every so often to make sure it has enough head space, and then it will forget things. This plans around that, because it's replacing the old values with the new, and doesn't drop anything.
But the AI will have to drop things from memory every so often to make sure it has enough head space, and then it will forget things. This plans around that, because it's replacing the old values with the new, and doesn't drop anything.
Ok It seems I'm gonna ahve to telly ou what I had in mind rather than leave it to my big TAI post.
2 overlays threat and strategic
Sectors and subsectors.
A sector is Screensized
A sub sector is krogoth gantry sized.
The AI can deal with either the full sector or subsectors.
The Ai deals with sectors and subsectors when dealing with attack and defence rather than enemy units themselves.
It has no sense of unit types rather it just sees different types of threats based on weapon range power unti experience and nubmers, air sea etc.
All information is extrapolated from functions that give data about a sector or subsector.
When dealing with ones own units they're dealt with as groups.
Subsector arrays are pointers to an overral array of structures, merging sub-sectors means giving them the same pointer and deleting the redundant memory created as a result. A subsector address would take the form [sector],[subsector]. I'll go into it in more detail tomorrow, but trust em I've been thinkign and I have a general idea on an overral threat based AI and I'm just trying to finetune and put it down on paper
2 overlays threat and strategic
Sectors and subsectors.
A sector is Screensized
A sub sector is krogoth gantry sized.
The AI can deal with either the full sector or subsectors.
The Ai deals with sectors and subsectors when dealing with attack and defence rather than enemy units themselves.
It has no sense of unit types rather it just sees different types of threats based on weapon range power unti experience and nubmers, air sea etc.
All information is extrapolated from functions that give data about a sector or subsector.
When dealing with ones own units they're dealt with as groups.
Subsector arrays are pointers to an overral array of structures, merging sub-sectors means giving them the same pointer and deleting the redundant memory created as a result. A subsector address would take the form [sector],[subsector]. I'll go into it in more detail tomorrow, but trust em I've been thinkign and I have a general idea on an overral threat based AI and I'm just trying to finetune and put it down on paper
Very interesting. The problems come in close combat unit to unit. They'll have to deal with other units, and can't simply bombard the square, and that's where the AI will foul up, as the units break into their own combat protocols. Without the ability to fire through it's own units, they'll start to fire across each other, and begin to decimate it's own forces to the point that a single Zipper will be able to demolish most AI attack forces. It won't have to fire a single shot, but simply let them kill each other.
That's why I added the offensive matrix to my system, so it can use the close combat units against fast units like that so it can't fire through, and at itself.
Tall missile towers might aleviate your problem to an extent, unless the aim bug has not been corrected, in which case the problem is worse than before.
That's why I added the offensive matrix to my system, so it can use the close combat units against fast units like that so it can't fire through, and at itself.
Tall missile towers might aleviate your problem to an extent, unless the aim bug has not been corrected, in which case the problem is worse than before.
-
NapalmEnima
- Posts: 4
- Joined: 03 Mar 2005, 17:49
Triaxx, I think that's just in terms of overal AI strategy... the individual unit behavior would be directed normally (hold fire, defend, fire at will/hold still, tethered, free roam).
So units being directed to a [sub?]sector based on the the threats present would react according to their set behavior (probably fire at will / roam-or-tethered). Every unit should have a 'react to stuff' radius large enough to cover a subsector, so the relatively course resolution at the strategic level shouldn't be a problem at the tactical level.
So units being directed to a [sub?]sector based on the the threats present would react according to their set behavior (probably fire at will / roam-or-tethered). Every unit should have a 'react to stuff' radius large enough to cover a subsector, so the relatively course resolution at the strategic level shouldn't be a problem at the tactical level.
Yes overral AI uses sectors to atatck. An agent is told that this sector should eb attacked. The agent gathers data and selects another agent to carry out the attack giving it a set of sectors as a target. The Agent that finally deal with this would ave control over single units and not unit groups or sectors. It would target units and buildings within that sector.
As for radius reactions etc, the same sub AI behaviours that cause this in human player units would do the same in AI exept that the AI Agents invovled would be notified of thsi and a suitable Agent would be chosen to co-ordinate the attack by issuing an attack command to that sector.
I've thought this out as much as possible and then some, I have 100 minutes of computer time now so I'll finish writting up as much as possible on TAI then post what I have in parts part 1, 2 etc
As for radius reactions etc, the same sub AI behaviours that cause this in human player units would do the same in AI exept that the AI Agents invovled would be notified of thsi and a suitable Agent would be chosen to co-ordinate the attack by issuing an attack command to that sector.
I've thought this out as much as possible and then some, I have 100 minutes of computer time now so I'll finish writting up as much as possible on TAI then post what I have in parts part 1, 2 etc