@ogged451 FWIW, I was the client lead on WAR, not the server lead, so I had no direct involvement with the server code. As I understand it, the architecture was largely inherited from DAoC without a lot of core changes, so it was a little creaky and couldn't handle some of the things bolted on. If I were to do it myself, with a clean sheet of paper and the knowledge gained from indirect hindsight, the three main things I'd want do (and I sincerely hope I get to, because this is cool stuff!) are:
1. Multithreading. Use it within the main update loop to update characters in parallel. Take the processing of each individual client's networking out of that loop and handle it asynchronously.
2. Hierarchical partitioning of spatial data. Each WAR server process divided the world into coarse cells. In order to determine who was hit by a 5m radius effect (roughly 79 square meters in area), you had to start with a list of everyone in 1 to 4 of those cells (potentially over 50 TIMES the area!) and then run through all of characters going "Are you in this 5m radius?". When a lot of people show up, that's a big problem. When everyone in the bunch spams AoEs, that's a bigger problem. There are far more efficient ways of representing that (quadtrees, R-trees, etc.) so that you can start with a list of only the people very near that radius.
3. At a high level, certain large swaths of the world belonged to certain processes. There was no ability to split one of these large areas into a second process on a second machine if it got crowded and the CPU couldn't keep up.
Right now we've got working tech for 1 & 2, which you'll see in an upcoming demo. Number 3 is potentially something we'll be bringing in from outside if the KS funds.
(And as an aside, to anyone from the WAR team: This is my best recollection of the conversations we had in 2008. My sincerest apologies if I'm remembering incorrectly; feel free to call me out below and I'll apologize publicly and personally.)