[DGD] just out of curiosity

[Jared Maddox]

I don't check mail for a day, and 8 digests. Wow.


> Date: Mon, 10 Sep 2012 14:17:22 -0700
> From: Shentino <shentino at gmail.com>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID:
> 	<CAGDaZ_q_QVEM+mZeM_SNE3pLKhGuvPO2hmrPMHfYhY8d8nNmgA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Indeed.  Rendering should be a client side issue.  The server, after
> all, can't exactly touch the client's GPU directly.
>
> Though I did recently learn of this thing called virtual gl or
> something that makes opengl run over a network connection.
>

Sounds like an OpenGL version of an X session that crosses a network.
I personally would classify that as something that should only be used
by the client to control the display, not something for the server to
use.


> Date: Tue, 11 Sep 2012 17:02:39 +0000
> From: "Schmidt, Stephen" <schmidsj at union.edu>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID: <BEACBB441183C7499BC63182DF11406B957E7863 at mbx2.union.edu>
> Content-Type: text/plain; charset="us-ascii"
>

> 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
>

> Date: Tue, 11 Sep 2012 21:21:28 +0000
> From: "Schmidt, Stephen" <schmidsj at union.edu>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID: <BEACBB441183C7499BC63182DF11406B957E796C at mbx2.union.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> 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
>

> Date: Tue, 11 Sep 2012 14:45:02 -0700 (PDT)
> From: Noah Gibbs <noah_gibbs at yahoo.com>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID:
> 	<1347399902.73410.YahooMailNeo at web39402.mail.mud.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> 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.
>

I think that a well-implemented version of the 'innterconnected sites'
system could actually compensate for the fission/art problem. You'd
need a system where one site's resources could be used on another
within the greater system (probably divide things into 'world',
'entity/logon', and 'object' categories, with the world being the site
setting, entities being players registered there (and capable of
travelling to other sites), and objects being things that the site
hosts). You'd ALSO need a way for entities and objects to detect WHAT,
exactly, the world that they're in supports. Finally, you'd need
'security' features, such as a way for an entity to teleport back to
it's host site without any other authorization, and some sort of trade
mechanism to allow but secure giving away objects. You'd probably also
want a 'system' host, to oversee the association of sites.

The system host would presumably place user license requirements on
all sites connecting to it, so that e.g. rights holders uploading
their own content couldn't pull it if someone else was validly using
it, and uploading content without authority could be enough for a site
to be kicked from the rest of the system, unless the site fixed it.

With a framework like that, you could have site fissions that (if it
was amicable) would allow the new site access to the resources of the
old site, and vice-versa (useful for development, personal
'workshops', different settings, etc.). By having worlds support
feature sets (with a minimalist feature set presumably standard) you
can have different worlds that support different things, but are still
mostly compatible (really, should you be able to use your Iron Sword
in Bob's Ethereal Plane?). You could even use this to divide different
areas of a single site into 'chunks', such as wilderness where combat
is pvp free-for-all, and markets where you can't even kill a goose.

Also: useful for prototyping new features.


> Date: Tue, 11 Sep 2012 17:02:39 +0000
> From: "Schmidt, Stephen" <schmidsj at union.edu>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID: <BEACBB441183C7499BC63182DF11406B957E7863 at mbx2.union.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>

> Steve
>

With the setup I outlined above, and an easy enough interface, you
could even have artists setup their own site.


> Date: Wed, 12 Sep 2012 04:54:29 +0000
> From: "Schmidt, Stephen" <schmidsj at union.edu>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID: <BEACBB441183C7499BC63182DF11406B957E7CB9 at mbx2.union.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> This is a question possibly out of ignorance, I am not a serious computer
> person, only an amateur. But it is a question relevant to using DGD for a
> practical task (not necessarily a game, either) so I hope it's moving back
> towards the theme of this list.
>
> Generally speaking, in a MUD environment you'll have players, you'll have
> objects, and you'll have "rooms" that contain those players and objects.
> Your users need to get some kind of information about all three of those
> things.
>
> In a text-based game, you basically have long and short descriptions for
> each of these three types of things. The long description of a room
> includes the short description of the players and objects in it, and a
> player's long description includes the list of the objects s/he's
> carrying. All of these things are text strings, and can easily be stored
> or generated on the server and sent to the client as text without causing
> any bandwidth issues. Character data is easy to send around. Also, it's
> easy for a wizard (meaning: someone who can create new game objects, but
> not necessarily an admin) to invent new objects and type in short and
> long descriptions for them.
>
> In a graphical game, you need images for these things as well. I would
> imagine that bandwidth issues are going to prevent sending image files to
> a client each time a user accesses an object, particularly if the image
> for a room needs to somehow include the images of the players and objects
> in it, and the image of a player needs to somehow include the objects
> s/he is carrying (or wearing or what have you, which are basically forms
> of carrying).
>
> I think there's two other options. One is to have a library of images stored
> in the client software, and have the wizard pick images from that library
> for the objects s/he creates. This'll be a problem if the wizard wants to
> create an object which doesn't match any of the existing images. It might
> be necessary for wizards to be able to add new images to a library that
> resides on the server, and one task performed at login is to have the client
> update its image library to match what's now on the server.
>
> Another one is to come up with a simple set of instructions for rendering
> images, probably by being able to instruct the client to draw various
> polygons and round shapes in various colors and positions, and building up
> the images you want out of the individual shapes. This lets you send
> instructions for creating that image to the client without using too much
> more bandwidth than a text description would take, but it limits you to
> images that look like combinations of polygons, which may not be pleasing.
>
> One could do both; have a standard library of "nice" images and the ability
> to use a set of rendering instructions to create additional, crude images
> when the library doesn't have anything appropriate.
>
> Anyone given more thought to this problem than I have? Obviously people who
> have coded graphical MUDs in the past have done. Is there some kind of
> standard approach to solving this problem?
>
> Steve

For graphical systems, I think the 'combo' option, though done
slightly differently, is correct (I'm assuming 3d here). Have a mesh
(or several) for the shape of the item, and apply pieces of images to
the individual parts of the mesh. If you want to get fancy, then allow
some scripting, so that your Staff Of Power can have gems orbiting
around it.

Bear in mind that Noah's "reference name" alternative can also be
applied to this: the combination of meshes, images, and scripts is
just as valid of a target for a reference as anything else.



> Date: Wed, 12 Sep 2012 10:29:24 +0200
> From: Ragnar Lonn <prl at gatorhole.se>
> To: dgd at dworkin.nl
> Subject: Re: [DGD] just out of curiosity
> Message-ID: <505047E4.7050306 at gatorhole.se>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I can add that Second life uses the "send polygon drawing instructions"
> variant (unless they've changed it recently). They stream rendering data
> to clients on a low level, polygons and textures. Textures are cached on
> the client, I think. Unfortunately, it is a little bit too slow, and
> causes delays in rendering (in a scene with many objects, there is
> simply too much data to send. Especially if some objects are moving).
>
> I think the best way to do it is to cache textures and complex 3D models
> on the client side, and use references, like you describe. Ideally, the
> client gets a set of standard models and textures when installing a
> client software. New textures and models are then dynamically added to
> that set, when needed. And it's very important that the system is smart
> and can figure out that a client *is going* to need a certain model or
> texture soon, so it can send it to the client before it is actually
> needed (pre-loading).

>
>    /Ragnar

It's enough for the client to figure it out in time to request it,
though doing it in the server is certainly better. Also, you can
potentially use this to swap in and out different resolutions.


> Date: Wed, 12 Sep 2012 12:48:00 +0100
> From: RobF <squaretriangle at hotmail.co.uk>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID: <BLU0-SMTP1599D85A8C1F9205E3C75AD9D920 at phx.gbl>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> On 12/09/2012 05:54, Schmidt, Stephen wrote:
>>

<snip>

>>
> The room/shortdesc/longdesc paradigm could be evolved to something that
> has greater commensurability with a graphical counterpart--i.e.
> maintaining a spatial 3D universe for objects and 'rendering' rooms in
> text based on dilating perception off of a certain point (i.e. what gets
> included in the 'long description' and what goes 'out of focus' and
> filed away into the short descs of the room is determined by how dilated
> ones perception is (and sometimes it would be conception--i.e. to the
> point of getting the equivilent of a 1-room town like you may have ran
> afoul of in traditional MUDs--something you couldn't rightly perceive
> unless you were a giant standing over the whole thing--an impression
> that said rooms have unintentionally lent).
>

You could also incorporate some player stat features into it, such as
better perception resulting in either more detail, or more things
mentioned.


> Date: Wed, 12 Sep 2012 12:48:00 +0100
> From: RobF <squaretriangle at hotmail.co.uk>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID: <BLU0-SMTP1599D85A8C1F9205E3C75AD9D920 at phx.gbl>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> On 12/09/2012 05:54, Schmidt, Stephen wrote:
>>

<snip>

>>

> As to the rest of what you said, I think it's best to conceive the
> answers you've suggested as second-best solutions to a problem--in an
> ideal world where efficiency is no object we'd never off-load content to
> the client, and the client would be responsible solely for presenting
> it.  The real answer may be the least satisfying: wait for the HW to
> improve.
>

How do you define content? You can just as easily define content as a
selection of abstract numbers, and the texture/image data as nothing
more than a trivial presentation method.

Also, "wait for the hardware" isn't always (or I'd say ever) a good
technique ;p .


> Date: Wed, 12 Sep 2012 12:48:00 +0100
> From: RobF <squaretriangle at hotmail.co.uk>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] just out of curiosity
> Message-ID: <BLU0-SMTP1599D85A8C1F9205E3C75AD9D920 at phx.gbl>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>

> As I said before I believe text MUDs have a future -- with over a
> billion people connected to the internet, I see no reason we have to
> enjoy player-bases of a mere 1-100 people on our text MUDs (and still on
> the decline).  I see no reason this couldn't be a hundredfold of what it
> is.  It's just that nobody has had the belief and saw what had to be
> done to stay appealing and relevent and keep it going (plus
> oversaturation hasn't helped).
>
> And as someone who believes that, I think separating content from
> presentation is definitely a mandatory step for text MUDs to take, it's
> not just something that graphical MUDs _have_ to do, they should also
> want to do it.  I haven't educated myself on whether there actually are
> any strictly non-graphical MUDs that have already done this?
>

To be a vibrant ecology, text MUDs would need to target the mobile
economy (remember, that's where the real growth is), which certainly
could be a possibility (I understand that there are some recent
commercial text adventures that have been successful on smart phones).
Single-player support (especially for puzzles & wizards) might be a
good addition, too.