Advanced Topic - Doing it differently.

Hiddukel hiddukel at
Wed Apr 6 03:20:44 New Zealand Standard Time 2005

I apologize for the length of this message and this will be the last from me
on this thread as no one else on the list seems to be interested in this

-----Original Message-----
From: rom-admin at [mailto:rom-admin at] On Behalf Of Christopher
Sent: Tuesday, April 05, 2005 9:57 AM
To: rom at
Subject: Re: Advanced Topic - Doing it differently.

> How so? Is this based on knowledge? Know anything about coroutines?
>Did you know that they are faster than processes and threading? Did
>you know that they also lessen the resource usage because coroutines
>don't access the OS kernal whatsoever? Did you know that it was first
>done on Linux but is also cross platform capable?

Muds of old didn't use coroutines either so as I said your argument of you
don't need this stuff because old muds didn't have them and they ran fine is
not valid on this point either.

> I've never seen a mud with 1000's of live, in use profiles...

You've never seen mine, I'm not saying that there are 1000's of people
logged on at one time, but there are literally 1000's of pfiles that at the
very least get used once a week and therefore are considered "in use".

> Sorry to tell you but rom won't load them whether you use a database
> or not. A database with that many would make the mud so unplayable it
> would be useless.

Sorry to tell you but it will and does load 400,000+ rooms willingly and
with no adverse affect (besides the fact it takes up huge amounts of memory
but memory is cheap).  You obviously have to change other things about rom
to make this totally playable, things that I have changed but are beyond the
scope of this particular thread.

>I hope that all of your decisions are not based on "Could be" events
>in the future.. I'm trying to plan for future expansion as well but I
>am at least trying to do it based on logical facts and not some "would
>be" examples.. As I said before, I see a logical solution for
>everything than can be mentioned.. It comes from years of research and
>learning.. I guess that's why I've learned to get around many of the
>problems associated with the standard codebase simply because I needed
>to do so.. Not because I thought I had too..

If you yourself don't need an sql backend or threads or coroutines or any of
the newer technology that muds are migrating to today that's fine, but my
decisions to use them are not based so much on the future as they are
solving problems that I have had in the past and continue to have today.  My
mud does have over 400,000 rooms, a lot of those are wilderness granted but
still stored in the areas and rooms databases and still loaded into memory
100% of the time and still occasionally need to be saved or searched
through.  So just because you've never seen it or for some reason believe
that a modified version of rom "won't load" this many rooms doesn't mean it
actually won't, hence why I said try it and you may start to understand my
personal decision to use an sql database and threads.

As for the years of research and learning that you keep trying to throw in
people's faces, I'll answer to that only because you keep bringing it up.
I'm no spring chicken, I have my BS in computer programming and have been
working with C since 1994 and countless other languages before then, some
you may have never even heard of.  I'll admit I've only been working with
muds since 1998 or so but to tell you the truth anything written before then
doesn't interest me because I'm not writing a nostalgic mud of old, I'm
pressing the limits in proof of concept muds that with time could compete
with mmorpg's, but that is not my goal.  My goal is nothing more than to
realize my vision of a mud with a world that you couldn't possibly explore
all of in a years time.  I'm not hoping for thousands of simultaneous
logins, but if it gets to that point I won't complain, I'll simply start
working on linking servers together to handle the load.

>I'm not knocking you for your examples.. But you are a bit off on many
>of your interpretations of C..

I'm also not interpreting C ... what I said about the language of C is
valid, it is not a scripting language, yes you can add scripting languages
to it or build a C style scripting language for your mud and I have no
doubts if you really wanted to you could add a php enabled web server
straight to your mud, but when some immortal searches through all your area
files with no database or even threading on your mud it will lag all the
players.  I'm certainly not saying there is not other ways to handle the
problems I've dealt with myself using sql and threads, but they are problems
none the less that were not in "general muds of the mid 90's" and need to be
dealt with in some fashion that wasn't used on those muds of the mid 90's.

All I'm trying to say is just because you or someone else doesn't "need" a
particular technology doesn't make it wrong to use it if it does solve the
problem in a fashion that does not make the mud unplayable.  I didn't simply
jump on the sql bandwagon, I tried other options and none were right for me
and my mud so I eventually arrived at using sql and threads.  Nobody is
asking you to use them, but it's also not your place to say that the mud
community as a whole is wasting their time with it simply because you had an
idea for a mud client that you thought someone should have already


ROM mailing list
ROM at
Unsubscribe here ->>>

More information about the MUD-Dev mailing list