Optimizing FPS?

[knucracker]

These things are also very interesting... and given their efficiency, modern reliability, and they are cheaper to manufacturer they should have replaced planetary gear automatic transmissions by now.  But most manufacturers actually charge _more_ for a CVT.


I guess the bottom line on the game's computation burden (regarding energy) is that it requires determining when and where to delivery energy.  This is done with a flood fill algorithm and it gets optimized so it doesn't have to run over and over per frame.  But, large graphs of things make larger networks and at least once per frame every individual network has to be identified and all units like reactors have to know the results.

Packets do come into play for energy consumption... which CN should produce a packet means finding the nearest connected CN. This means a flood fill and A*.  Neither are done more than necessary and results are remembered for as long as they are good.  But there is a lot of energy addition, packet production, and resulting routing that has to happen 30 times a second on a network that changes more often than you might realize. 

'Small' additions to the game made big differences.  For instance, if there was only 1 CN then it will produce all packets (if connected).  This was the CW1 model.  In CW3 having more than 1 CN means energy balance, determining which CN is closest for all packet production, etc.  And all of this has to happen while a 256x256 array is updated 30 times per second (in a CA simulation), many dozens of units search their neighborhood for targets to shoot at, digitalis 'grows', runners figure out where they want to move to next, etc.  And it's all written in C# running in the mono runtime.  Kinda shocking it actually works as well as it does now that I think about it :)

Last thing... a game like Total Annihilation deals with resources in an "out of map" cache.  Pick up metal or make energy and it goes into your cache.  Construction units pull from that cache to make things.  No routing necessary to keep up with "physical" metal store on the map.  Trying to keep things on the map was a goal of CW3.  That's why ore mines send ore packets to the CN (another computation load).  Aether is visible and flies to the Forge (straight light, so not too bad computationally :) ).  Even energy production (which is invisible) still obeys connectivity like electricity would. Removing the abstraction of logistics means all logistical needs have to be dealt with as discreet entities during the simulation.  It means extra work within the game, but I like the results from a game play perspective.

[4xC]

Speaking of CN's and packets, I know this was mentioned many months ago while CW3 had yet to be released publically, but I could use a little catching up:

What, if there is one, is the limit to how many packets a single CN can distribute?

Back in CW2, the LS could not send more packets than 60 units of energy could provide (meaning that it was useless to produce more than enough reactors or upgrade their efficiency enough to exceed 60 production).

[planetfall]

Back in CW2, the LS could not send more packets than 60 units of energy could provide (meaning that it was useless to produce more than enough reactors or upgrade their efficiency enough to exceed 60 production).

Not true. If you had crystals, you could exceed the limit (even if you weren't using the crystals, just had them in storage.)

[4xC]

Back in CW2, the LS could not send more packets than 60 units of energy could provide (meaning that it was useless to produce more than enough reactors or upgrade their efficiency enough to exceed 60 production).

Not true. If you had crystals, you could exceed the limit (even if you weren't using the crystals, just had them in storage.)

Oh yeah. Thanks for reminding me of that.

My original question still stands: do CN's have a limit for how many packets they can send regardless of energy production?