[DGD] just out of curiosity

Wed Sep 12 19:01:38 CEST 2012

I think many people would say that most LPMUDs "felt" the same, at least in some
basic ways, so having a common art base may not be so bad a problem. As long
as the developers have flexibility in creating the content, differences in what they
create should produce sufficient distinction between them. After all, if we live in
the game world a bit longer, a sword is a sword is a sword. It's the social mileau
that the designers create in which the sword can be used that makes one MUD
feel different from another (or not different). A common library of art images,
as long as it's reasonably large, shouldn't prevent that from happening.

Steve
________________________________________
From: dgd-bounces at dworkin.nl [dgd-bounces at dworkin.nl] on behalf of Noah Gibbs [noah_gibbs at yahoo.com]
Sent: Wednesday, September 12, 2012 12:53 PM
To: All about DGD and Hydra
Subject: Re: [DGD] just out of curiosity

The problem with art and a pre-existing library is that artistic style defines a lot of the "feel" of a given product.  If there was a template library like that, all the resulting games would "feel" the same.  The code problem is alleviated somewhat by the fact that programmers like MUDs and often start MUDs...  Plus, honestly, the amount of code to "reskin" a MUD is much smaller than the amount of work to reskin all the base 2D artwork.

I don't think you'll find that the art problem goes away.  And 3D is much, much worse that way.

________________________________
 From: Ragnar Lonn <prl at gatorhole.se>
To: dgd at dworkin.nl
Sent: Wednesday, September 12, 2012 1:00 AM
Subject: Re: [DGD] just out of curiosity

Yeah, art is definitely a bottleneck sector. But I think it can be
solved through templating - you create an art library with common
textures, and a model library with common 3D models. Then it becomes a
lot easier for an average person to create, say, a kitchen table.

In the end, the model library will not only contain kitchen tables, but
parts of kitchen tables (surface, legs), allowing non-artists to create
unique items that look good by just adding together different
pre-existing pieces.

Regarding copryright, code is as much an intellectual property as art,
and MUDs have managed to handle the code issue. Every serious
community-created initiative out there forces its users to relinquish
(or share) copyright on stuff they create inside the community.

   /Ragnar

On 09/11/2012 11:45 PM, Noah Gibbs wrote:
> 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
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd

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