[DGD] just out of curiosity

[RobF]

On 12/09/2012 05:54, Schmidt, Stephen wrote:
> 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?
>
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).

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.

I think as far as text MUDs go that they could have separated content 
from presentation more than they had done in practice, but that's an 
evolutionary step I guess they never 'lived' long enough to take...?  Or 
maybe it was just so easy to send data and presentation as one that it 
never occured to them to separate concerns as there wasn't the extra 
incentive to do so, and they didn't see it's potential at the time as 
people were still too happy to connect over telnet?

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?