AI that adapts game difficulty level

[Quintaxel]

Has anyone tried to write a script or knows about a script that somehow 'senses' the players strenght and adapts the gameplay accordingly ? What I mean is that the AI player (or the game) would become harder to beat when the player is also very good so both 'elite' players and less experienced players could enjoy the same map.
A player could also play the same map again but on another difficulty level. The AI would adapt to his skills.
In the past I experimented with maps in which the player could select a difficulty level at the beginning of the game. That's easy and straightforward to program but hardly 'intelligent'.

[Major Pain]

It can be done, but the code is heavy and complex.

I continue to urge someone to step up and learn the LUA Code basics.   Once they understand the basics, they will naturally learn the undocumented functions and capabilities.   One day it just all comes together.

EDIT Afterthought:

In the above statement I did not answer your question.   Allow me to go more in depth on this subject.

Imagine an AI that learns the player's habits or style, then counters using measures designed to impede or focus attacks on key elements within the Player's unit inventory.  Consider Hunter/Killer units the AI will use to take out the player's command structure.

Imagine an AI that can and will use every available resource it has in its control to beat you.   If you attack a left flank, the AI counters by moving units laterally to provide support or perhaps a counter offensive on your opposing flank.

Imagine an AI that screens one way and attacks somewhere else.

Imagine a Mission where every single resource has a name in the system.   Your scouts are working in advance of your main force and spot a fortified position.   Your scouts report exactly which enemy are present using a Display Function. 

Imagine a Mission where the use of multiple random nested functions creates a situation where the same map plays an unlimited numbers of way and nearly impossible to duplicate.   Along with this, your arriving reinforcements may not always in the same place or where you expect.   Alternately, the enemy landed reinforcements can come from anywhere at anytime.

Imagine a mission where the Player's actions determine how the AI responds or predicts the player's next actions.

Imagine where the AI not only uses its eyes and it ears.   This equalizes the field giving the AI the ability to detect a player's tanks long before they can be seen.   The player already has this capability.

All of the above can be done with LUA.

I should note that BK uses only LUA 4.0, however some of my LUA testing seems to indicate LUA 5.0 is also supported in a few cases.   This undocumented aspect offers additional functions.

LUA fully supports arrays, variables and global parameters.   This exactly how data is passed between maps.

The Script and Language has not been exploited to it's potential.   Most mappers use very simple Scripts, I think because the language appears over their head.   We have done a poor job developing this aspect of the game, myself included.   While I am not a map guy, does not mean I have not worked on them.   The ones I worked on or expanded, focused on scripts that were not considered ordinary.  Many of the scripts I wrote were to develop certain aspects and undocumented functions.  Because LUA is a chuck code or scripting language and step-child of ANSI C, it supports virtually every aspect of C Code Modules.

Documentation is available from several sources, including the gatekeeper/developer: Department of Computer Science of PUC-Rio.

LUA is easy to master if you give it a chance.   Anyone who has ever written in C, C+, C++, C- and even GW-Basic already understands the basics of LUA.   Because LUA is lightweight and fast, it is used world wide as the number scripting language.

Over the years I have been on record saying, when NIVAL employed LUA 4.0 in BK, it was a stroke of Genius.

For those who are interested...   I direct your attention to the following links:

www.lua.org/

www.lua.org/manual/4.0/

lua-users.org/wiki/LuaAddonsArchive

Under the BK Game Engine, 'Enigma', the LUA Script language directly embeds the KEYWORD and Function Tables.   The game engine may directly access the LUA Code, but the Lua Code cannot directly access the GAME ENGINE core.  It is very important to understand this relationship.

I hope this provides some answers.

So again, any mapper that accepts the challenge to work in the LUA code, with the desire to research, test and expand the Scripting, can be expected to become the MASTER MAPPER in the community.

There is a vast new frontier waiting for someone to conquer.

 

[feldgrau]

Hi...

function example()
if (any reason) then
Password("Panzerklein");
SetDifficultyLevel(1);
Suicide();
end;
end;

(0)=easy (1)=normal (2)=hard

mbkg Feldgrau

[bb]

Well, using this basic script provided by Feldgrau you can achieve something, for example, if the player get one objective the script could change the dificulty level to hard, for example. But the dificulty level did not change the "challenge" of the map, for example giving more units to the player, it changes the relative values of the units, making a mission on "easy" will make easier to the player destroy enemy units and so on.

Off topic: Major, how about this script:

function len( ... )
local vec = arg[1];

return sqrt( vec.x * vec.x + vec.y * vec.y );
end;



function sqrt( x)
local ITNUM = 4;
local sp = 0
local i = ITNUM;
local inv = 0;
local a, b;
if ( x <= 0) then return 0; end;

if ( x < 1) then
x = 1 / x;
inv = 1;
end;

while ( x > 5) do
sp = sp + 1;
x = x / 5;
end;

a = 2;
-- Newtonian algorithm
while (i > 0) do
b = x / a;
a = a + b;
a = a * 0.5;
i = i - 1;
end;
--
while ( sp > 0) do
sp = sp - 1;
a = a * 4;
end;

if ( inv == 1) then
a = 1 / a;
end;
return a;
end;


function EINSDT101()

local ScriptAreas = {};
ScriptAreas[101] = "V_BR_W_2";


local coeffs = {};
coeffs[101] = 100000;

local delays = {};
delays[101] = 7000;


local ACTION_SWARM = 3;
local PatrolID = 101;
local vector = {x = 0, y = 0};
local center = {x = 0, y = 0}

It's from Moskau map by Baumi, the script have 1978 lines... I dont have a clue what this mean...

[Major Pain]

BB:

I'll try to provide some insight to what is going on in the script you posted.

It is only a portion of what should be there.

function len( ... )

local vec = arg[1];



return sqrt( vec.x * vec.x + vec.y * vec.y );

end;

The above is what we call a function named len( ... )



This defines a variable named vec, which is set to equal to arg[1]

The arg[1] most likely means argument [1] which does not seem to appear in this chuck.



Below we find the function named sqrt(x).   This is initiating a couple of loops, perhaps setting counters and variable definitions

function sqrt( x)


local ITNUM = 4;
  <-----  Here we set the local variable named ITNUM to a value of 4.   This suggest that ITNUM means Initial Number, as in the first number value to be used.

local sp = 0
  <------  Here we set the local variable named sp to the value 0.

local i = ITNUM;
  <----------  Here we establish that the local variable i to the same value of variable ITNUM

local inv = 0;
      <---------- Local Variable inv is set to 0
local a, b;

if ( x <= 0) then return 0; end;
  <-------  This line checks the value of x to determine if x is less or equal to 0; if true, then this function ends


If the above x check value is not true the following lines are executed.

if ( x < 1) then
 <----  here we check the value of x to determine if it is less than 1
x = 1 / x;
   <---  this line changes the value of x to: 1 divided by the value of x
inv = 1;
  <---  we now reset the value of inv to 1.   Above we had previously set the value of inv to 0.
end;
 <-----  and this line ends this chuck



while ( x > 5) do
  <------ the following is a loop where we count and check the value of x... to determine when it is greater than 5.   On each pass in this loop, we are increasing the value of variable sp by 1.   Likely this is a step counter.  As long as x is greater than 5, the loop will continue to run and increase the value of sp.

sp = sp + 1;
 <------ we reset the value of variable sp
x = x / 5;
   <----- we change the value of variable x,  on each pass this variable is also changing.
end;
      <---- this line closes the loop.


a = 2;

-- Newtonian algorithm

while (i > 0) do

b = x / a;

a = a + b;

a = a * 0.5;

i = i - 1;

end;

--

while ( sp > 0) do

sp = sp - 1;

a = a * 4;

end;



if ( inv == 1) then

a = 1 / a;

end;

return a;

end;

If all of the above seems confusing, well it can be until you figure out how to break it all down.   Not all of the code is here to fully understand what the purpose is.   But I can see enough that tells me that we are looking at a chuck of the code which is checking the location of a patrol unit.  The paroling unit(s) is moved from point to point on the map.  The above lines are only the calculators which set the map coordinates along the patrol route, but the acutal script that moves the patrol units is not in this part of the code.

