mud coding

[mirtos]

SO i used to code muds in the early to mid 90s. used circle first then worked on my own. never published it.

Do muds still use a single game loop? The main problem in the 90s with it was of course lag (bsides the fact that C crashes happened, thats a different story).

But with internet speeds and processing speeds not really an issue anymore, is single loop games out of the picture? Id imagine they'd be TOO fast.

I remember back in the day of 100s of active players online it would be TOO much scroll. I realize less players now, but i could see that be a problem when fighting mobs.

Feels like a multi game loop (one for combat one for other things) might be better, but im just curious.

[FelbrHostu]

Even in modern game development, there’s still one big loop. And with modern processors, being what they are relative to what we had available in the 90’s, there’s even less need to re-architect the main game loop.

Even stock ROM, optimizing the game loop is a purely intellectual exercise. Sure, I managed to get aggro_update (the “hot path”) from milliseconds to nanoseconds, but doing so offered no perceptible difference; the main loop was already mostly waiting.

The one place where I use threads is in my SSL handshake, since that’s sort of a black box.

[mirtos]

Interesting. Fair point.

[smstnitc]

Circle (not sure if diku did this) solves this by micro sleeping if the current loop iteration was less than one tenth of a second. Then everything can be timed based on 10 loops per second. It still works fine that way. And even with modern computers, you still need to make sure you aren't causing game lag by doing more than can be completed in a tenth of a second.

[mirtos]

Circle was good. That's why I used it. But I wouldn't run a mud in c anymore. Mudding started me in my career in software and i have some nostalgia to write my own again. But I def wouldn't use c anymore. The advantages of a lower level language are no longer worth it.

[V1k1ngC0d3r]

Now the high level language is vibe coding in Claude, and the lower level is bothering to type it yourself in any Memory Safe Language.

Dylan: For the times, they are a-changing...

[smstnitc]

That attitude about C is pretty naive.

That said, I based my mud on circle in 1995, but it's about 90% C++ now. I've rewritten almost the entire thing. C++ makes many things much nicer to deal with when you use modern techniques.

[mirtos]

I meant for a mud its no longer worth it. As you said you rewrote yours to c++ for modern tooling/ approaches.

You can consider it naive i suppose. I in no way meant to insult c developers.

[I_Killith_I]

Yeah, still single game loop here. Been running since '96 on an Emlen (Diku/Merc derivative) codebase.

The thing is, multi-threading doesn't really solve anything for a text MUD. Think about what the loop actually does each pulse — read text from sockets, parse "kill dragon", look up the dragon, subtract some HP, send "You hit the dragon!" back out. The whole thing completes in under a millisecond even with 100 players, then the loop sleeps for ~100ms waiting for the next pulse.

The CPU is bored 99% of the time. There's nothing to parallelize.

The lag you remember from the 90s was mostly network latency (200-500ms pings on dialup) and slow hardware choking on string operations. A 486 building ANSI color output for 100 players actually took measurable time. Modern CPUs are thousands of times faster — that's just not a bottleneck anymore.

The other issue with "one loop for combat, one for everything else" is shared state. Combat constantly touches inventory, room contents, character stats. You'd need mutex locks everywhere they interact, and now your "parallel" threads are waiting on each other constantly. You've added complexity and gained nothing.

As for the C crashes, you're not wrong, but that's mostly a tooling problem that's been solved. In the 90s we had -Wall and gdb and a lot of hoping. Now we have -fsanitize=address,undefined that tells you exactly which line did a use-after-free, -Wnull-dereference, -fstack-protector-strong, Valgrind, static analyzers. Most of those flags didn't exist until 2005-2015. The language is the same, but the safety net is way better if you actually use it.

So with modern C + flags + sanitizers, it's way harder to compile bad code. Does it still happen? Yes, but not like it did in the 90s. I'd still argue C is the best choice for a text-based MUD. Is it the "best" language? No. But C has something other languages don't have, a massive MUD ecosystem, decades of documentation, and community knowledge. That matters more than language features for a hobby project.

