New Auto Mission code proposal

[Destructavator]

OK, I've talked with BTAxis and looked over the old proposed Auto Mission code on the wiki page.  The old proposal doesn't factor in a lot of stuff, doesn't have some realism factors (Two wounded units can be more deadly than one healthy one), and it also has the issue of the Balance Of Power slamming into a "solid wall" if it strays above 1.f, rather than curving towards it.

This pseudo code I'm going to list here would fix much of that, and after something like this is put in the could could then pick back up on the old proposal starting from "Injuries and Casualties" once the Balance Of Power is calculated.  This new system would let that balance curve in a controlled amount (anywhere from a slight adjustment to leaning heavily) towards the range boundaries of 0.f and 1.f without completely reaching them.  This means a lone soldier could still have a very slight chance of winning a mission against a group of aliens (although that slim chance wouldn't be pretty for the soldier.

I'm also attaching two pics showing examples of how the curve function can work with different values.  The result isn't quite "exponential" but is very controllable.

Code: [Select]

// Custom functions for manipulating floating point number
//    up and down without straying outside of 0.f and 1.f,
//    also doesn't need min() or max(), but rather keeps
//    everything in a nice curve.
// "pushV" and "pullV" are floating point parameters
//    that set how rounded the curve is, or in other words
//    how much to push or pull toward 1.f or 0.f.
// "pushV" and "pullV" can range from 0.f (very subtle)
//    to just under 1.f (extreme change).  I personally
//    would not recommend going above 0.99f (usually).

float PushUpward(float oldValue, float pushV)
{
    float newValue = (((1.f-pushV)+1.f)*oldValue) / ((1.f-pushV)+(1.f*oldValue));
    return newValue;
}
float PullDownward(float oldValue, float pullV)
{
    oldValue = (1.f - oldValue);
    float newValue = (((1.f-pullV)+1.f)*oldValue) / ((1.f-pullV)+(1.f*oldValue));
    newValue = (1.f - newValue);
    return newValue;
}


// Now for the actual Auto Mission code

float BoPindex = 0.5f;  // Starting or "base" balance of power (chance of sucess)
                        // for the mission, can be set lower for hard game
                        // difficulty, or higher for an easier game.  NOTE: If
                        // this is set higher or lower it should NOT be set to a
                        // perfect 0.f or 1.f, it should always be somewhere
                        // in-between.  Normal games start at 50% success rate,
                        // before we of course "play" with it.

float numberOfSoldiers;  // Total number of soldiers on a mission, and yes, it
                         // needs to be casted into a float, you'll see why shortly.
float numberOfAliens;    // Same thing for aliens.
float numberOfCivs;      // Same thing for civilians.

float playerFactor = 1.f;
float alienFactor = 1.f;
float civFactor = 1.f;

for(x=0; x < numberOfSoldiers; x++)
{
    float tmpF;
    tmpF = soldier[x].currentHealth / soldier[x].maxHealth;
    tmpF = PushUpward(tmpF, 0.5f);  //This accounts for the fact that two wounded
    playerFactor += tmpF;           //Soldiers can be more effective than one healthy one.
}

for(x=0; x < numberOfAliens; x++)
{
    float tmpF;
    tmpF = alien[x].currentHealth / alien[x].maxHealth;
    tmpF = PushUpward(tmpF, 0.5f);
    alienFactor += tmpF;
}

for(x=0; x < numberOfCivilians; x++)
{
    float tmpF;
    tmpF = civ[x].currentHealth / civ[x].maxHealth;
    tmpF = PushUpward(tmpF, 0.5f);
    civFactor += tmpF;
}


float playerFactor = float (1.f / playerFactor);
float alienFactor = float (1.f / alienFactor);
float civFactor = float (1.f / civFactor);

if( Civilians are infected and hostile )  alienFactor = PullDownward(alienFactor, civFactor*0.5f);

if ( playerFactor > alienFactor )
{
    float tmpF = playerFactor - alienFactor;
    BoPindex = PullDownward(BoPindex, tmpF);
}

if ( playerFactor < alienFactor )
{
    float tmpF = alienFactor - playerFactor;
    BoPindex = PushUpward(BoPindex, tmpF);
}

// Here the sums of equipment scores are factored in.
float plyrWeaponFac = float (1.f / soldierEquipmentScore);
float alnWeaponFac = float (1.f / alienEquipmentScore);

if ( plyrWeaponFac > alnWeaponFac )
{
    float tmpF = plyrWeaponFac - alnWeaponFac;
    BoPindex = PullDownward(BoPindex, tmpf);
}

if ( plyrWeaponFac < alnWeaponFac )
{
    float tmpF = alnWeaponFac - plyrWeaponFac;
    BoPindex = PushUpward(BoPindex, tmpf);
}


Note: All the "0.5f" values within the custom push/pull functions are "magic" numbers that could be changed to alter game mechanics.

[Mattn]

can you please post this on the patch tracker with a link to this thread?

[Destructavator]

can you please post this on the patch tracker with a link to this thread?

OK, Done.

[Destructavator]

OK, I thought I'd start by creating a header with the custom "helper" functions.  I put in it several algorithms, including some I might use for additional coding down the road.

It is currently written to go in the "common" folder, right next to "mathlib.h"  If this is an OK spot for adding custom functions like this, should I go ahead and commit this via Git?
(At some point I'll put the mentioned graphic together.)

Edit:  Oops!  I meant "shared" for the folder name.  Sorry, I was working on more than one new source file in different places.  (I'm still trying to figure out the best place to put new source files.)

[Mattn]

I'll check it asap. But i currently do not have inet at home

[Destructavator]

OK, here's a little more work, a few additional functions, and a .c file in addition to the header for some complex math functions.

I tried to conform to the code guidelines for the project - How do these look?  If I were to code the actual auto-mission code like this (which I'll start very soon), would this be OK?

Please note I didn't actually try to compile these.

[Destructavator]

Oops!  In that last 7zip file I put the old version of the header in with the newer .c file, by accident.

Sorry about that, give me a few minutes and I'll attach the proper, updated files.

Edit:  OK, here they are.  I also added some more comments to give a better idea of what the hey is going on in parts of the functions.

Edit #2:  Hmmm...  I did a little reading on C vs C++, and it appears I have more "homework" to do on the differences.  Sorry, I've never worked in regular C before, my bad.

[geever]

Oops!  In that last 7zip file I put the old version of the header in with the newer .c file, by accident.
Sorry about that, give me a few minutes and I'll attach the proper, updated files.

- First of all, please check your editor, the patch contains 4spaces per level instead of TABs in indentations.

- Second comments: there are two different kind of comments we use:
a) doygen:
/**
 * @brief what this function does
 * @param[in] param1  What is param1
 * @param[in,out] param2 What is param2
 * @return @c true if blabla...
 */

Always write doxygen comments for functions, our documentation is made of them automatically. (We also make doxy for macros/constants/structures which are not obvious)

b) normal comments
there is no asterisk leading for a normal comment
put normal comments in separate line if possible

- function signatures: put a space between function name and parameter list in the .c file but not in the .h file.
- if and the (condition) should also have a space between.

Wrong whitespace using will FAIL the pushing of the commit. We have some automatic tests for whitespace rules.

- I suggest using double precision types for the parameters

- I lost in the bracket jungles of macros in the header file, also in macros every parameter should be protected with brackets as they can be complex expressions on calling. (we agreed that they'll be better as inline functions)

- better parameter (and function) names if possible, please

- make the functions failsafe, now they can easily div by zero. If the parameters domain are strict you should explain it in the @param doxygen tag, and can check with at least an assert().

- there are much comments in the .h I don't get, can you clean them up? Or I should have some drink, to make it clear?

-geever

[Mattn]

Please also make sure to provide aunittest. I will prepare the files for you once i have the time.

[Destructavator]

This isn't totally finished, but how does this look?

[Destructavator]

This is the latest, hopefully good enough for me to start the actual auto-mission stuff.

[Destructavator]

The latest, with a quick test app, project files, and a .txt output log.

Oh, and many bugfixes and improvements, as well as a few optimizations and removal of unnecessary/dead crap.

According to the output log of the test app, I'd say the tested functions are working as they should.

This is now enough for me to start the actual auto mission code, I think.

EDIT:  Please note that this package contains a mathlib.h and ufotypes.h which are DUMMY files - please do NOT use these dummy files in the main game source code.  Only the mathlib_extra .h and .c files are the actual new code, thank you.