That particular section of a function would be along the order of:

function move_patrol()


Cmd(0, [script_unit], [map coordinates]);




Below we find the Function named EINSDT101.

The purpose of this function is to define several 'arrays' named ScriptAreas, coeffs, and delays.  Arrays are a powerful method to store variable values or names that are used many times in the script.   Instead of repeating a section of code numerous time within the script, we can use a variable name from the array to do the same.   

While all of this can appear confusing, once you break it down to the purpose of each chuck, then you can determine what code defines variable and what code uses those variables to perform certain tasks.

function EINSDT101()



local ScriptAreas = {};

ScriptAreas[101] = "V_BR_W_2";





local coeffs = {};

coeffs[101] = 100000;



local delays = {};

delays[101] = 7000;





local ACTION_SWARM = 3;

local PatrolID = 101;

local vector = {x = 0, y = 0};

local center = {x = 0, y = 0}

The line 

local ACTION_SWARM = 3

is the tip off that all the code above is used to move the patrol unit.

Here we are naming a variable ACTION_SWARM  and setting the value to 3.

Right below this we set the local variable PatrolID to 101.   <----- this is the Script ID of the specific unit(s) on the map.

So in these two lines we can define our Section of the move Function:


Cmd(ACTION_SWARM, PatrolID, [map coordinates]);    <------------note that the variables easily plug into the Cmd code.

Anytime you see Cmd...  it means Command,   and in most cases is a command to a specific unit(s); like MOVE, ATTACK, SWARM, etc.


I purposely did not define the area around the above area concerning the so-called:

-- Newtonian algorithm

That actual code appears in many scripts for the explicit purpose of defining the map coordinates in a map, used by paroling unit(s).

In my own map scripts, I use some of the similar code, but simplify the variable names.  The uses of an arrays to store each coordinate makes the process simple because you only have to perform the calculations once, then store each coordinate within the array.

Ok, now I have confused many of you with this term ARRAY.  So what just is this thing.

For the purpose of our script, some may use the term TABLE, which we use to also store values.   If you use Spreadsheets, then you most likely know what a LOOKUP TABLE is, so now this should make sense.  A LOOKUP TABLE is a table that we can point our attention to find a value or name, which both can used within a variable.   The term variable is just a fancy word that means a value of something with a name:

The variable named a will assigned a value.

For those of you that have taken Algebra, then you know we use variables in our formulas.

Our Formula:

x = y + 3

So in a nut shell, all we are doing in our scripts is using variables instead of numbers in our formulas.  This allows us to change the value of a variable easily to so we can make calculations as needed.

Looking at the above formula... if we change the value of y several times, we are also changing the value of x... aren't we?

Each time we change the value of y, either by using a loop or counter, we change the value of x.

Imagine for a moment:

y = 3

We don't have to think very hard to understand this truth:

x = 3 + 3

In our functions, we can see that the code now can easily determine the value of x:  x = 3 + 3, or x = 6.

So why is this important to know?

Well if we want to move our patrol unit, we can do it several different ways.

We could sit down and make around a 1000 calculations by hand to determine each place the patrol unit should move to, what we might call a benchmark or patrol point.   To do this, we would have to use the map and a graphics software to calculate each stop point by a coordinates (x, y).    Ok, we all can understand that easy enough right?   But how can we do this?   By using the mouse in the graphics software, where we move the mouse you should also see a coordinate which translates to two values x and y.   So we now have the actual coordinate for one of our points.  But this is only a very small part of what we need.   If we are moving our patrol unit across a large area of a map, we may need to map the entire course if we wish for the movement of the unit to follow roads or other terrain features.

So now you are saying to yourself: "Well, I don't want to sit here and do all of that stuff, I just want the unit to move from here to there, and then over here, and then over there."

Ok, so lets to it the easier way.   We'll use some lines of code, called a chuck, or nugget, and let that define each route.  All we have to do is set the benchmarks or stop points and let the code define the route to move the unit.  Clean, easy, fast.   And we don't kill brain cells to make this work.

In the illustration that BB gave us to look at, it is only a part of the total sum of the script.   So we really can't see all of the mechanics which we need to define each function.  I tried to add a couple of those vital lines which we need to make our unit move... by assuming a couple fo things:

