Re: images and maps

["Carl Edman" <cedman@cedman.remote.Princeton.EDU>]

From: Philip Brown <philb@soda.berkeley.edu>
> >>>>[From Carl Edman]
>     

>     > - when the client connects to a server, the server sends all
>     > filenames (images and sounds) to the client, along with their
>     > id numbers.  Then, each time a sound or image has to be used,
>     > its id number (2 or 4 bytes) is sent instead of its name.
>     

>     That is a false economy.  On the systems on which bandwidth
>     _really_   matters i.e. SLIP or 57.6 kBps fixed line systems you
>     are trading   adding several minutes to the startup time for
>     being able to shave off   some unnoticeable 2 or 3 bytes off a
>     reference to a new image or sound. The user visible performance
>     gain for that is completely below the   threshold of noticability
>     (and may even be a loss as I explained in the   article about the
>     efficiency of ASCII vs. binary I posted yesterday).
> 

> I don't get how you can justify this, or maybe I'm misunderstanding
> what you're saying.
> 

> Counter-situation: Server/client uses the method of loading
> images/whatever on demand, instead of at startup.
> 

> player walks into a new map area, with 20 different monsters he's
> never seen before.
> 

> His connection gets flooded with loading new information.
> 

> Meanwhile, the monsters trash the player.
> 

> We COULD make it so when you enter a map, you are "invulnerable", but
> I think that's an unclean thing to do.

Ah, yes, this is a real problem.  I only have a few partial answers to  
it.

First of all, note that I insisted on two independent channels in the  
protocol (for this very reason, among others).  Even if the  
server->client connection is clogged up with large image transfers, the  
client->server connection is not affected.  That means that you _never_  
"freeze".  So you'll always be able to run away in this case, even if  
it may take a little while for the graphics you see on the screen to  
catch up with your flight.

Then, it is also a matter of map design.  Already I believe it is  
considered quite bad form to place aggressive and dangerous monsters  
right next to a map entrance because it tends to lead to fatalities  
even now.  Also _I_'ve never seen more than two or three new monsters  
I've never seen before at one time and even that only very very rarely.   
So this problem may not be as signficant as you think.

> Anything that requires , or
> COULD require, mass loading of data , should be done one time only,
> at startup time. (and then never again, until the server gets
> updated)

But servers are going to be run by us hackers -- there are going to be  
almost continuous updates.  This scheme will transmit many times more  
images than most players will ever see, more times than any player  
needs to have them transferred (once) and then compounds its sin by  
doing the transfer in the way most painful for players by resulting in  
long pauses rather than tiny unnoticeable delays during play.

>     Of course this proposal also gives away a list of all images and
>     sounds   to the user -- arguably not as bad a problem of cheating
>     as sending the   entire map to the client, but nevertheless.
> 

> Are you referring to crossfire displaying all the images onscreen,
> when starting in "pixmap" mode? it doesn't HAVE to show them, you
> know.

Ah, but I thought that there was something of a consensus now that we  
can not assume control over the clients and that telling something to  
the client is morally equivalent to tell it to the user.  That was the  
main argument for server-side LOS.

> BTW: as far as sending screen updates across, I quite like the
> 

> VIEW x y {imageface imageface ... <space>} [x y {imageface ...}]
> 

> idea. This would actually allow some notion of client map caching.
> For example, moving "up" one square, on a quiet map would only
> require the server sending the new row.

Well, that is just the MAP command with the optimization that when two  
words follow each other the location of the second is assumed to be one  
to the left/right of the first one.  I'd be perfectly happy to make  
that change to MAP, though frankly it doesn't buy you very much if you  
move left or right (which you'll do at least half the time) or when  
revealed areas (because of LOS) are not lines.

> Even if there are monsters, server is only required to send new top
> row, plus whatever monter has moved.

Monsters are items, not map and are transmitted with a different  
command (which also automatically erases the last image of the monster  
or other item).  Even if a monster is in some field, a client will  
still want to know what the terrain is.

> Given the arguments about auto-compression, and relative sizing, I
> think I will concur that having "imageface" as an ascii value is
> acceptable.

Ah, I'm glad to hear that !

	Carl Edman