Multi-core CPUs are not very well utilized for large fleets of ships.

[keith.lamothe]

I reject your reality, and substitute my own.

Which is not only a great Mythbusters quote, it's a good summary of what the threads wind up saying to each other about shared objects, the problem being that whichever thread wins the player still loses


(oops, accidentally edited your post the first time instead of replying to it, I guess there was a threading problem )

[x4000]

Yeah, the Adam Savage quote made me lol, as well.  My wife asked me what was funny, and I had to pause and just say "it's too long to explain."

[RCIX]

I'm glad you don't mind putting up with us stubborn fans, after all we do come up with something useful once in a while.

We push units through the simulation like FPS games push polygons through the GPU, and that's before you even get into all the AI firsts.  

Wow. That's a great line! you really should put it on the homepage or something...

[x4000]

I'm glad you don't mind putting up with us stubborn fans, after all we do come up with something useful once in a while.

Indeed!

We push units through the simulation like FPS games push polygons through the GPU, and that's before you even get into all the AI firsts.  

Wow. That's a great line! you really should put it on the homepage or something...

Haha, that is a pretty cool line, you're right.  I'll have to think of something to do with that, perhaps.

[TheSilverHammer]

Earlier I didn't consider your random numbers issue and I do see how that can be a real problem.  If you have N simultaneous threads each using random numbers, I can see how this will break in a multi-player game.  In single player it is no issue, but in multi-player it is.

However, are there areas of your code that are CPU intensive and do NOT use random numbers?  I notice when I select like 3000 ships and give them a move order, the game halts for a few seconds.  All this pathing and whatnot, it does not need to be random does it?  It can be parallel as well.

Here is another huge performance problem I found. 

1. Get like 2500+ ships in a hostile sector.
2. PAUSE the game.
3.  While paused and having all your ships being selected, shift-click on multiple targets, like lightning turrets. 

This can take SECONDS between clicks even though "time" is stopped and nothing else is going on.   There should not be any random numbers being used here, yet there is some huge computational task going on.

Another thing to look at is if random numbers are actually needed in certain situations.  One thing I noticed is the fact that there is a "hit chance" which generally goes very quickly from 0 to 100.  I would suggest that this is a prime target for removal.  If you are in range, you get a 100% chance to hit, otherwise zero.  Now if this is removed, then once a unit has a target, the whole "attack until dead" AI can be parallelized because there is no need for "random" synchronization.

[x4000]

Earlier I didn't consider your random numbers issue and I do see how that can be a real problem.  If you have N simultaneous threads each using random numbers, I can see how this will break in a multi-player game.  In single player it is no issue, but in multi-player it is.

However, are there areas of your code that are CPU intensive and do NOT use random numbers?  I notice when I select like 3000 ships and give them a move order, the game halts for a few seconds.  All this pathing and whatnot, it does not need to be random does it?  It can be parallel as well.

Here is another huge performance problem I found. 

1. Get like 2500+ ships in a hostile sector.
2. PAUSE the game.
3.  While paused and having all your ships being selected, shift-click on multiple targets, like lightning turrets. 

This can take SECONDS between clicks even though "time" is stopped and nothing else is going on.   There should not be any random numbers being used here, yet there is some huge computational task going on.

Another thing to look at is if random numbers are actually needed in certain situations.  One thing I noticed is the fact that there is a "hit chance" which generally goes very quickly from 0 to 100.  I would suggest that this is a prime target for removal.  If you are in range, you get a 100% chance to hit, otherwise zero.  Now if this is removed, then once a unit has a target, the whole "attack until dead" AI can be parallelized because there is no need for "random" synchronization.

All I will say to this is that I cannot believe how you refuse to read my explanations. It has more to do with than ransoms, as I have explained repeatedly in my above posts. I can't explain it any better, I fear. I know you're not being intentionally maliscious or anything, but it is very frustrating when you push your agenda while seeming to skim and disregard my explanation. I don't want this to create a huge rift here or offend you, but please understand that my job consists of a lot more than re-explaining myself to someone who clearly doesn't want to hear the answer. The answer to your above post is in my prior posts, in painstaking detail, two or three times over -- hence my frustration.