Remember, I added that COMMAND line:  
Cmd(ACTION_SWARM, PatrolID, [map coordinates]);

All we are doing with this line is SWARMING or moving a unit (101), from point to point, which are map coordinates.   Those map coordinates are stored within the array.   As the script unit (101) moves, the loop script checks and verifies the location of script unit 101.  Once it arrives at a map coordinate that we have defined as one of our benchmarks, then the scripts tells unit (101) to now move to the next benchmark.   The entire code or function continues to run in a larger chick of code called the..... Chuck or Nugget, which is also a LOOP, meaning it runs until something changes with in the controlled area.

OK.... something changes?

Yes, it runs until something changes.... what we call a Condition., as in the Condition has now changed.

So what does this mean?

Simply put:  this patrol unit, let's call him John, is moving around happily walking around his route.  John is doing his job so well that he does not have a care in the world.  All of a sudden, the condition changes and John is not as happy and stops patrolling his route.  

So what changed?   Your army had entered his little zone of control and now he is very upset.  So he stops patrolling and now going to attack your unit.   This is exactly why we use the Command SWARM rather than MOVE.

The Code for MOVE = 0
The Code for SWARM = 3.

Remember earlier in our code we named that thing/variable ACTION_SWARM = 3.

If we only wanted to MOVE our unit, we would define a variable MOVE = 0  and our Command code would appear as:


Cmd(MOVE, PatrolID, [map coordinates]);

Swarm means we want our script unit to move, but also attack any enemy that encounter along the way from point A to point B.

So back to John.   John has now moved to swarm or attack your unit, and for the purpose of this example, he kills your unit.  Once the threat is removed.... John goes back to his patrol route and is happy once more.

But let's back up for just a second and think about this script for a minute.   Would we really think that John all by himself would attack a enemy and not call some help.... or is John so bad-ass he does not need any help?

Well if you are John, I imagine you're calling some friends.   So imagine John calls Bill to help him out.  So here comes Bill... who also calls some other friends... Luke, Charlie, Roger, and their big gal named Bertha,  who just happens to be a Tiger, as in tank.  

So now John has a bunch of guys coming to kick your ass.  So if you plan to fight good old John, you better have a bunch of your friends helping you.

Ok, so I added the humor to illustrate a point here.   So why should you expect to not see other units move to exactly where your units are once you are detected?  

In most maps you just see good old John, and he never calls his buddies.  You kill John and move on never upsetting John's friends because they have no clue you killed him.  Does something seem wrong about this?

well unless you sneak up on poor old John with one of your guys and kill John with a knife or piano wire, there is going to be some noise... usually a gunshot.  So if you fire a rifle to kill John, does it stand to reason that Bill, Luke, Charlie, Roger, and that big gal named Bertha are going to check what is going on?  

You can bet your ass they are.

So your creativity and imagination are all that limit what you can do with your maps.  

If your map does not include a function along the line of LETS CHECK OUT WHAT THE HELL IS GOING ON OVER THERE...  then you have very much limited yourself and the Player is left going... "Well that was easy".

Then the Player goes on and easily kills Bill, Luke, Charlie, Roger, and that big gal named Bertha one by one and without any problems.  

So my point here is be creative.   You should not be afraid of the code.   It is just numbers and math plugged into these things called formulas and functions.  

This is why I say..... we have only scratched the surface.

Thanks guys for listening...

[Quintaxel]

@mp: I have the same kind of imagination or you can look inside my head.  
Anyway this proves the point that the full game potential has not been exploited yet.

Let me add these ideas:

- AI scout or sniper that moves around the map carefully avoiding player units.

- AI planes that check the position of AA guns and find a path to avoid them.

- Drop-off point for supply trucks. The player moves the truck to a certain point on the map, close to the where the action is. Then the unit follows a save trail back, away from the front. Useful if an objective is to take control over a road.


Now I was thinking of a script in which a player’s skills would be rated based upon one or more of the following parameters;


- Playing time and units killed within that timeframe for both AI side and player side. Experienced players will kill more AI units in less time whilst suffering fewer losses.

- Position on the map: Skilled players will advance faster.

- Objective(s) that are met: Skilled player will meet a mission objective is less time.


Based upon the players rating the Lua could then send in more or other another type of reinforcements or trigger other scripts.

This is still basic AI but it could be a start I guess. Of course a lot of the game play does not only depend on the script but also on the layout/design of the map.


Now one of the things I missed in BK is the use of waypoints. That’s why I wrote a function to move units along set trail of waypoints on the map. This gives better control over the movement of AI units. It was one of my first real tryouts in Lua. Should anyone be interested than more details can be found here.

@ Feldgrau: Nice simple script. I like simple scripts because there all I can handle. The script does indeed not change the challenge of the map but it could be used in combination with other ‘smart’ scripts.


Now where did I put Calvin’s Lua guide?


Also need to find that Moskau map by Baumi.

[bb]

hm, quite complex script, but I'm not sure if the effect in the game pay all this work. I like Baumi maps, but some of his missions are just weird (I prefer 100 lines scripts of Dmitry M.). Actually the worst thing in implement new scripts is to test it in the game. I just can imagine the nightmare in testing a script of 1000 lines!
Quintaxel, nice script! Meaby I'll try it some day.

[Quintaxel]

Just a thought.

In campaigns BK already rates the player's skills using an algorithm based upon a number of parameters. (# of enemies destroyed, units lost, units returned, resources used, house destroyed,…). As I understand it these variables are scoped as global.
If the script for the map could somehow call these variables then it should also be possible to use them to influence the gameplay, at least for chapters or campaigns.
Or let me rephrase this. If these variables can be called by the map script then they can be used to change the difficulty level of the game.

[Major Pain]

Within a script, you can pre-select the Difficulty of a Map.

You cannot change the Difficulty after the MAP is launched, nor can you change the next map based on the Players performance in the previous map.

But you can collect and pass Global Parameters which can used to change which MAP is next loaded.

Example:

Player completes MAP #1

Based on data collected, the Player is scored to calculate what MAP he will get next.

You can use a Function or Formula (Either will work) to determine the Map to be selected.

If PlayerRate < Baseline then <---------Execute Map 2.1

If PlayerRate => Baseline then <------- Execute Map 2.2

The two maps may be the same map, but each have their own script and slightly different OOBs (Order of Battle).

The Difficulty can be set in each Script, or you can provide a tougher challenged as to objectives.  

The Difficulty level does affect how the AI will function; Path Finding will be much improved and the level of Aggressiveness will significantly increase.

Before anyone thinks too hard about this, I urge caution.   If you set the Difficulty too high on MAP #2. and the Player has to start over, he is stuck right there.   There is no way to re-calculate the baseline unless you add another Script after a Lose condition.   The issue then becomes whether the Player wanted to re-play the difficulty he lost on, or will he get upset when it dumps him to the lessor Difficulty.   His choice and earlier baseline is lost with no way to return to the same level without a complete restart.

I suggest this.   Rather than Re-Adjusting the Difficulty level in the script, Adjust the SMARTNESS of the AI within the Script by ramping up or down the AIs play based on the Player's actions.  If the players is skilled and knocking down ground and objectives, ramp up the AI.  If the Player is prone to mistakes, ease the AI down.   This is a much easier process than tracking a Global Condition.   Local variables defined by Player conditions with some random or expected conditions which PUSH Tirggers, can be more powerful than passing Globals.

Example:   Player is to take a small village and hold until relieved.  Player advances cautiously to edge of village.  Based on the time elapsed, you could use timers and triggers to set up several situations.   Players HQ has urged caution, or perhaps set a attack time.  If Player misses the mark on the time, then perhaps you have the AI put up a stiffer fight, or perhaps it detects the slow player movement and sends a reinforcing group and a skirmish group to delay the Player advance even more.

You can create many kinds of conditional situations that can be used to trigger functions applied in many ways.   You can set up an open channel communication link between the AI-controlled Scout Planes and Ground Command for either the Player or the AI... or even the Player 2 (which is usually neutral).  Using the Script, it directs the flight path and search grid and reports activity on the ground.   If Intel is to be provided to the Player, he gets a Report Display Trace on the screen.  If intel goes to the AI, it is handled by Conditional Statements, based on level of activity or size detected or any other parameter.  The AI can select from a Condition Menu or Table as to what response will be used, ranging from Full Response down to No Response depending on the report.  You can hard code the orders which means the AI has to follow this action based on a condition, or you can let the AI use it's own process or thinking to select the proper response.   Difficulty has nothing to do with the way the AI acts if you give the AI its own brain and let it /hash/ its actions based on the players actions.   

In most missions, the player takes the offense position.   We see this because unless the AI is provided a structure process of thinking through options or arriving at solutions, it performs weakly on Offense.   It has limited intelligence, or what I call the Dumb AI.   This has nothing to do with Difficulty.  Difficulty does not make the AI smarter, it only lets it perform path finding much better and increase the level of aggressiveness.   This has nothing to do with the level of intelligence.  Having said that, the AI is always going to be better than the Player while on Defense, mostly because the ESP that it benefits from that causes the Marching to the Sound of Guns.   Again, this has nothing to do with the level of Intelligence.   MSG affects all AI units within a radius of the closet sighting or visual key AI unit.  If one AI unit can see it, all AI units see the same thing and react based on the distance.  Using the script, you can strip the AI base functions and replace them with a new brain which improves performance on defense and offense.

One of my pet peeves:   Have you noticed this before:   A Enemy tank comes into sight of one of your tanks; lets say you have a Sheridan Scouting and you come across a Tiger.   We you are going to lose the fight so you back your tank up to a picket line which brings the Tiger into your Emplaced Guns range.  The Tiger ignores every other units you have in that zone, only looking at the Sheridan, which you continue to back away from his gun range.  

We call this baiting, but it is a cheap way to kill an enemy unit.  

What if the Tiger can detect every units you have within its field of vision instead of remaining locked on the Sheridan?  Unless you give the AI the new brain, he will not look at any other units until he either kills the Sheridan, is killed by anything, or the Sheridan moves beyond his ability to hunt.  

The Tiger will remain in Seek/Kill mode on the Sheridan until something else breaks the condition.   Even if you attack the Tiger with an AT gun, your shot will be ignored, unless the Sheridan has moved beyond the Tiger's Interest Factor  'and' out of sight.  Interest Factor is defined as a timed event or span of time that the Tiger will continue to Seek before he forgets why he is there and begins to return to his last staged position.  As the Interest Factor zeros out, the sight capability returns to normal and the Tiger begins to look for another target while it returns to its previous location.  

If it acquires a target, the Interest Factor is reset on the new target and the process begins again.   The AI does not have the capability to track multiple targets with its core brain.   But if you enhance its intelligence, you can make it as smart as you want it to be.  Using the script, you can introduce a loop to control the SEEK and INTEREST FACTOR.   You can track the Sheridan and check range in a look-back function... which continues to run until contact is broken.  At the same time you can tell the Tiger to look around within his sight range for other targets.   The script is tricky, but very deadly if applied correctly.  When I use this type of Conditional Situation, I include other alerted Units which also move to SEEK targets.  

You can also create a Function where the Tiger will ignore weaker targets based on range in favor of stronger or armored units further away, but within the sight range.   What you have done is given the AI the brain so it knows what the Tiger should attack first and what is not an immediate threat.   Infantry would be ignored compared to a T34(85).   The Tiger will then create a threat table from the highest to lowest (which is stored in a temporary array or table) and attack in the top to bottom order.  So what happens if the infantry tries to sneak in to throw grenades?   The Tiger continues to analyze the threat status of each enemy in its sight range.   Condition:  I see you and you can see me versus I see how close you are trying to get to me.- Threat Increases based on proximity.  The Tiger at the AI's option may turn and attack the closer threat or 'move off' or 'jockey' for distance while continuing to attack other target.  This allows the AI to think about options and make a decision based on the condition.

