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

[Kjetil Torgrim Homme <kjetilho>]

Phew, this will probably be long.

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

+---
| [...] 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. 

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

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.

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.

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.

Of course, if we want to, we can on a per client basis reset the flag
whenever an object exits that client's viewport. 
SETF ONLY_KEEPS_VIEWPORT or somesuch.

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

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.


+--- Peter Mardahl:
| The current little display is kinda small, in my opinion, and I'd
| like to see the freedom in the design of the client to make the
| display larger.....

Like Carl said, a larger viewport is possible, but only the closest
11x11 (or whatever the default viewport size is - I vote we go for
13x13) will get updated.

In Xpilot, you can make the window as large as you like. This has the
affect that people on large displays (1280x1024 or even 1600x1280)
have a MAJOR advantage over those using lowly terminals with 1024x768,
especially in tournament maps. (This design decision in Xpilot is even
sillier when you consider that it uses vector graphics and therefore
easily could scale the graphics according to display size.)

+--- Philip Brown:
| Plus, what if some pixmaps got updated to "nifty k00l knew 1s", and
| the client doesn't know about it?  The user would never know to
| request the new version.

We could modify Scarrow's proposal. During lulls in network traffic,
the client could ask for checksums of (individual) images, and would
then request the images which didn't match its own checksums. The
client should remember when it last checked, of course. That way, an
intelligent client would have updated pixmaps after a day or so.


Kjetil T.