[DGD] just out of curiosity

[Ragnar Lonn]

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