[DGD] just out of curiosity

[Noah Gibbs]

It's true that browsers run with too little cache.  Although old experiments with 3D worlds suggested that keeping as little as 1% of the textures in an LRU cache could give you up to 50% of the benefit in cache-hit terms.

So that's not as awful as it sounds.  Cache sizes *should* be turned up, but we're probably getting 50-80% of the benefit even with a cache that's way too small.  Doesn't help initial site load time, of course.


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

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