Thanks for the info. I'm also curious about the performance of the game with very many rooms (read: more than 10k), with lots of mobs and players running around doing stuff. Judging from what you said about combat, you might have to be fairly careful about not simulating parts of the world that don't have players nearby.

*shrug* If you mean "ambiently walking around", I can tell you right now that doesn't even put a dent. If you mean something more goal-directed, well, I guess it depends what you mean by "doing stuff". Anyways, you have me curious about how I can optimize my code (though, on a mud scale, I am fairly certain "500 NPCs doing 1 complex action every second" is acceptable performance. Maybe I'm just not imaginative enough). Just to give you some insight to how my mud works… I just have an event handler that checks for pending events every tenth of a second. Pretty standard. Right now, all NPC combat happens in lockstep; there's just one giant event that runs over every NPC every second. So, effectively, I'm pushing 1 second worth of combat activity into a 0.1 second window. The smarter thing to do would be to give each NPC their own event to spread the work out over the entire second. Those lag spikes would need about 10 times as many combatants to be noticeable then. Like I said, I haven't even attempted to optimize the code yet. Consider "200 active combatants" an extremely conservative lower bound. Even so, I am quite convinced it is (almost) sufficient for even a highly active mud. I'm sort of surprised you seem to disagree (again, maybe it's just my lack of imagination).

Substantial data on what exactly?
Hmm…





Okay so you'd like to see data on:
1) 500 active mobs
2) a 10000 room world

How many players?
Anything else?

My MUD has some 10k rooms, 20k instantiated objects (more if you separate grouped objects), and almost 3k instantiated NPCs. I consider this to be relatively small, although it is probably one of the larger MUDs out there in terms of non-automatically-generated content. Many mobs and objects have triggers of varying complexity; by the nature of mudprog, these are all relatively simple programs. So yes, I think that a few hundred active mobiles is fairly small, although it depends on what exactly you mean by "1 complex action" per second. I don't have a way of telling how many of the mobs are engaged in combat, but that would be interesting to find out. Combat is relatively cheap in my MUD as the NPCs currently do not have much combat intelligence.

Event handlers are of interest to me, especially if the events are non-trivial (i.e. about much smaller-scoped actions, rather than giant "update everything" types of things).


Well, for starters, it would be helpful if you explained what your categories mean, as you previous statement gave me basically no information. I don't know what "huge", "very huge", "enormous" and "gigantic" mean.

How many of those things are actually doing something more sophisticated than "walking around randomly" when someone isn't there to interact with them? Mere existence isn't really relevant, here. Is it less than 100? Less than 1000? Less than 10,000? Everything?

Heh, see I measure from the other direction. The codebase I
work on would tend to dislike having to have all that stuff
loaded at the same time, since it's designed from a "load
what you need when you need it" perspective. I tend to measure
not how much stuff there is, but how many players can usefully
interact with what there is simultaneously.

An interesting thing I found while testing with hundreds of
non-idle playerbots (aside from how effective they can be
at finding bugs!) is that the results from tests on your LAN
aren't necessarily applicable to "real world".

For example, I found that around 400 or 500 playerbots you
start seeing a little lag. Now, this can be compensated for in
all sorts of ways I dont need to get into…you can definitely
tighten up some settings to make things faster at higher loads.

But what I discovered is that when you set up distributed bot
clients to fire hundreds of bots into a test mud across the
internet, the results change dramatically. You wind up being
able to have even more players with even less lag. It turns
out that "in the wild", connections to your mud don't happen
at loopback or even LAN capacity. Perhaps my methodology was
not hadron-collider quality, but I suspect that testing locally
does generate skewed results.

And then there's the fact that in the real world, players
take coffee/bio breaks, or just stare at their screen waiting
to heal, or…etc. Relentlessly-unidle-playerbots also tend
to skew the results.

Don't get me wrong, I value efficiency, and recently I
did a bunch of work to make sure things work fine even
on the crappiest machine I have, a 133MHz 40m RAM Pentium I.

But after a while of tweaking and lubricating the bits…
it does start to feel like minmaxing.

I guess what I'm getting at is "practical purposes". While
it's occurred to me to tighten and streamline such that 1024
players can log on with no lag….where would I go with that?

-Crat
http://lpmuds.net

Well, I would disagree rather strongly that mere existence isn't an issue if you still are doing housekeeping on things that merely exist, even if just making them wander around randomly. But, yes, many mobs are doing more interesting things, even if players aren't around. More than 100 certainly, but I don't know if it's more than 1,000 offhand.


Well, yes, it seems pretty clear that if you're testing something based on the bandwidth of sending and receiving, the bandwidth itself is a very important bias in the test.

My question isn't just about players, though. Actually, I have the impression that people are starting to argue with me about what worlds should or shouldn't do. That's not the point of my question: I'm only trying to get a feel for real-world experiences on non-toy worlds with active players.

We use NakedMud for Maiden Desmodus and I'd recommend it. I've even been able to get my codephobic building partner to start doing more complex scripting because he finds it so easy to use. The codebase is also actively maintained and supported with a mailing list, irc channel and some decent documentation.


There is very little that you can't accomplish completely in Python and I believe that in the next release Geoff will have opened up the last remaining parts of the C code to Python.

We've got a whole game created with description driven interaction, real time combat, PC shops, banking, NPC scripts and dialogues, 350+ skills, stats, PC run guilds and factions, elections, generated quests etc etc., and all I've had to do in the C code is some minor tinkering - every major system was written entirely in Python.

