There's no distinction between players and other creatures w.r.t. 'thinking'/processing in this engine so your extrapolation of 1 player = 0.5% avg CPU is just plain wrong, but I'll bite: The way this engine is implemented there's at least 50 'players' in there doing path finding (arguably the most compute intensive operation in the known C++ engine) and, while there's no re-targeting yet, every movement, individual attack, turning, splashes (which are item things being added & removed) you see is being handled by the same centralized queue without problems.0.5% average CPU usage for 1 player? It's still too much as to what we can do with C++ on the same circumstances, imagine 100 players and monsters also retargeting many times and finding paths for different players at a time and over 300 players doing stuff? That's overkill on the CPU.
Imagine 300 and plus average players, and about 300 or more active monsters at a time, including player actions from moving objects, removing objects, etc ... How would the performance be? Also, isn't an object pool a better approach in C#? CipSoft uses object pools for everything but creatures.
Moreover, I've never claimed this will be faster than the C++ implementation out there, but I'll argue that there is absolutely no need. We're not in 2005 anymore, (where compute resources cost so much that efficiency was a religion) and rather maintainability and service distribution is the norm.
Finally, while I do believe the numbers you mentioned are easily achievable by this engine's current implementation, you're right in that there's still the open ended question of where the limit for this approach is. I'll try to answer that question with telemetry and by hosting some very rudimentary test server soon
Last edited: