First week DOOOOM: a look back
By
Arkyaeon,
Posted on: 2011-04-11 08:01 in CoH and CoV General Discussions
I think it's more than that. I think there are a number of zones that carry textures and solids that are essentially out of sight of the player. But they still need to be rendered and that rendering cost is exacerbated the more that goes on. If it's just one solid rock with a texture on the inside, so be it but when it's 200 piles of rubble that have unnecessary texturing and there's a bunch of other stuff going on it just serves [sic] to put extra pressure on the system.
Thelonious Monk
Even generating new mobs isn't really an issue- TRACKING the mobs and communicating that tracking data is a big chunk of it.
When a mob is instantiated but it just running its default behaviors, there isn't much that needs communicated to the clients, just "Mob_A started default animation set B at time C." Nothing deviates without player interaction, so nothing really needs updated... and no heavy AI calculation needs done.
In the case of the BAF, there are even default paths that the resistance will run. They, like ambushes, just need to tell the client "mobA going from pointB to PointC via pathD" and forget about it...
...until player interaction. Then the AI needs to calculate alternative paths, or initiate combat commands, and then every moment-by-moment action needs to be relayed to all players within range... along with all the other players' behaviors and locations.
Whether all that causes a process bottleneck (many calculations, multiple times a second) or a bandwidth bottleneck (it IS a lot of data to relay several times a second) I'm not sure. It could be either or both.
- If it was a PROCESS bottleneck that was slowing down server time, you could add a few bits to the bandwidth every few seconds to make sure that your tray icons "recharge" was working at the same clock speed as the server's.
- If it was a bandwidth issue, the last thing you'd want would be more bits transmitted per second. You'd instead look to see whether you could curb the frequency of the updates... if you could cut them down from (fictional numbers here) 4 times a second to 3 times a second, and you reduce the load by 25%, for example. Cut it too much, though, and users would experience more warping. Alternatively, you change how often SOME data is transmitted (positioning is critical info... but maybe the hit point meter data could be sent half as often, for example)
(DISCLAIMER: While the principle behind the solution is simple, none of these solutions are "simple" when it comes down to changing the code at such a fundamental level. This part of a codebase is usually the "here ye be dragons" domain-- where programmers fear to tread (for good reason).