Another Baiting Tactic we have all used is what we call the Sacrifice.   You Sacrifice a weak unit in order to position a strong unit for attack to kill the target while it's Interest Factor is peaked out and is in Seek/Kill Mod.   If you provide the AI the ability to think about it, then you get this...  Oh... a weak target to kill....  but hey... that is a juicier target to kill over there.  Rather than the Tiger attacking a truck, it is going for the Wolverine TD.

I hope this explains the options you have.

[Quintaxel]

@mp, thanks for the explanation. I’m learning here and I’m enjoying it.
The difference between setting the map difficulty level and using script to make the map more challenging is clear.

The idea of ramping up or down the AIs play based on the Player's actions and/or behaviour is a challenge but seems feasible to me. How far you can push is indeed only limited by the imagination and skills of the scripter and also the design of the map (layout, position of units, …).

To enhance the AI on the level of a unit looks like a real challenge for a scripter. Take the field of view of a unit or its armour values for example. I understand that these values are parameterized in the 1.xml belonging to that unit and used by the games engine.
The values cannot be called through script. (I think). So this would mean that in order to create a unit with enhanced AI, as the capability to track multiple targets and take the best option these parameters, would also have to be included in the script.

Wow..... . 

[Major Pain]

Let me provide a layman's version of what happens if you have a unit check for everything in its range.

We'll assume for a moment that the sight range is 30.

The Tiger that has its Interest Factor working which has detected an enemy, will begin to pursue the enemy unit.

But we want the unit to check for other targets rather than ignore them.

So in the Script, we have a function that checks the sight range of the Tiger.

We will get the Tigers map coordinates using:  GetObjCoord(HunterID).

We need to know the Script ID of the Tiger.  Using a function that detects enemy and also identifies the Unit that has made the detection, we will know the ID of the Tiger.  The Tiger's name and Script number are already defined in the Script Unit Array or a table. We use the Tiger's ID to define the local variable HunterID.   

We check for enemy units within a radius by using a function that checks the area around the tiger that is exactly 30 sight range, then checks for enemy units:  

NumHUnits = GetNUnitsInCircle(HPlayer, GetObjCoord(HunterID), 30).

Now we'll check if more than enemy is within range with the following function and 'if' statement:

----------------------------------------------
----------CHECK RANGE FOR ENEMY ------------
----------------------------------------------
function CheckRadius ()

if NumHUnits > 1 then RunScript("SeeWhoIsHere", 1000, 1); 

else RunScript("Just1Target", 1000, 1);

suicide
end
end
-----------------------------------------------

If NumHUnits returns a value of 1, then the Function "Just1Target"  is called which will change the Tiger's state to ATTACK then send the Script back to the "CheckRadius" Function.

If NumHUnits returns a value greater than 1, then the Function "SeeWhoIsHere" is called so we can perform a few checks to see what they are.

Once the Tiger can now see all of the Enemy units, then it must check a couple of things before we can break off our pursuit on the original target.


We first identify the units by checking each coordinate and comparing to the OOB Table (Order of Battle) that maintains the coordinates of each Script Unit by ID.   When we get a match we add that unit to a table named TARGETS.  We add a fudge factor to allow for units that may be moving, by creating a temporary Script Location (Radius) around each target.  Moving targets can checked to determine if they are retreating away or advancing toward our Tiger; which is another function that calculates range.

Since we now have the Target Table by Unit ID, we can then check what each Target is by checking our OOB Table (Order of Battle) which also stores each ID with its Unit Type  (Infantry, Truck, Gun, Tank, SPG) and it's relative strength (VHigh, High, Med, Low).

Note:  Each time a Script Units moves, it's coordinates are update roughly every 3 seconds in the OOB Table.  We use a UnitTracker Script to perform this duty.   The Tracker detects whenever a unit moves and tracks its movement by ID.   If Units are not moving, they become static, or what we called staged.

I'm not showing all of the script since it is quite complex and would require several Array Builds to demonstrate.

Once we have defined each target by its Relative Strength, the Tiger can make a decision based on the Strength and distance.

Obviously, the higher the danger level of the enemy, the more the Tiger should focus on that unit.   If there are two or more units with a VHigh Strength, it selects the one that is the closest.

Another thing that the Tiger might consider is the odds of surviving against several targets, and perhaps retreating if it feels the odds are very low.  So we can use a script which this can be analyzed.

Anyway, the Script that checks the Tigers Target Options is performed about every 1 to 2 seconds, with the timing based on how many target are within the range.  The more in range, the longer it takes to calculate.   If the tiger determines it is outnumbered and outgunned by a factor of 2.5 to 1, it will always retreat instantly forcing a 'Move To' Command and suspending the rest of the Target Script.

One thing more that we can do while the Tiger is checking its targets is communicate with other units for assistance.  We can use another Script that will call the closest units based on distance, strength or numbers.   That Chunk will continue to run even if the Tiger has retreated.   We then can assemble the supporting units for a larger attack.

What I am trying to illustrate is the power of the Script language.  We lack a few Scripted Formulas or Anchors that define specific aspects of a model.   But you can usually build a work-around for most of them.  We can use "Get" and "Set" to define or acquire variables values, conditions, states.

Learning LUA is not really too difficult.   It just takes some time to understand how you can apply its capability.

When we complete the Chapter Project, guys that really want to understand how it works can see how we are going to use it.

I have been working on a Module which should allow us to expand the list of defined Formulas, Functions and Commands which will reduce some of the calculations we must do now by storing data in Tables and Arrays.   But the use of Tables and Arrays is key to structuring a very Powerful Script and a very smart AI.

I'm sorry for posting so much in your topic, but I hope it is helping everyone understand what can be done.

[Quintaxel]

Does anyone know if values that are the result of a function can be stored somehow so they do not get lost when a game is saved. I'm talking about working with single maps here.
Suppose a function that enables the AI to gather intelligence, eg. the position of AA guns on the map.

This could be programmed in the map's script but the problem is that the values (x,y position of the AA guns) would get lost when the map is saved.

[Folgore]

Why lost? Unless you think that the AA gun is out of sight of the AI.
Anyway we do know that it happens on .sav files because the game has to put on the map even units that AI didn't spot but we don't know how the game retrieves data from .sav files and how they are stored.
I mean, the game must know the position of any units in order to save the game at any moment but there should be somewhere in the engine a function that "conceals" to the AI units out of sight of the same AI.

[Quintaxel]

Jan 20, 2014 10:45:47 GMT 1 Folgore said:

Why lost? Unless you think that the AA gun is out of sight of the AI.
Anyway we do know that it happens on .sav files because the game has to put on the map even units that AI didn't spot but we don't know how the game retrieves data from .sav files and how they are stored.
I mean, the game must know the position of any units in order to save the game at any moment but there should be somewhere in the engine a function that "conceals" to the AI units out of sight of the same AI.

I think I understand what you mean Folgore but even if the .sav files stores if a player's position is know, then such information can only be used by the AI engine and it can not be used in the script.  If however you could store the position of units of which the position is known to the AI then it would be possible to enhance the AI of the game.

I was thinking the following script:

When the AI reconnaissance plane finds AA-guns within its view then the position of these AA guns are stored in a array.
Once these positions are known they can be used to trigger further actions by the AI. 
It would for example be possible for AI bombers to move along a certain path to their target so they would stay outside the range of the players AA guns that were spotted by the reconnaissance plane.

Now this could be scripted, but the problem would be that the positions of the AA-guns would be lost the moment the game is saved. 
I know that it is possible to carry over data between maps that are part of a chapter (however I do not know how this is done). Now I was wondering if it would be possible to write and read values to and from an external file via the script file of a map.
I must be possible in Lua but I found out that the 'BK Lua version' has a lot functions missing that are available in Lua.

 

[Folgore]

Carrying over values from maps it's an issue that has been discussed previously on the Global Campaign topic by Danzig70 (see here: blitzsrbija.proboards.com/thread/418/global-campaign?page=1 ) but I don't know if Danzig got results.
IMHO the idea of an array to store values it's a good idea but there is a difference between values stored after you play the game and values to be stored while you are in game.
In this latter case you need either a sort of "dynamic" array that has to be able to expand as long as new values are added or some function that deletes older values once newer values are added if you want to keep the array to a given dimension.
Don't ask me how to do it...
This is stuff for MP's teeth