Re: A few thoughts on client/server

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

Tero Haatanen <Tero.Haatanen@lut.fi>:
> About doing animation in client is partical solution only. Most alive
> objects moves around so animating those in client side don't help, 

> since you have update them anyway. So objects which can be animated
> on client side are backgrounds (currently 3) and normal objects (e.g.
> diamonds and so, currently about 50). If client animates these,  it
> helps server side. Note that alive object's animation can have  a
> real meaning, like different animation of wizard, when he concentrate
> to cast a spell, director turning around and so on. So maybe there 

> should be two types animations on server side, first done by client 

> and second done be server.

Absolutely.  If an animation actually means something, it has to be  
done on the server side.  When I said animations I was thinking  
exclusively of aesthetic repeating patterns (like waves, or fire, or  
darkblade).  Those I believe are both much more frequent and happen  
much faster.  All of that is handled with relative ease by the proposed  
protocol.  The only case which is really worrisome are spikes because  
they both have meaning _and_ they are constantly and quickly repeating.   
A couple of spikes could really load a slow connection.

> One point about Carl Edman's protocol is that it makes difference 

> between backgrounds and objects and that doesn't make sense. Does
> that mean that background objects don't have same properties that
> other objects? And what are these terrrains? Floors? Floors and
> walls?  If walls does it count weak walls? And so on. I think it's
> not worth it.

Yes, MAPs lack one extremely important property which ITEMs have --  
they can't move.  Also in most places they are considerably more  
plentiful.  Over time I've come to the conclusion that this is a real  
fundamental distinction and so I think have the designers of crossfire.   
However, if you don't agree just view the distinction as a performance  
optimization.  As things are now, MAPs don't need a name, a quantity or  
a tag and you can have any number in one single command.  That will  
probably give you real performance increases.

> And there isn't anywhere seen requirements how long client have to
> keep items in the memory. Does UNMAP mean that client can delete this
> square totally and server sends it again or does client have to keep
> all places in memory where player is visited or so only to next CLEAR
> command? 


The proposed protocol says:
"MAP <locx1> <locy1> <image1> <locx2> <locy2> <image2> ...
Using one of these commands the server may tell the client that it sees  
the map at a series of location given by coordinate pairs.  The name  
refers to the image to use for the particular map location.  If the  
client doesn't know that particular name, it asks the server for it  
(see REQUEST/TRANSMIT).

UNMAP <locx1> <locy1> <locx2> <locy2> ...
This command tells the client that a certain series locations isn't any  
longer in the LOS of the player.  The client may respond to this by  
erasing the squares in question, shading them to indicate to the user  
that they aren't any longer directly visible or just by doing nothing."

I take that to mean that a client may do whatever it wants when it  
receives an UNMAP statement.  It may delete all memory of the square in  
question as the server is going to send it again when it enters the LOS  
again in any case or it may keep it around as a sort of automatic map  
drawing for the player.


> Note that client really shouldn't been aware  which physical
> map player is, although it probably knows it. Think something like
> current world maps, client don't need to know which physical map is
> in question.

I agree.  However, that is a crossfire server decision and I'm in too  
many discussion in this group right now in any case to want to open up  
another can of worms.

> One thing which makes hard to send just updates in visible items is 

> that server has to remember all things what it has been send to every
> player in the game. With 10 players and big map this is quite much of
> memory to keep tracked.

Not really.   The server (as I would write it though that really is  
protocol independent) just keeps a set of all the squares which are in  
the LOS of each player.  That should be less than 1k.  As an item  
enters or leaves a square in that set, the server generates an ITEM  
command.  As the set changes, all items in squares which enter the set  
are sent to the client (no need to worry about items in squares which  
leave the set -- the client is assumed to understand that items in  
UNMAPed squares are no longer visible).  Even chosing an implementation  
which sacrifices compactness for speed (as one probably should) that  
will be less than 1kByte/player.

> I prefer Kjetil's idea that client tells how  many stacked objects
> client wants and server send images without names. Since how many
> times players click on walls to see their names?

Walls are MAPs and don't have names.  Only ITEMs have names.

> If player wants to look at a specific square it sends command to
> server ("look x y"). Server sends back a string (and maybe pixmaps)
> what player see there.

To paraphrase myself: Latency is evil.  Latency for just _looking_ at  
things (rather than doing something) is doubly so.  


> So server can implement feature that player don't see all items if
> looking from too far.

If that is what you want (and it certainly sounds like a good idea),  
then just don't send ITEM commands for faraway small items.

> I think it's also good assume that player is always in the centre of
> view (currently 11x11). Maps are designed that way, so no need of
> changing that. This view can be probably get up to 15x15, but bigger
> that change the game too much. All maps are designed only for small
> views.

Maps are designed for a certain LOS.  That is a server side decision.   
How big a view the client choses to give player is none of the business  
of the server.

> One solution to send updates for map is that when player first time
> enters to the new map, whole 11x11 (or 13x13, 15x15) area is send
> player. With binary packet it makes 11 * 11 * 2 = 242 bytes
> per/graphics level. Next time when view is changed server checks if
> how much that byte array  is changed. If it changed only little then
> update packet can be send. If player moves, that array is shifted in
> same direction that player moves. It would be very easy to server
> remember what is send to  each player since you need keep only latest
> update, not whole map. Update packet use 3 bytes per location per
> graphics level, so it don't even use much bandwidth.

Clearly, we are talking about two entirely different kinds of client  
here.  You are talking about a glorified VT100 which can draw graphics  
and play sounds but has no more brains or understanding of the world it  
is in than the dumbest of terminals.  That is what we had until now in  
X which is probably the reason so many think in terms of a *graphics*  
protocol.  There are probably some gains to be made in this area, but  
let me tell you that the people who designed X were not stupid.  If you  
want to play their game and beat them at it you either have to work  
very very hard or imposes enormous restrictions.  This is frankly  
something which I personally don't have the slightest bit of interest  
in investing my own time in writing and maintaining.

What I'm thinking of is a *simulation* protocol (for lack of a better  
term).  A protocol which doesn't consist out of instruction to draw FOO  
at BAR now but rather one which *describes* a world without any  
immediate consideration of graphical representation.  Graphical  
representation (or the lack thereof) is a client matter.  A protocol  
which actually allows the receiver to make rational decision about the  
simulated world and gain understanding about it.

	Carl Edman