A couple thousand? Less than that? More?
200-250 total players in a 24/7 span roughly. Assuming everyone got jobs and they were spread out in the ratios that all the jobs required...
Not gonna get into specific breakdowns, but the earliest positions would crowd out first. As those are considerably more competitive.
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.
https://lisdude.com/moo/
There apparently exists multi-threading versions of LambdaMoo serve in both Haskell and C++. I thought that was interesting to see that the server code is being updated still.
Assume no computer or GM restraints.
Like there's what...
9 corporations x 15 max characters in each
Service mixers in 9 careers x 4 characters
20 or so shops with coded jobs x 4 characters
9 bars & organizations x 10 characters each
25 or so each of solos, dips, and muggers
35 runners & urchins
= Like 500 dedicated players?
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.