Reset Password
Existing players used to logging in with their character name and moo password must signup for a website account.
- Sabess 1m
- ZaCyril 10s
- Bruhlicious 17m
- Majere_Draven 4s
- SoftAndWet 10s
- solo 1h
- Baphomei 2m
- Something_Wicked 27s
- deskoft 22m
- Laerad 28m
- Kangarat 49s Rat.
a MirageGM 7s The original cryptid.
- bitMuse 57s
- JakeyBoy 2h
- DancingRoo 45s
- himble 4m
- Enven 7m
- PsycoticCone 51m
- Rhicora 8s Most loved therefore most hated.
- HolyChrome 2m
And 24 more hiding and/or disguised
Connect to Sindome @ or just Play Now

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'd estimate... From my experience playing the game and watching when places stop hiring.

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.

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.

What sort of codebase does the moo's server use though? Even javascript has addable multithread support.
An ancient C engine, with a HUGE modifications, called LambdaMOO.
oh my.
Heh, yeah. Lambda was originally written in 1990.
So, this is a fairly interesting topic, and it caused me to kinda stick my head into the great googling machine.

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.

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.
My question was about IC support.

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?

@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.

There would also be a rather large increase in RP. Just as a random example, there's a job created for every new immy. Someone needs to find out their info. The more of us playing, the more jobs people will be wanting done.
Thank you! Those are excellent answers. 😊
This post is miscategorized and should have gone in Anything Really.

In the future miscategorized posts will be deleted.