Since I’ve always had problems with my connectivity, and don’t have the best connection to begin with, I never really considered that the servers were ‘over-capacity’ or struggling to sustain the player count. Friends had frequently told me {when asking} that they never experienced “lag” even when the servers were full. So, I’d just assumed this was on my end.
That said:
Absolutely.
Easiest method would be to just throw faster hardware at the problem. If that’s not possible, then you have to move onto actual optimization … and if your backend code is already tuned to the point this is difficult to squeeze more out of it {already parallelized, low thread-contention, well written code} – you start taking shortcuts.
Shortcuts means that you simplify checks and other calculations or reduce the frequency of them.
For example, under the hood all game-logic will operate at a ‘tick-rate’. Different mechanisms of the game’s logic may happen at different frequencies [AI decisions, network-frame updates, entity movement, actions, etc]. A very easy way to reduce the overhead of a game, is to just increase the time between whatever the most expensive ticks are. → NOTE: That’s easier said than done.
– Decreasing the number of ticks increases the time to complete operations without falling behind.
– There are less calculations and updates happening, which directly translates to reduced-load, and thus increased capacity.
– Game mechanics may not behave properly at a lower tick-rate. {has to be tested thoroughly}
– Larger time between ticks increases perceived latency to players. {at lower capacities, there’s more-delay}
It was stated in one of the official posts that hit testing was done by playing out the full skeletal animation of a character on the server-side {to make dead certain it was sane}. Though it would reduce accuracy, this could be dropped to just a basic and quick hitbox.
In jist, there’s plenty of ways to cut corners and squeeze more performance out. Some can be done dynamically, like tick-rate, where tick-rate could be dropped on the fly as population increases or the server reaches capacity.
EDIT: On the hardware front, depending how things are structured it may also be possible to throw ‘more hardware’ at the problem, rather than just faster hardware. Divide and conquer, further splitting of any server cluster.
