[DGD] just out of curiosity

[Ragnar Lonn]

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

Also, you will probably want to set up dedicated servers for serving 
static content such as models and textures. They could be web (HTTP) 
servers like Varnish or Squid. Then you'd have the state machines (DGD) 
to compute position, and velocity vectors for all objects and send that 
to the clients in real time.

An interesting note about web browser caches btw: all modern browsers 
have max cache size settings that are quite small by default - maybe 50 
MB or so - and that means you will get a lot of cache misses because 
data is getting purged from the cache prematurely all the time. 
Hopefully, the browser vendors will fix this in time. They just haven't 
adapted to the amount of disk computers have today.

   /Ragnar



On 09/12/2012 07:06 AM, Noah Gibbs wrote:
> Stephen,
>
> Yes, both of those approaches can work well.  There's also a third 
> good option where you send references to objects and never reuse a 
> reference name.  If the client doesn't already know what the reference 
> means it sends a request that says "here is your reference back, 
> please give me the image to which it refers."
>
> The most common implementation of this pattern is a web browser, where 
> the references are URLs.  But your game can do exactly the same thing, 
> including various caching patterns similar to a web browser.
>
> If you build a game *in* a web browser and rely on the browser for 
> caching you get this pattern for free.  That's not the only way to do 
> it, of course.
>
>
> ________________________________
>   From: "Schmidt, Stephen" <schmidsj at union.edu>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Sent: Tuesday, September 11, 2012 9:54 PM
> Subject: Re: [DGD] just out of curiosity
>   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
>
>
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd