[MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence
Kwon Ekstrom
justice at softhome.net
Mon May 14 08:59:22 CEST 2001
From: "Bruce" <bruce at puremagic.com>
> But there are plenty of things that aren't done well by existing
> codebases (at least in released versions).
> * Monitoring/Logging systems.
*nod* I've always hated how poorly logging was done on every mud I've
worked for... It's one of the major things I'm working to improve on
my system, I intend to store logs in memory, which will phase out to a
temp file, and eventually get deleted. The major features I'm
allowing is for Logs to contain additional data than just the brief
description. I'm also planning on attaching logs directly to certain
types of reports (punishments, board notes, etc), as well as being
able to send a log to someone who would otherwise be unable to view it
(to show a player that yes we do have proof they did something, or to
ask advice from visiting admins)
> * Unit tests.
Could you be more specific by what you mean by unit tests? There are
a variety of consistancy tests that would be nice to have :)
> * Use of transactions (with the sorta-exception of DGD with its
> atomic methods).
I had thought about using a transactions type system for my server,
but I don't think that I'm going to for various reasons (mainly
because I'm spending enough time adding other "nice" but "unnecessary"
features). Although I think a transactions system would be wonderful
to aid in synchronizing data. Perhaps if I ever get around to
distributing my server I'll add in a system to handle this.
> * DB robustness in the event of server failure.
This covers alot, unfortunately I can't say that my DB fits this bill,
although my server is extremely robust. Using java exception handling
I've only managed to bring the server down once... um, that happened
to be because of a bug in the channel code generating a log, logs
sending the data to the channel code so you could see it online, and
the eventual stack overflow. Stupid bug really, gotta watch them null
checks.
> Other things, like distributed servers, capability-based security,
> or clustering are roughly understood, but the mud community hasn't
> really
*nod* Distributed servers would be nice, but for 99% of the community
it's unnecessary. For a commercial massively multiplayer server, I
could imagine needing this. As for capability based security, that's
my goal... to separate administration from the regular player
advancement. I'm sure commercial muds have done this through the use
of flagging, or extra values, I'm using an int array to divide
security permissions by function. Currently using Security, Admin,
Builder as the dividing lines.
Clustering would be nice, but I think that's an extention of
distributed servers.
-- Kwon Ekstrom
_______________________________________________
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