[3.1+] NullBot: an adaptive skirmish AI

[cue]

To see if NullBot is the problem, try playing against Nexus instead. Nexus is much less CPU-unfriendly.

In fact, on my PC, i'm starting to have problems with around 5 NullBot AIs running. But my hardware is much older than yours (one of the early P4, ~8 years old).

Early P4! One of our player is using a P4 3ghz with Hyper-Threading so it reports two cores.
Can you finish a game with 4 NullBots?
Does the game not slow down when there are many many units in game?

But I can ask my friend to try the game with more AIs.

[cue]

I suspect it's the clustering code later in the game when there is more stuff on the map. Also, I suspect that possibly nullbot doesn't know when it's been defeated and thus keeps running that code. Maybe have a check to see if nullbot has any units/buildings left and if not throw a kill switch? Obviously, human ally could gift a truck so it would still need to do minimal check to detect "resuscitation" and reactivate itself if it suddenly finds it has a truck from somewhere.

Could the gift function itself not have a reactivate code to revive the AI if it is dead?

[NoQ]

Early P4! One of our player is using a P4 3ghz with Hyper-Threading so it reports two cores.

Yeah that one. I finished a FFA against 9 nullbots on Emergence ... the game was lagging considerably, but not unplayable.

[aubergine]

There is already an eventObjectTransfer() in the JS API which gets triggered when a game object is gifted or assimilated (eg. via Nexus link).

I guess the C++ code could cancel all queued functions and timers if it sees an AI has no structures/droids left, and also set a flag to prevent any events (other than eventObjectTransfer() event) being sent to the AI script. This would completely remove processing overheads from dead AIs. On seeing an object transferred (any unit I guess) the C++ code would trigger eventObjectTransfer() and also re-enable normal events (eg. eventObjectSeen(), eventAttacked(), etc) for the script.

[NoQ]

I don't think it should be done on c++ side (scritps can handle it well enough) and i don't think dead AIs are the issue.

We're gonna need some real profiling, i think. aubergine: any ideas on how to profile js code?

[aubergine]

Well, in the current environment proper profiling will be difficult. I guess you could wrap functions and event handlers in a basic profiling function that debugs time spent on a function, for example:

Code: Select all

// I've not tested this code!
Function.prototype.profile = function() {
  var fToProfile = this;
  return function() {
    var t1 = Date.getTime(); // start time
    var res = fToProfile.apply(this,arguments);
    var t2 = Date.getTime(); // end time
    // not sure if fToProfile.name is supported in the JS env, but it should be
    debug(fToProfile.name+": "+(t2-t1)+"ms");
    return res;
  }
}
// scroll down...

function eventAttacked(victim, attacker) {
  /* some code */
}

eventAttacked = eventAttacked.profile();
// from now on any call to eventAttacked() will debug profiling info

[aubergine]

Actually, this would create nicer output by indenting the debug when nested functions are profiled.

Code: Select all

// I've not tested this code!
(function() {
  var profileIndent = -1;
  Function.prototype.profile = function() {
    var fToProfile = this;
    return function() {
      var t1 = Date.getTime(); // start time
      ++profileIndent;
      var res = fToProfile.apply(this,arguments);
      var t2 = Date.getTime(); // end time
      var indent = Array(profileIndent).join("  ");
      --profileIndent;
      // not sure if fToProfile.name is supported in the JS env, but it should be
      debug(indent+fToProfile.name+": "+(t2-t1)+"ms");
      return res;
    }
  }
})();

function eventAttacked(victim, attacker) {
  /* some code */
}

eventAttacked = eventAttacked.profile();
// from now on any call to eventAttacked() will debug profiling info

[cybersphinx]

Profiling the game itself should at least show if the time is actually spent in js or somewhere else.

[Per]

Run the game with --debug=script command line parameter, and it will output a warning to console whenever a single event call from the c++ side takes more than 50 ms to process on the scripting side. See https://github.com/Warzone2100/warzone2 ... t.cpp#L109. It is not much, but it is a start. Master only, I'm afraid.

[NoQ]

Per: C.O.O.L.

Master only, I'm afraid.

Ok, since #3371 is finally fixed, i'll have some work to do

[NoQ]

Fail
Will try aubergine's code then

upd: Fail we don't have Date.getTime?

Code: Select all

error   |10:44:23: [callFunction:117] 0 : <anonymous>()@multiplay/skirmish/nullbot-1-16-head.inc.js:7
info    |10:44:23: [callFunction:120] Uncaught exception calling function "attackStuff" at line 7: TypeError: Result of expression 'Date.getTime' [undefined] is not a function.

upd: yeah, we only have Date() function that returns a string.

upd: finally compiled master (:

upd: master's profiler clearly points to the last function you'd expect to be a problem: huntForOil().

upd: dangerLevel() is the problem (ineffective and/or called too many times)

[aubergine]

Doh! I know what the date issue is:

Code: Select all

var t1 = Date.getTime(); // start time

Should be:

Code: Select all

var t1 = (new Date()).getTime(); // start time

And same sort of thing for var t2.

[NoQ]

Ok, i switched to enumRange() and it helped a lot. But what to do on 3.1?

[Per]

I could backport a chunk of javascript code from master -> 3.1 if that helps. Let me know what are the top desired items for backporting, and I'll see that I can (dare) do.

[NoQ]

Apart from enumRange, i seriously look for enumGateways and .range property; the rest seems to have a workaround.