[nrb]

I generally agree (object serialization was rough, and stop-the-word saves have been a constant issue for the entire life of the project) but the things it did well were done outstandingly better than POL, Sphere, UOX, Wolfpack, etc.

I think the killer feature of RunUO was that it compiled the C# “script” files and linked them at runtime, eliminating the need to attach a scripting language that provides some limited API. It led to some extremely messy code, but it allowed you to achieve anything you wanted with minimum fuss, using the base .NET APIs that were well-documented. And the community was huge and active by UO emu standards.

It doesn’t fall over with 5000+ clients connected to a single server, which is pretty astounding considering it’s TCP based and players tended to clump up pretty majorly during in-game events and such.

[uo_throwaway]

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 it's scaling easily now. I plan to push the rewrites upstream soon. The emulator still has legs!

[nrb]

My experience is from ~3000 online peak in the mid 2000s, with a more pure T2A ruleset.

Outlands has a breathtaking number of additional systems and enhancements that I’m sure are exposing weak points in the architecture (timers, pathfinding, and distance checking stuff especially).

Amazing shard btw, I logged some hours the week of launch before I got busy over the holidays.

[ztorkelson]

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 with over 10k clients (not just idle, mind you, but moving and talking and whatever else we were able to throw in to the load generators), and the server was able to keep up just fine. That was on mid-2000 era hardware too, but then again, RunUO wasn’t built to really take full advantage of multiple cores.

There are a lot of things I’d do differently if I had the opportunity to go back and redesign it from the ground up, but the simple single-threaded concurrency model is not something I’d want to change without great care. For all the scalability problems RunUO had, I think the concurrency model contributed significantly to its approachability, and I’d be very cautious of making any changes which would complect game logic with concurrency control.

I’ve heard quite a few stories (and now I’m hearing a few more) of folks whose path into software development started by tinkering around with RunUO. In fact, a few of my closest friends (and some now colleagues) took that same path. I am filled with a weird mix of pride and abject humility whenever I have the opportunity to see how the project has touched people all over the world, often in ways I could never have anticipated.

Please do share your changes back. I’d love to take a look at them, even after so many years.

-krrios

[uo_throwaway]

I'll get those patches out soon. Outlands generally is running much more complex AI with much faster response targets, so in conjunction with the far more detailed map it is stressing RunUO much harder than previous shards. But as noted the primary CPU consumer is definitely the map searching. My changes don't entirely change the algorithm (I've adjusted the sector size), but rather take advantage of more recent C# features that are much friendlier to the JIT and shift several allocations to the stack.

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!