[MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence

[Bruce]

Derek Licciardi wrote:

> Bruce: Enterprise level software is simply a term meaning

I much prefer to discuss in terms of something like your paragraph
below. :) I've often heard the term 'Enterprise level software', but
everyone wants it to mean something different, especially some of the
vendors that I've had to deal with in the past.  Ugh.

> robust, stable, scalable software.  It is software that was
> developed under a system of code review and other best practices.
> It is software that reported status back to its operators, and
> allowed for configuration without taking the server down.

All software should be so configurable. :) In practice many things
don't appear to be, which has led to me having to write my own
versions in the past.  An example of this that will have to be dealt
with soon is that I'd like to just use syslogd for logging, except
that you can't create new log facilities at runtime, which I'd view as
a necessary feature.

> When I think of enterprise level software, I think of operating
> systems, DB servers, mail servers and web servers.

It is probably fair to just say any 'mission-critical' software here,
since the same standards apply.  Presumably, if you are running a mud,
the mud server software is critical to doing so. :)

> I am thinking of features that typically do not exist in MUDs today,
> better backup and recover schemes, better 24x7 support, perhaps
> paging and alert support for events requiring support.

Muq has support built into the driver for maintaining a historical set
of backups (that get thinned out over time).  Cold does something
similar with an external script.  Both could use better support for
manipulating a database directly without running an instance of the
server for performing emergency maintenance though.  I'm unfamiliar
with how DGD handles any of those things.

Support for paging and sending emails for disastrous events is
something that I'm hoping to add in the near future once we pick up
good logging infrastructure (as I discussed in a reply to Kwon)
recently.

> How about the ability to use decision support tools to better
> analyze things like class balance and object hierarchies.

I know of some muds that do this.  I thought the BatMUD people kept a
lot of statistics.  Another mud that I knew did was the Harper's Tale
MOO.  I asked one of the (former?) admins, Shirgall, who also happens
to work on the DB side of what was Informix, for a comment on it:

--- begin quote ---
  There are many aspects of administering an online environment that
  use methods common to Decision Support Systems. For example,
  statistical methods are often used to summarize the player
  population, their connection activity, their use of objects in the
  database, even their own usage of space, CPU time, and other
  administrative details. The object database itself is a huge fact
  table that can be split up along many dimensions and summarized. For
  example, on Harper's Tale MOO I wrote statistical analysis on the
  ownership of virtual money in order to spot hoarding and
  cheating. In fact, much of the analysis is done to see when the
  business rules (in my case, the game rules) were stretched, bent, or
  broken.  In the final analysis, much of the same problems businesses
  have understanding their customers and related data carries over
  into online environments with their users and related data.  
---- end quote ----

In the discussion about some of the RDB vs OODB stuff, one approach
that hasn't been brought up is something that I've seen used to
support data analysis in the past: log events to a file, and later,
import that file into an RDB and do the analysis there with that set
of tools. Sometimes, that can be more effective than cluttering up the
OODB with a bunch of data that is otherwise useless during the runtime
of the game.

> On the development side, the code would be reviewed, change
> controlled using a two or three server process and would be designed
> to support better expansion in the future.

All good stuff.  But it is somewhat harder to do without a paid
staff. A lot of people don't seem to want to deal with that level of
rigor when they're volunteering.

Overall, that was an admirable list of goals and design constraints.
I don't necessarily think that -no one- is working towards that,
because I definitely am, and I've been privately evangelizing some of
these same ideas with other server developers.  But, like much that
goes on with mud development, there isn't widely spread knowledge
about what's happening, what the best practices might be, or much
empirical data at all.

  - Bruce

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev