Earlier quoted context omitted.
It actually falls over around 1000 clients if they're actually playing and encountering one another at any regularity. I have been contributing to a new RunUO based shard ( http://www.uooutlands.com ) that has become extremely popular and hit 2k clients online. The lag was pretty extreme at first, but after a few weeks of studying CPU profiles I rewrote a lot of the map search algorithms, plus a few other things, and…
Congratulations on the launch! I’ve heard great things about Outlands and have been meaning to log in and check it out. It’s been a long time since I was involved in the RunUO community, but as I recall, one of the biggest limiting factors on scalability was activated NPC/AI. Range queries and movement were the two big pieces, so I’m sure your improvements would have a big impact there. We ran load tests on Hybrid wi…
I'd also like to move away from timers for mobiles and simply call a function on a subset of them (sector by sector) each tick. This is advantageous because it groups all of the processing for a set of nearby mobiles in game space together in time, so it should greatly improve the CPU cache hit rate during the map searches. That would also require moving RunUO to a constant tick rate, which I also have patches for.
If anything, my changes have made RunUO more single threaded (and eliminated some locks in doing so). This has proven to be faster than some of the previously highly parallel code because the contention was so bad. That's not to say that it couldn't be done in a way that did scale well, but I agree with you that it would put the code out of reach of hobbyists entirely. I think the code today strikes the right balance of approachability and performance. Thanks for all of your effort on this project!