[DGD] just out of curiosity

[Shentino]

One other thing I was hoping to do with Kotaka was allow megascalediff.

Able to have a town simulated/emulated down to the meter, at least

...but still be able to have moons orbiting planets, planets orbiting
suns, and suns orbiting black holes.

Probably have a dedicated server to handle a planet...possibly with
"lieutenant" servers to handle continents.

This goes back to my ealier thread about r-trees.

Basically a server running "earth" would handle the entire earth...and
possibly also supervise sub-servers below it that handle
continents...plus pay attention to its superior server "sol" which is
itself busy supervising the solar system.

Meanwhile, the earth server would be supervising the lunar server, and
also handling trnasit between the planet and the moon.

If anything interesting happened on a continent, such as a rocket
launch, the continetn server would pass the rocket objecdt up to the
earth server.

Meanwhile, the sol server would notify the earth server if something,
say, like an asteroid, got close enough to earth that earth would care
about it.



On Tue, Sep 11, 2012 at 2:21 PM, Schmidt, Stephen <schmidsj at union.edu> wrote:
> 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