[DGD] just out of curiosity

[Schmidt, Stephen]

If we're talking about MUDs that connect to their users via a telnet protocol,
which is what they always were back in the 1990s in my experience at least,
then I'm not sure that there's any point in sending "data" to a telnet client;
a telnet client doesn't process data in any way except to print strings of
characters to a screen in a line-by-line way. All that client can do is present;
it has no use for data.

If we're talking about creating our own client, then I think distinguishing
between data and presentation makes a lot of sense - the client's CPU
can do the presentation based on the data it gets sent, but if you need
to escape from the client's pre-existing abilities, then you may need to
send presentation directly.

However, if you're going to go to the trouble of creating your own client
software, then I would think that it would always make sense to have a
graphical capability built into that client.

If we're talking about using a pre-existing client that isn't telnet, such as
a web browser, then I think the distinction is there; the html file is "data"
and the browser displays it according to the browser settings.

Steve

________________________________________
From: dgd-bounces at dworkin.nl [dgd-bounces at dworkin.nl] on behalf of RobF [squaretriangle at hotmail.co.uk]
Sent: Wednesday, September 12, 2012 7:48 AM
To: All about DGD and Hydra
Subject: Re: [DGD] just out of curiosity

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?
___________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd