[DGD] just out of curiosity

Tue Sep 11 23:45:02 CEST 2012

Very true.  One thing that promises to change that: art assets.

Their copyrights tend to stay with the artists, not the MUD.  The artist would need to grant copyright to the MUD.  You also need an artist for *new* art, and you usually need multiple.

So splitting the MUD gets hard because there aren't good art assets, and you have to take the artists with you to get new ones.

Possible, of course.  But much harder.

And the resulting fission would be less likely to produce two new MUDs, and much more likely to produce one or zero.  Zero would be if the mutiny takes away enough of the staff/artists to kill the original MUD, but not enough to keep the new one afloat.

The march of production values hasn't been kind to MUDs.  2D art makes the problem a bit worse and 3D art makes the problem unmanageably bad.  There just aren't enough artists, and that's not likely to change.

________________________________
 From: "Schmidt, Stephen" <schmidsj at union.edu>
To: All about DGD and Hydra <dgd at dworkin.nl> 
Sent: Tuesday, September 11, 2012 2:21 PM
Subject: Re: [DGD] just out of curiosity

I will beg Dworkin's indulgence for one more post, then move on.

One reason LPMUDs never got terribly big was because they tended to fission
if they got large. Once there was a reasonably-sized wizard group, someone
who wasn't a top administrator would develop a desire to be one, and since
it wasn't too hard to open your own MUD, sooner or later someone would.
A few other wizards would go along, and poof, two MUDs where there used
to be just one.

This is probably an inevitable phenomenon in any setup where people can
easily create their own new communities with themselves at the top of the
new hierarchy.

Steve

________________________________________
From: dgd-bounces at dworkin.nl [dgd-bounces at dworkin.nl] on behalf of Ragnar Lonn [prl at gatorhole.se]
Sent: Tuesday, September 11, 2012 2:00 PM
To: dgd at dworkin.nl
Subject: Re: [DGD] just out of curiosity

This is an interesting discussion also, although I don't know if Felix
will kick us off the list if we start discussing communities :-)

I think the reason LPMUDs rarely went over a few hundred users were that
the market was so small, not that there was an inherent limit in the
size a creative community could have. Wikipedia is an example of a
pretty sizeable creative community that is also incredibly productive.
Actually, Second life is an example of a 3D virtual world creative
community that consists of in the order tens of thousands of contributors.

Communities in general get more valuable the more members they have.
There are always organizational challenges when a community grows, but
nothing that can't be addressed I think.

   /Ragnar

On 09/11/2012 07:02 PM, Schmidt, Stephen wrote:
> I have a sense that there's a conflict between this vision of a large
> distributed system, and the vision of community-based creation, as
> Ragner mentioned earlier. Effective communities don't scale well,
> which is why LPMuds (my experience anyway) rarely went much
> over a few hundred regular users, usually less. Also, communities
> have to get started, so it has to be relatively easy for someone to
> open a new site out of the box. People who can set up and run a
> large distributed system are few and far between. If it's easy enough
> to open a site that lots of people can do it, then you're going to have
> a lot of sites to choose from and few of them will need more computing
> power than a single machine can provide.
>
> There was an attempt in the Olde Days to split the difference, and have
> a lot of small locally-run sites that were interconnected in various ways.
> But if you wanted the interconnection to be more meaningful than
> being able to text-message someone on another mud, then you have
> to ensure some basic compatibilities between the systems, and that's
> not consistent with each community developing in its own direction.
> Let alone the problems of maintaining partitioning when each site is
> being independently run.
>
> To some extent, I think we might be better off trying to get to a system
> where it wouldn't take too much skill to open a simple site, and work on
> having lots of small sites with close-knit groups developing in their own
> ways. I see that as more attractive than going the MMP route where it's
> harder for any one individual to influence the development of the
> community much.
>
> Steve
>
> ________________________________________
> From: dgd-bounces at dworkin.nl [dgd-bounces at dworkin.nl] on behalf of Ragnar Lonn [prl at gatorhole.se]
> Sent: Tuesday, September 11, 2012 10:11 AM
> To: dgd at dworkin.nl
> Subject: Re: [DGD] just out of curiosity
>
> On 09/11/2012 03:32 PM, Felix A. Croes wrote:
>> Ragnar Lonn <prl at gatorhole.se> wrote:
>>
>>> [...]
>>> The problem with DGD/Hydra, for this particular application, is that it
>>> is not meant to be run in a distributed environment. Any system that is
>>> not distributed will not have enough CPU cycles for anything but a small
>>> world with few players. You can get away with some sharding maybe, or
>>> transferring objects between different state machines, but it will be
>>> messy.
>> This isn't true anymore, DGD & Hydra now explicitly support outbound
>> connections.  The problem of efficiently distributed servers is still
>> unsolved, but DGD/Hydra can be part of the solution.
> I guess the overall question is: is DGD/Hydra a good starting point for
> building a massively scalable, distributed state machine, or would it be
> easier to start with something else, or completely from scratch?
>
> When you mention outbound connections, I guess you mean that state
> distribution should be done in LPC. Would that be fast enough?
>
> I want:
>
> 1. huge scalability. Up to hundreds of thousands of physical nodes where
> each node supports hundreds of thousands of objects
> 2. a seamless world, where interaction between objects is always
> reasonably fast from a user's point of view
> 3. reliability. A failed physical node will not cause service
> interruptions (multiple-copy state redundancy). Multiple concurrent
> failures can at most cause temporary interruptions (physical media state
> backups/snapshots). Loss of data can happen, but is kept to a minimum
> and consistency is not compromised.
>
>     /Ragnar
>
>
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd

___________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd
___________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd