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

Derek Licciardi kressilac at home.com
Mon May 14 10:15:42 CEST 2001


> -----Original Message-----
> From: Greg Munt
> Sent: Sunday, May 13, 2001 7:34 AM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence

> -----Original Message-----
> From: Derek Licciardi <kressilac at home.com>
> To: mud-dev at kanga.nu <mud-dev at kanga.nu>
> Date: 13 May 2001 7:03 AM
> Subject: RE: [MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence

>> I do believe that to accomplish some of the ideas that people
>> express on this list, it will require larger servers.  This will
>> more than likely change the scope of a MUD that wants to be that
>> ambitious and turn it into a full fledged commercial venture.  The
>> next wave of ideas we discuss here will most definately require
>> more than just a single man shop running the game on spare hardware
>> in some ISP or school.

> Which ideas do you think demand larger servers? Why? What is your
> definition of a "larger server"?

> Your supposition that only commercial muds can advance the state of
> the art is flawed. Commercial muds have to be popular. Popular does
> not neccessarily imply good. It could even be argued that players of
> commercial muds don't *want* their mud to change in any highly
> perceptible way. Free muds, on the other hand, can get by on no
> players at all, if need be. They can concentrate on making muds
> better. Players are important, but their needs do not have to
> influence the direction of the game's growth. On a commercial mud,
> there is no choice. If players leave, the game (and the business,
> more importantly) is dead.

> Your implication that free muds will soon be dead is not one that I
> can support. I can only assume that you place zero importance and
> value upon free muds - or that you consider muds that aren't
> massively multiplayer games to be stagnant and nowhere near the
> direction that 'real' muds are heading. I happen to think that free
> muds have the potential to be much more ambitious, and much sooner,
> than commercial muds. (That potential is rarely realised,
> unfortunately.) This is mainly because their "success" does not have
> to be defined in terms of the number of players that they can
> attract.

I believe you read too much into my message, or I did not quote enough
of the previous message.  I did not intend to imply that free MUDs are
dead.  In fact, I believe that many of the free MUDs out there today
are superior to the commercial MUDs on the market.  If you follow the
thread back to the beginning, you will see that there was an
assumption in the original post, that we were discussing large
servers.  My definition of large servers is a MUD that can support
more than 1000 - 2000 players online at one time. From the original
author's assumptions, I made my point.

Bruce: Enterprise level software is simply a term meaning 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.  When I think of enterprise level
software, I think of operating systems, DB servers, mail servers and
web servers.  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.  How
about the ability to use decision support tools to better analyze
things like class balance and object hierarchies.  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.  These servers would take advantage of today's
technology and use it in a fashion that would allow administrators
better control over the entire world simulation.

Derek


_______________________________________________
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