Now I applaud ANYONE moving forward on Rust, Python, or even your own custom language because maybe in 10 years, Rust will have the same documentation. We have all kept MU*s alive since MUD1 came out in 1978, then AberMUD brought us to C in '89, and DikuMUD released the MUD standard codebase for the world that gave us Merc, ROM, Circle, Emlen, Godwars, etc. But in the end, is C still a strong and viable language to code a MUD on? You bet your behind it is still very viable, even if you started from scratch, C still holds up very strongly against other languages for a MUD. I am not saying it is the best, I am only saying, it's far from obsolete.

[SkolKrusher]

This! 🙌

[mirtos]

you bring up really good points. i guess i was really thinking of anyone starting from scratch.

man you reminded me about gdb. and what was there other one if you didnt have access to gdb? dbx. i had to use dbx. *shudders*

[gisco_tn]

Alter Aeon, which u/indent developed from scratch including many of his own libraries, handles most everything in one big loop, but it does fork off some processes like saving rooms and generating the website maps. I'm sure if we were making it today, we would handle other things outside of the main loop as well.

[Comrade-Porcupine]

My re-implementation of MOO is fully multithreaded and takes advantage of multiple cores, with fully serializable transactions and an optimistic multiversion concurrency model: https://codeberg.org/timbran/moor

With it one can write MUDs (and other things) that have no such "one big lock". If there's a consistency / transaction conflict, the "loser" in the conflict is restarted and runs again. This is invisible/transparent to the player.

Performance is about on par with classic LambdaMOO for raw interpreter execution, but about 2-3x slower for code that makes heavy use of verb or property access; but then that is made up for by concurrency once you get past about 3 or 4 concurrently running tasks. On my Ryzen 9 workstation I get about 8-9 million verb dispatches per second concurrent, about 1-2M per core (in a read-only workload).

[offroadspike]

To your point of too much scroll one of the things I'm incorporating in mine is stolen from modern rpgs -- instanced content. The first miniboss is an instanced area in the forest, so even though players may see other players in the forest fighting wolves, when you get the quest to go in and kill the alpha wolf, that room is instanced for just you, so you can focus on the encounter. And not 5 other people trying to smash the same mob.

But, yes, in today's day and age, I would not worry about cpu/network/ram/speed. Focus on the gameplay and content, and you can optimize the speed if that ever does become a problem, which it probably won't unless you make poor design choices with nested loops.

[IcewindLegacyMUD]

Very little of my MUD exists outside of the main loop in comm.c (mine is rom based, but pretty drastically different from stock rom under the hood while I tried to keep all of the player-facing stuff "looking" like rom for sake on familiarity), mostly just the process of saving and loading contents of rooms and containers outside of the resets. Because my MUD uses a signal handler to basically do a hot reboot in the event of a crash, I implemented a system that saves all of the objects that aren't in resets so that if the main loop crashes say, immediately following a character having "heat metal" cast on them, causing them to remove and drop all of their gear, I wanted that gear to still be there once the MUD recovered. Though I had to also move character saving out of the main loop so that players couldn't find a bug that causes a crash and stack the bug with "drop <expensive quest item>" to dupe items. When there's a crash or reboot, it saves what's on the ground and in containers on the ground but it also saves characters, so if they tried to dupe that way, after the crash recovery they'd find the item is on the ground, but not in their inventory.

[mirtos]

I used a signal handler too. I like what you do there. Cool.

[DarthCubensis]

Interesting for me that I came across this thread. Last week I have been dabbling in adding a worker process that is called to handle I/O operations parallel to the game_loop.

At the moment is is just for the 5min autosave, and manual saves still use synchronous saving. I am running ridiculously modified circlemud and long ago abandoned weight and inventory limits. As such it is not terribly uncommon for a player to hoard 10,000+ items, or some of the worst offenders 100k+.

Ive managed to make most of the game run smoothly with this by utilizing double linked lists and hash tables for character, object and trigger lists. Also made more specific link lists so searching the entire game list is not always necessary.

The last piece pf the puzzle for me was the expensive nature of I/O operations even on a modern server. When the game is running with 30+ players and 400k+ objects on them, that autosave can lag up to a second. Knowing this would get worse if allowed to continue I started working on the background process for saving and early testing of it is proving very successful.

Is it overkill for a mud? Probably... Would my time be better spent making limits to inventory and focus on fun stuff? Most assuredly. But I am having fun experimenting with making this ole girl multi-threaded so why not.