TAI part 4 Command queues rules the roost
Posted: 16 Apr 2005, 21:17
/*TAI Part 4
The queue to end all queues
So it came to me that we could take commands for units and put them into a script or at least into a queue then copy the queue over to other units or set a factory to automatically give built units the command queue. Of course I now realise a much better use fo trying to get the most out of this system.
If you can make a Factory assign a queue to a unit once it's built then you can assign a factory a build queue and the construction unit a build queue of factories and resources that come from factories. So if you could tell a commander to assign itself a command queue at the beginning of the game and include logic in that queue based on surroundings then yu could essentially create a simple AI.
So what would become of the idea of an AI made totally of a large collection of command queues auto assigned?
Such an AI while providing a simple AI would show a highly customisable AI, however it wouldn't be able to react in the way Sun Tzu would require it to unless you specifically scripted sets fo queues for every map game type and player which is absurd.
So I suggest that TAI brings in a new set of agents, unit agents. A unit is given an instance of a save agent. The AI doesn't bother telling units where to go other than groups to large sectors. These scripts would deal with Micromanagement and would essentially simply be told what to do with no real complexity.
So what do we make all these scripts in? I think I should rule out compiled languages. A language that's easy and popularity, such as Java, or Perl. I'm guessing some sort of Socket layer with an immediate abstraction layer on top providing basic functions and data structures such as the threat array and move here and is anything there type functions. Thus any person could wander into the folder and change the AI to suit them. A basic unit control class for each type would be needed, attack: sea air ground mixed, const: ground sea air mixed Building, and modders could create their own class for custom units through inheritance.
Seeming as most people already have Java and wouldn't want to download active Perl, and the greater portability of Java, I'd say Java was the better to use. So We would have an immediate abstraction layer built in C++ as a dll for the engine that would provide a sockets layer to a Java program which would contain the 'unit agents' and 'system agents'. Unit agents being those that receive basic commands and carry them out and system agents being those that deal with big things and not specific units.
So we have a hovercraft agent a ground agent and amphibious agent a sea agent an air agent a defence agent and a factory agent. All of which accept general commands such as go here attack sector with tactic where a tactic is a class derived from the original class.
System agents would be in two types, those that react to events and those that run at timed intervals. For example resources would be a timed interval, and the construction agent would be event based. Thus an event can be termed as receiving a command or request from another agent.
So a simplistic AI could be*/
//Start AI
MAIN(){
defstructs();
//INITIALISE SYSTEM AGENTS
BUILD build = new BUILD
//SET STARTPOS
float3 startpos = getunitpos(1);//1 being the Unit ID of the first unit, which I'm guessing would be the commander.
//START TIMER
//EVERY MINUTE INITIALISE TIMED AGENTS AGAIN FOR RE-RUN
}
IF (/*MAP COVERED BY RADAR*/){
break;
}
ELSE {
FIND EDGE NEAREST TO STARTPOS = XY
WHAT IS BEST ARADAR AVAILABLE = BUILDING
BUILD.REQUEST( BUILDING , X, Y, NEAREST);
}
}
void DefStructs(){
struct queue{
int BuilderID
int BuiltID
}
}
class BUILD {
/*build agetn, deals with building and deciding wether a build request should go ahead wether it an be built there and thus need moving and wether the resources are available to build it. */
public:
int Request(int UNITID,int X, int Y, char PREFLOCATION[8]);
void queueAdd(int UNITID,int X, int Y, int PRIORITY);
protected:
queue
private:
};
BUILD::Request(int UNITID,int X,int Y, char PREFLOCATION[8]){
IF (CANBUILD(X,Y) = FALSE){
SWITCH (PREFLOCATION){
case 'NEAREST':
//CODE TO FIND NEAREST GRID SECTOR THAT CAN BE BUILT ON
IF (X-NEARESTX>(1SECTOR || -1SECTOR)){
return false;
}
break;
case 'ANYWHERE':
//CODE TO FIND NEAREST SECTOR AGAIN
IF (THREAT(XY); => 1.5*AVERAGE THREAT){
return false;
}
break;
}
}
int PRIORITY = BUILDPRIORITY(UNITID,X,Y)
this.queueAdd(UNITID, X,Y, PRIORITY);
}
void Sight::AddScout(int UnitID){ // for when scout is built and handed over
//FIND NEAREST EDGE OF LOS TO STARTPOS
//SET WAYPOINTS OF UNITID TO PATROL EDGE.
}
class Sight{
public:
void AddScout(int UnitID);
int RmvScout(int UnitID);
protected:
int Scout[100];//stores the Unit ID's of the scous that've been handed over
private:
}
// I├óÔé¼Ôäóll keep changing this post to be ever more full but I thought the general idea needed to be put across so I could get comments since the comments well seems to be drying up and needs new life.
//Argghh I had a terrible head cold when I wrote this so dont be too
//antagonising over errors. Erm I dunno if i should ahe said antagonising
The queue to end all queues
So it came to me that we could take commands for units and put them into a script or at least into a queue then copy the queue over to other units or set a factory to automatically give built units the command queue. Of course I now realise a much better use fo trying to get the most out of this system.
If you can make a Factory assign a queue to a unit once it's built then you can assign a factory a build queue and the construction unit a build queue of factories and resources that come from factories. So if you could tell a commander to assign itself a command queue at the beginning of the game and include logic in that queue based on surroundings then yu could essentially create a simple AI.
So what would become of the idea of an AI made totally of a large collection of command queues auto assigned?
Such an AI while providing a simple AI would show a highly customisable AI, however it wouldn't be able to react in the way Sun Tzu would require it to unless you specifically scripted sets fo queues for every map game type and player which is absurd.
So I suggest that TAI brings in a new set of agents, unit agents. A unit is given an instance of a save agent. The AI doesn't bother telling units where to go other than groups to large sectors. These scripts would deal with Micromanagement and would essentially simply be told what to do with no real complexity.
So what do we make all these scripts in? I think I should rule out compiled languages. A language that's easy and popularity, such as Java, or Perl. I'm guessing some sort of Socket layer with an immediate abstraction layer on top providing basic functions and data structures such as the threat array and move here and is anything there type functions. Thus any person could wander into the folder and change the AI to suit them. A basic unit control class for each type would be needed, attack: sea air ground mixed, const: ground sea air mixed Building, and modders could create their own class for custom units through inheritance.
Seeming as most people already have Java and wouldn't want to download active Perl, and the greater portability of Java, I'd say Java was the better to use. So We would have an immediate abstraction layer built in C++ as a dll for the engine that would provide a sockets layer to a Java program which would contain the 'unit agents' and 'system agents'. Unit agents being those that receive basic commands and carry them out and system agents being those that deal with big things and not specific units.
So we have a hovercraft agent a ground agent and amphibious agent a sea agent an air agent a defence agent and a factory agent. All of which accept general commands such as go here attack sector with tactic where a tactic is a class derived from the original class.
System agents would be in two types, those that react to events and those that run at timed intervals. For example resources would be a timed interval, and the construction agent would be event based. Thus an event can be termed as receiving a command or request from another agent.
So a simplistic AI could be*/
//Start AI
MAIN(){
defstructs();
//INITIALISE SYSTEM AGENTS
BUILD build = new BUILD
//SET STARTPOS
float3 startpos = getunitpos(1);//1 being the Unit ID of the first unit, which I'm guessing would be the commander.
//START TIMER
//EVERY MINUTE INITIALISE TIMED AGENTS AGAIN FOR RE-RUN
}
IF (/*MAP COVERED BY RADAR*/){
break;
}
ELSE {
FIND EDGE NEAREST TO STARTPOS = XY
WHAT IS BEST ARADAR AVAILABLE = BUILDING
BUILD.REQUEST( BUILDING , X, Y, NEAREST);
}
}
void DefStructs(){
struct queue{
int BuilderID
int BuiltID
}
}
class BUILD {
/*build agetn, deals with building and deciding wether a build request should go ahead wether it an be built there and thus need moving and wether the resources are available to build it. */
public:
int Request(int UNITID,int X, int Y, char PREFLOCATION[8]);
void queueAdd(int UNITID,int X, int Y, int PRIORITY);
protected:
queue
private:
};
BUILD::Request(int UNITID,int X,int Y, char PREFLOCATION[8]){
IF (CANBUILD(X,Y) = FALSE){
SWITCH (PREFLOCATION){
case 'NEAREST':
//CODE TO FIND NEAREST GRID SECTOR THAT CAN BE BUILT ON
IF (X-NEARESTX>(1SECTOR || -1SECTOR)){
return false;
}
break;
case 'ANYWHERE':
//CODE TO FIND NEAREST SECTOR AGAIN
IF (THREAT(XY); => 1.5*AVERAGE THREAT){
return false;
}
break;
}
}
int PRIORITY = BUILDPRIORITY(UNITID,X,Y)
this.queueAdd(UNITID, X,Y, PRIORITY);
}
void Sight::AddScout(int UnitID){ // for when scout is built and handed over
//FIND NEAREST EDGE OF LOS TO STARTPOS
//SET WAYPOINTS OF UNITID TO PATROL EDGE.
}
class Sight{
public:
void AddScout(int UnitID);
int RmvScout(int UnitID);
protected:
int Scout[100];//stores the Unit ID's of the scous that've been handed over
private:
}
// I├óÔé¼Ôäóll keep changing this post to be ever more full but I thought the general idea needed to be put across so I could get comments since the comments well seems to be drying up and needs new life.
//Argghh I had a terrible head cold when I wrote this so dont be too
//antagonising over errors. Erm I dunno if i should ahe said antagonising