Well, like I said, I never looked through it thoroughly but my major concern is -changing- major systems. Not adding them. I like things to work My Way :P. How much editing would need to be done to the core if you wanted to say, change the way areas are layed out to work more like SourceMUD? Or say, work with a DB rather than flat files. What about web integration? Can you import any of the python libs into the scripting in-game, like, say I wanted to plug in PIL, or the twisted framework…

I have seen server applications far more massive and under far more stress than any MUD (even back when they were actually popular) run without missing a beat on modest (modern) hardware. This isn't really about MUDs. It's about the fact that here in 2009 you just don't need C/C++ to get adequate performance for anything but the most demanding applications… and even then, you usually only really need C/C++'s performance for a few small sections of the app (heavy number crunching, usually).

Older versions of Ruby were VERY slow, so they might balk under heavier load, but ever since Ruby 1.8 or 1.9 speed has not been a concern (Until relatively recently, Ruby's interpreter was just a recursive algorithm operatiing on the parse tree. Newer versions use a decently written bytecode VM. Future versions are likely going to see a tracing-JIT VM.) There are full high-performance 3D games and truly massive MMO servers all running off of Python, which actually has worse performance characteristics compared to the latest Ruby runtime.

Little to no editing? As far as I can tell from looking at SourceMUD, NakedMud already supports what you describe.



Very little. All data are turned into a generic intermediary structure (called a storage set) before being written to disk. It's a glorified hash table. To work with a DB instead of flatfiles, all you'd need to do is translate these to and from database tables instead of files. At least, that's what my slowly growing knowledge of RDBMS leads me to believe. You could just as easily make things be stored as xml files, or something of your own design. How things are stored is abstracted.



Yes

Okay what I got from piecing together your responses to Hollis and Cratylus is that…

You would NOT like to see data on:
1) 1000 active mobs of 3000 instantiated
2) 10000 room world
3) 20000 objects
4) 500 players

Because you consider that to be SMALL.

So again…


My response was a joke. On the other hand, you want empirical data or real world experience on something you aren't willing to define, just dismiss. Now I might be able to get data, but I'm not willing to bother if you're just trolling. And seriously don't you think you're already pretty close to defining what this community (I think) generally considers huge muds as small or toy muds, making this psuedo-debate over language choice not really relevant to anyone reading?

I'm not entirely sure why you think I don't want to see data on that. I merely said that that's my world size, and I don't consider it "huge". I talked about it in the first place only to give context for why I don't think a few hundred active mobs is terribly interesting in terms of size. I'm not sure where your "500 players" figure comes from.


I think I've given fairly clear lower bounds for what I consider to be an interesting size. The accusation of trolling is simply insulting and uncalled for. I asked you a question, you responded with a joke and then asked me what I wanted data on. I then tell you what I want – clearly you have some idea of when things start breaking – and you retort that I am trolling.


I think you're hearing things that I haven't said. I never said that the figures I gave defined a toy MUD. I don't consider my MUD to be of toy size, I just don't consider it to be "enormous" or "gigantic".

I'm not exactly sure why this is getting you so riled up.

One distinction that I feel is important to make clear is exactly how you can USE the data you've put into your RDBMS. It is, of course, fairly easy to replace files with tables and shove all your pickled (I think that's the correct python term for serialized) data into rows of a table. It is NOT so easy to generate a functional schema that would let you do real-time queries against such data, let along live editing of the data from an external client.

A good schema with foreign key constraints, bounds checking, and a few other tricks one can use in an RDMBS makes it very easy to add game content via graphical clients (web based or not), but without having all those relationships built into the DB, you have to duplicate the code to do all that checking in everything that touches it. THAT is not so fun. :)

If I understand you correctly… yeah, fair point. The way I was thinking about the question was in terms of editing world information and force-reloading instanced copies of things that have been edited. I think that would still be doable with very little modification. I suppose it gets complicated when you want to query (and especially edit) specific, instanced things (or players playing). I'll admit I do not understand the complexity of these issues as well as I could. Perhaps it's harder than I anticipate, without doing serious edits to the existing code. Maybe somebody will give it a serious try, and let the NakedMud lists know.

Any chance I'll get an answer? :sad:

He probably felt that the bandwidth savings weren't worth the hassle. Seems like the main reason you wouldn't do it to me. :shrug:

He addressed that here.

I don't particularly think it's even a useful or good idea to try to allow that. Give your MUD some kind of browser-friendly RPC mechanism (basic HTTP plus either JSON or XML) and let it act as the middleware between your web applications and your data store. That even negates the need to use SQL at all and lets you stick with flat files, and allows you to keep all your "business" logic inside the MUD server instead of having to decentralize it to several different layers.

The only argument I can really think of against using the MUD itself as the interface for your web apps is the fear that those apps will rbeak if the MUD goes down… but honestly, you're MUD shouldn't even be going down. You can also duplicate any super-critical iniformation from the MUD into a SQL database used by the website, so things like site login and such can work fine. Or, alternatively, just let both the MUD and website access the easy stuff directory in the SQL (user accounts) and keep the more complicated stuff behind the MUD's API.

Slapping in a basic HTTP server and XML-RPC API (or a home-grown JSON-based API) is really freakin' easy. If you're coding in Python/Ruby/Perl/whatever then changes are you already have a reusable RPC mechanism available to you. If you're on C/C++, there are plenty of libraries to use that make it easy enough, or you can just write your own if you're interested in learning the HTTP internals (what little there are).

Eh, there are enough details that are sufficiently annoying that I'd not recommend this as anything other than a learning exercise. It's too easy to screw things up in subtle ways and introduce security holes that I'd recommend using something that's been bullet-proofed to some extent.

I also get a little twitchy about live editing of a DB causing instant reflection of those updates in the MUD, and would also suggest some form of RPC instead if that goal is desired.