[MUD-Dev] Server stability (was: Player statistics)

Ben Chambers bjchambers at phoenixdsl.com
Wed Jan 17 17:41:51 CET 2001


<EdNote: Quote trimmed>

----- Original Message -----
From: "Koster, Raph" <rkoster at verant.com>
To: <mud-dev at kanga.nu>
Sent: Wednesday, January 17, 2001 7:58 AM
Subject: RE: [MUD-Dev] Server stability (was: Player statistics)

>> -----Original Message-----
>> From: Bruce
>> Sent: Tuesday, January 16, 2001 7:41 PM
>> To: mud-dev at kanga.nu
>> Subject: Re: [MUD-Dev] Server stability (was: Player statistics)

>> I do recognize that there are some updates that will very likely
>> require downtime and that the engineering cost to avoid those would
>> outweight the benefits.  But with some of the trends that are
>> currently visible in the industry, I wouldn't be surprised to see
>> smaller updates become more common (and therefore a necessity at the
>> technology level).
>
> Given the QA process involved in posting changes to live servers, even
> small updates have significant overhead -- too small a change is more of
> a pain to test than getting several small ones into one update. So an
> "optimum size" seems to be what has evolved.

I don't see why it should be necessary, unless you are re-writing a
server.  And if you had a setup with scripts and stuff you shouldn't
need to do this.  If rooms change, re-output them.  If scripts change,
implement when the person re-enters the room.  If areas are added,
people can now get to them.  The only actual need for downtime is for
wiping players accounts but that should be able to be done all uptime
as well.  I am trying to write a MUD for Dummies server.  Basically it
is a MUD with a visual front-end.  It will hopefully have scripting
capabilities.  The key I am planning on for this, is developing a
stable server, and then everything else is just data dumps and data
reloads.  Once again, no 'downtime' more like a re-boot.


_______________________________________________
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