[keith.lamothe]

I notice when I select like 3000 ships and give them a move order, the game halts for a few seconds.  All this pathing and whatnot

Pathfinding is minimal-to-none, as it doesn't try to factor in the odd actual obstacle of a forcefield (it does do collision checking, but generally only at the endpoint).  It's possible that queueing up those 3000 unit commands is the problem, I will try to get time to take a look at that one in the debugger.

Here is another huge performance problem I found.  

1. Get like 2500+ ships in a hostile sector.
2. PAUSE the game.
3.  While paused and having all your ships being selected, shift-click on multiple targets, like lightning turrets.

That's a very similar issue, it's queueing up tons of game commands for later processing (though typically those game commands are condensed for large groups).  I can't be certain that this is the cpu drain but I'll try to take a look.

Another thing to look at is if random numbers are actually needed in certain situations.  One thing I noticed is the fact that there is a "hit chance" which generally goes very quickly from 0 to 100.  I would suggest that this is a prime target for removal.

There are no randoms in that calculation, it's deterministic based on shields, power, and range. Edit: oh, if you mean the calculation of whether a shot actually hits based on that hit chance, yes, that uses a random.  Removing hit chance (in favor of "can hit" and "cannot hit") would remove some pretty significant mechanics having to do with minimum chances, etc.

[TheSilverHammer]

Sorry, I wont post on this topic anymore. I didn't mean to upset you or offend you in any way.

[keith.lamothe]

It's just that this is probably the 50th thread on the subject, patience cost tends to be O(n^2) or O(n^n) on ones like these

Please do stick around the forums, in any event.

[RCIX]

The one other thing that might help, i don't know if you're doing it, is to form a "group" out of whatever's selected then just issue the one order to the group and have ships take the group order as fast as they can while maintaining smoothness. Just a thought. I hope i'm not suggesting anything redundant or unusable!

[Velox]

     Battling for galactic supremacy is old news - I think each ship should run in its own thread so they can fight over system resources instead.

[x4000]

The one other thing that might help, i don't know if you're doing it, is to form a "group" out of whatever's selected then just issue the one order to the group and have ships take the group order as fast as they can while maintaining smoothness. Just a thought. I hope i'm not suggesting anything redundant or unusable!

Well... yeah.  See, selection is an "interface thing," not a "simulation thing."  In other words, the simulation doesn't even know what is selected, same as it does not know what planet you are looking at, where you are scrolled, etc.  It is an odd way to think, but needed in order to have much more realtime responsiveness of the interface and viewport compared to the 400ms round-trip execution time for simulation-affecting commands.

So what that basically means is that when you have a ton of ships selected, the simulation does not and can never know without sending some sort of "group these units" command that would be the same size as the "move/attack" here command.  Then you wind up with the game lagging as soon as you select some large number of ships, and some various technical issues based on syncing and trying to make it all work... etc.

Basically, I think that that sort of solution would have the same problems as the PreFetching in Vista/Win7, and for a lot of the same reasons.  It's trying to predict and offset future occasional load by introducing persistent ongoing load.  It's one of those many things that is so different from coding a single-player RTS.

[RCIX]

Well, i was just suggesting it because that's the method SC2 uses to do pathfinding (with flow fields and units pathing as groups instead of individually). But, you have a great explanation there!

[x4000]

Having units path as a group is very common, and actually is a technique that AI War also uses for things like Galaxy Map orders, etc, which is the only place there is true pathfinding in AI War.  But that's a bit different than what was discussed above, because above there are a large number of units that you are issuing simple orders to, rather than in SC or similar, having a large/small/whatever number of units that you are issuing complex orders to.  When we issue complex orders, we always do the work only once for groups of ships, but the problem comes with issuing simple orders to vast numbers of independent units.

[HellishFiend]

     Battling for galactic supremacy is old news - I think each ship should run in its own thread so they can fight over system resources instead.

Am I the only one that found this hilarious?