Max number of players?
Just out of curiosity

How many regular players can the world handle right now? Like a total among coded jobs, gangs, corpies, WJF, street urchins, etc. before it's like, too crowded to do anything more?

A couple thousand? Less than that? More?

I'm a bit nerdy on this subject.

Every MOO codebase that I am aware of has some serious limitations on the number of concurrent users. Even though they are the predecessors to the modern MMO, they have some technological constraints that will cap the number of active users at any given time much lower than what you would have on a modern MMO. On the same token though, they are able to be hosted on hardware as simple as a older model rasberryPi. A one gigahertz CPU with a single core and a gigabyte of storage or less is often going to be more than sufficient for a small MU* running a low number of concurrent users.

The biggest limitations to users would have to do with the number of coded systems that are running in the background. Generally, the more codedly complex the game is with systems that players are actively interfacing with, such as combat- as well as systems that are regularly scheduled to run as jobs (levs, mementos, etc) will place further loads on the server.

Some of this can be alleviated by offloading tasks to other cores and being smart about scheduling, but these are all considerations that have to be made when discussing the overall quality of play. (Do we want players waiting say, 10 seconds on a move command? 10 seconds to a combat round, etc?) Even with modern technology present in CPUs with multiple cores, or multithreading support, in many cases game 'loops' for MUD/MOO are run as a single-threaded application. You are, afterall, still connecting to a server in a terminal/server connection. The server has to perform all validation of user commands, execute those commands, and then update the connected clients accordingly to changes in game state. Unlike most games, the server cannot offload tasks to game clients on the client side, as there simple is no client in a text game as we have with SD. So there is no virtual scaling whereby the game developers can use client machines to do computational tasks and alleviate the workload on the server.

TL;DR: MOO's don't scale well. The more mechanically complex they are, the less they are going to be able to support additional users. A complex game like SD is going to be able to realistically support far less players than say, something simple like a 'talker' RP game, I.E. a chat room with basic enhancements like character sheets and some simple verbs.

An ancient C engine, with a HUGE modifications, called LambdaMOO.

Heh, yeah. Lambda was originally written in 1990.

As I mentioned in my post, even with multi-threading, it's often the case that jobs are tasked out to other threads, and the main game loop is still going to be a single-threaded application. That's the bottleneck. We're playing via TELNET protocols, over TCP connections. These things have to be maintained in lockstep order. Therein lies one of the big problems.

@RedSteelButterfly LambdaMOO continues to be developed in various off shoots like Stunt and the Haskell version you mentioned but they are not nearly as stable (though Stunt has come a long way in that regard since we first looked into it). For a game like Sindome, stability is our biggest concern since we are 24/7 always on, and senior coders are not always available to diagnose random issues that come up in the middle of the night that could take the game down for hours or days.

One of the reasons you will see me posting about performance optimizations and such at various times, or removing dead code, or optimizing some task, or adding caching, is specific due to what Talon said, which is the MOO is single threaded. That means there is an upper limit to how many tasks the MOO can run at any time.

It also means that when I make a major performance optimization (doesn't happen often these days) the overall 'lag' of the MOO drops. Meaning commands actually execute faster. However, you can be assured that your commands are executing at the same speed as any other players commands, so if the MOO slows down it slows down for everyone, if it speeds up, it speeds up for everyone. I once made an optimization to some underlying code that made movement 0.002 seconds faster :)

Still, the MOO can handle billions of lines of execution per second, so we are not nearing our upper limit. We've had 100+ people online without any noticeable lag. Things like combat would be the first to slow down, but we've had RampageMOO (dozens of players and hundreds of zombies) all fighting at the same time and it's added some lag but not a ton. We haven't neared peak utilization or peak optimization when it comes to some systems, meaning there is plenty of room both to grow our playerbase, and plenty of room to optimize further as issues come up, before we hit diminishing returns on a single core.

@ynk We are constantly adding/removing jobs and other things as the player count changes. It's not a static system. If we had twice as many players, we'd introduce additional jobs.

Thank you! Those are excellent answers. 😊