[MUD-Dev] CoolMUD lives!, sort of.

Miroslav Silovic silovic at zesoi.fer.hr
Wed Aug 22 15:43:48 CEST 2001


Bruce Mitchener <bruce at puremagic.com> writes:
> Robin Lee Powell wrote:
>> On Tue, Aug 21, 2001 at 04:48:01PM +0200, Miroslav Silovic wrote:
 
>>> Boot time. You /really/ don't want to load gigabytes of data
>>> prior to accepting any connections (and yes, my favorite test
>>> subject does have gigabytes of persistent data. On a 32-bit
>>> arch, you can't even mmap it.)
 
>> Gigabytes.  It a text-only not-for-pay MUD.
 
>> You _must_ be joking.
 
>> What the heck mud is _this_?
 
> I'm pretty sure that Miro was referring to The Eternal City.  We
> were previously free, but now part of the Skotos collection of
> games.  Check it out at http://www.skotos.net/games/eternal-city/.
> We are text-based. :)
 
> We're sitting pretty close to a 2G database.  We use an
> as-of-yet-unreleased version of Cold that is much faster than the
> current release.  Recently work has been done and tested to make
> sure that it can handle DBs well over the 4G mark as well.

Furthermore, I used to host Harper's Tale MOO, which, at the time,
was a very small MOO - 20-30 players connected at the peak times,
and 500 players total (more or less). dbsize was 10 megs or so, It'd
take a minute to boot and about 30 megs of memory. While not
unacceptable, it's obvious that it wouldn't scale to a /real/
playerbase without a buff, dedicated server.

Another thing about diskbased systems... When you know that your
performance won't suffer too much from the increased db size, you
don't have to worry about db size. That influences certain design
decisions. I.e. you can have helpsystem in-db without worrying about
its size, you can keep the backlog of years of mail and news (which
certainly gives your players something to read) and you can have
persistent, autogenerated areas on a large scale.

--
How to eff the ineffable?
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list