Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol

["Carl Edman" <>]

From: Kjetil Torgrim Homme <>
> >--- Carl Edman:
> > A player with the coordinate system the other way around would see
> > a mirror image of the world but everything would work just for him
> > as well.
> 

> The big shops are constructed as
>   AB   Our "backwards" friend would see   CD
>   CD                                      AB
> Result - jumbled graphics. Direction of axes needs to be defined.

Maybe I'm a little slow today.  A player with axes reversed will either  
see a mirror image world or a world rotated by 180 degrees.  But such a  
world makes perfect internal sense.  It is just as if all the maps on  
the server had been rotated around.  They'd still work just fine.   
Until the player actually talks with other players and happens to  
mention e.g. that the guild is north of the armour shop, he'd probably  
never even notice that anything is wrong (nor would the server).

Nevertheless of course we _should_ define the axis directions, so that  
players can switch clients with a minimum of confusion and players with  
different clients can communicate more easily.

> > [...] animation information is part of the image information and is
> > handled 100% on the client side.  The server nevers sends a command
> > to animate something.  The ITEM information is about items, not
> > pixmaps.
> 

> Well, then you should define more clearly what you mean by image
> information and how you are going to handle synchronization. For many
> objects, it is vital that the right frame of the animation is shown
> at the right time (e.g. spikes). I think the best way may be to add a
> <frame> argument to the ITEM packet. 


Ah, yes, I hadn't thought of spikes.  I guess that means that both  
clients and servers will have to have good clocks and we need some  
clock synchronization at connection.  It seems a lot of work for just  
the spikes, but we have to do it...

> > The client is only _required_ to keep the information on the couple
> > dozen squares which are in current view (though good clients will
> > want to keep more around as a form of automatic map drawing).
> 

> If the server only can assume that the objects in the current
> viewport is known, it will have to send the information when the
> viewport changes. If the "good" client keeps more information, it
> will be of practically no use.

But not at all.  A client which keeps at least the MAP information also  
from squares which have been UNMAPed would work as an automatic mapper  
which is judging from its popularity in many commercial game a very  
desireable feature to many players.

> A little arithmetic: For every object, the client will need tag,
> animation pointer, name pointer, X and Y coordinates -- roughly 16
> bytes. I just went into "Andreas living apartment", the largest and
> most computing intensive map I know of, and Crossfire reports 7571
> objects. That's 128kB. All in all, I think a client can keep all its
> state for a map in under a megabyte.

That really does sound like quite a lot.  But even a client which keeps  
old mapping information is allowed to throw it away if there is a real   
memory crunch.  When an object enters the viewport again, the server  
will send the MAP and ITEM information again in any case.

> Okay, onto my goofups. I repeatedly said "stateless client". I
> actually meant "stateless server" - a server which doesn't need to
> know what information the client has. In the strictest sense, this is
> unusable. According to Carl, the server assumes the client knows
> everything about the objects visible. The state for each client in
> the server is then small - basically a pair of coordinates.

A stateless server is something I'd like to see as well.  However I  
suspect that in the interest of server CPU efficiency (and without any  
impact on the protocol) the server will want to keep a list (or some  
other structure) of all the squares which are in the LOS of the player.   
The client will probably want to do the same (well, for it is just the  
list of all coordinates for which it has received a MAP but not yet an  
UNMAP).

> Let's say the client keeps all map info, which should be possible for
> even low-end PC's and Mac's (4 MB is minimum configuration these
> days, and they have at least that amount in virtual memory). The
> server keeps a bit in every object for each client saying whether
> it's up-to-date. If the object moves or its name changes, the flag
> word(s) are set to 0. When the object comes into view for a client,
> the flag is consulted, and if it not set, an ITEM message is sent.
> 

> If there are no moving objects on the map, the only thing on the wire
> is one MOVE and one ITEM every time the player moves.

Here I disagree.  What you are proposing is just a variation of the  
client-side LOS scheme with all (or at least most) the attendant  
problems.  I thought that of clients which keep UNMAPed squares for  
automatic map drawing and other convenience, but never really rely on  
it.

> >---
> > I don't think we should negotiate colors.  Colors are up to the
> > client side.  Please try not to think purely in terms of current X
> > hardware -- there are machines with one million and one different
> > kinds of color hardware.  And in every case the client knows far
> > better how to make use of it than the server will.  The server
> > gives the client full information and the client makes use of it as
> > best it can without any server interference.
> 

> First, I am _not_ "purely thinking in terms of current X hardware" -
> why make such accusations?  Always, always, always leave room for
> future expansion in the protocol. As your protocol stands, the server
> can send data of unknown types to the client, but the client has no
> way of telling the server that it doesn't understand them.

No side _ever_ sends binary data without the other side requesting it  
first.  And the REQUEST command contains a TYPE field which allows the  
client to specify what kind of data it wants.

> If you want to give the client full information, the only alternative
> is the XPM-format. One colourful XPM-file uses ~900 bytes, gzip can
> reduce that ~300. Compare this to sending the raw colour data (a
> palette with 32 colours is preset): 24*24*5/8 = 360 bytes
> (uncompressed, but still... and I set out to prove the superiority of
> raw data :-)
> 

> In any case, a raw monochrome image is just 72 bytes. 300 bytes takes
> one sixth of a second to transmit with a 14.4 modem. (assuming no
> overhead from SLIP - hah!). 72 bytes takes one 25th.
> 

> Note that you cannot make monochrome images from raw colour data.

OK, let me propose a compromise.  The server will not know or care what  
kind of color hardware the client has.  However the client can REQUEST  
not just PIX and SND types, but can request the types BW1, BW2, BW3, ..  
BW8 to receive black and white XPMs of one to eight bit planes and CO1  
to CO8 to receive color XPMs of one to eight bit planes per color.  The  
client is not required to always REQUEST the same type even within a  
session.  The server may either have all images stored in all image  
formats (unlikely) or it may just keep a few representative XPMs (like  
BW1 and CO8) and generate the rest as needed in whatever manner it  
believes best.

	Carl Edman