How many thinking AI can your game handle?

#1 Few months back I've done some tests...
Modded T3D 1.1 dedicated build handled approx 500 AIPlayer objects, all running around without noticeable latency drop.
Server config:
CPU: Core 2 Quad Q9550 2.83GHz
RAM: 2x2GB DDR2 @ 1333MHz (Dual mode)
OS: OpenSUSE 11.3 x86
Compiler:

Quote:
gcc -v
Using built-in specs.
Target: i586-suse-linux
Thread model: posix
gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux)

Compiler options:

Quote:
-MMD -msse -mmmx -O0

Every AIPlayer object have own "think()" method called every 2.5 seconds. The "tick" includes about 3-4 castRay() calls, few iterator runs over different SimSets and 200-line scripted method.

Note 1: From my tests, Linux (dedicated release) builds' performance is about 20-40%% better comparing to Windows. And debug builds can give up to 50% boost on Linux under some circumstances.
Surprisingly, but sometimes Linux release builds runs faster on virtual machine comparing to Windows builds running on host machine. :) Weird, but that what from my tests (i7 950 CPU with 24GB RAM + VMware Workstation 7.1.4 on W7 x64 as host with OpenSUSE 11.3 + 4GB RAM as VM).

Note 2: It is a heavily modified engine, so I can't say what stock T3D will show. Haven't run stock T3D on Linux for a long time.

#2 I use core2duo 2.4, 4Gb ram, ATI 6790, win7 64 bit
I run de-server with 4 terrains at the time, 12713 object, 874 Npc, 1960 mobs,(1.20GB in ram). Textures 1024, 2048 dds
fps +50, cpu 2-3%, ram page 2.4Gb

for Ai i use variable thing time, starting from 20sec, long distance check.
not used in think nothing except the detection of long-range distance (etc 500 meters every 20 secs, 250 meters every 10 secs, 100 meters every 5 secs, 50 meters every 1sec and attack mode every 10mSec).
variable for lock target in AI, etc %this.curTarget = %target;
Unlock this after player or AI die, or with aggro tank skills, so no need to do the AI search control again for a target.

#3 It's completely dependent on what your bottleneck is...and it can be many thing but it's usually only one specific thing that you can fix and/or work around if you have the time.

Since it's going to be a CPU problem, a tool like VTune will help you track down what the specific bottleneck is.

http://software.intel.com/en-us/articles/intel-vtune-amplifier-xe/

#4 I'd like to point out that unless you've done something in the engine, the default script processing tick is 32ms, so scheduling for every 10ms is going to miss ticks all over the place....

#5 It's completely dependent on what your bottleneck is...and it can be many thing but it's usually only one specific thing that you can fix and/or work around if you have the time. As Richard states, on the server side you are fighting the self-limitations of 32 ms ticks.

Since it's going to be a CPU problem, a tool like VTune will help you track down what the specific bottleneck is.

http://software.intel.com/en-us/articles/intel-vtune-amplifier-xe/

#6 yes you right, the example for 10ms is only for AI archer shooting at a moving target.
I tried to 50ms and has almost no difference :) thanks Richard.
Also resolved the think time and the best simulation I believe is an auto adjust, like %this.thinkTime = %tempDist * 30;
30-40 is the best for me
if an AIPlayer attk melee in 2-3 meters distance, think time goto 60-80ms

#7 @Vince and Bank,
So are these servers actually making use of the multiple cores? Is the threading allowing it to spread that out? Or is it running the console stuff in one thread = one core? Can you tell?

After taking a close look at the console code it looks like it can only run one compiled script at a time due to the global/static variables used.

@Eric,
Can that tick be adjusted easily? It might be useful to do so on the server side since you are not rendering there.

#8 On a completely separate note, why would you even run AI update routines at 100Hz? Human reaction time is around 200ms, or 5Hz. The standard AIPlayer::getMove updates at 32Hz should more than accommodate stuff like aiming at moving targets - which is more about the firing solution than the rate of update, in any case.