Re: A few thoughts on client/server

[Tero Kivinen <>]

Tero Haatanen writes:
> If client writer makes his 'own superior sets of images' then server 
> admins take these anyway and use these as server images also. :) And 
> client maker forgets convert anyway some part of wall (which can be 
> added to server later) and give out all secret doors.

Server will of course send same image for wall and secret doors until
the player finds the secret door. There is no way the client can make
'own superior sets of images' except that they can look better or be
faster for players display. Player cannot get any more information
about anything with them. 

> Clients should be easy to make and expand, but they should show the world
> that server gives them, not make their own, IMHO. This includes maps, 
> images, sounds, LOS and probably much more. Cheat clients use every way 
> thay can, but 'normal' clients shouldn't use any these features. And
> 3D clients aren't really useful to crossfire, someone probably hacks
> server to support for them and then makes client which use 3D features.

If someone is using some SGI workstation to play and he wants to use
gl-graphics and show the 3d view of world too, there should not be
anything in protocol that requires any changes in the server. The
client only shows some 3d objects in 3d graphics world for every
image. So if server sends info saying here is wall the SGI client will
draw 3d box in the players view. There should be no modification for
server to do this.

Of course if the server uses some images (say new table) that SGI
client doesn't know how to draw in 3d the client can fetch the pixmap
of image and try to do some cleaver with it (like drawing a 3d box
which have that image in all the sides, or if player have already
walked through it (or there is some other items in the same place) it
can draw it as floor with pixmap acting as texture). Then when new
client will come out it will add new code to display this table as
real 3d object.

Why should the server be prepared to send data in all possible formats
in which the client may want it. I think the server should send
something very simple and all the converting etc is left to client.
It should be enough the server to support pixmaps, and perhaps the
1-bit bitmaps too (if client is say 2-bit display, it may use either
one of those as selected by player). 

> > Onto ASCII->binary->UDP: The way I see it, that's the route we should
> > take.
> And leave that ASCII step away :). I agree that first version is probably
> better be TCP, so that something gets done.

I would leave the binary part away, and not even thinking to going
UDP. Crossfire WILL need reliable data transfer protocol anyway, so if
we are using UDP we have to create such over UDP thus recreating TCP.
The TCP is very clever for doing all kinds of optimizations for slow
or long turnaround links. If we are trying to do better than that we
have quite a lot to do...

> I totally agree, here. And this is why I don't like Carl's original
> protocol since it requires reliable comminication channel.

As a said in previous paragraph we WILL niid reliable communication
channel anyway. At least for some data, so why not use it for all
data. 

> > A protocol which doesn't care about lost packets would have to be
> > _very_ graphical in nature. 
> 
> Not _very_, if we divide protocol to two parts. The first is on which

If the protocol have any graphical nature I think it is bad. It should
be in much higher level than that. The client will usually already
have one graphical protocol talking to display, why should we add
another?

> offers reliable transfer. All player commands, and some server
> commands (like pickup) use this. This is only small part of traffic.
> The biggest part of traffic is map updates and these don't need 
> be reliable (in strict sense). And these go old very fast, means if
> you get view which was true the second ago, you can be in trouble.

I would say that they should be reliable too. I hate in xpilot that
usually when you enter to battle when there are few ships the next
thing you see is you flying back to base after crash. In xpilot that
isn't so bad because you are dying all the time, but in crossfire one
death of that kind would be one too much.

The only thing in Carl's proposal that bothers me is that this can
happen in that too, but there can only be some time difference between
the action and the time it is seen in display. In UDP those time
differences happen much more often...

Another thing with UDP is that we have to be sending the images all
the time (if we are not doing that then we will need reliable
channel), thus even if I don't do anything in crossfire there will be
constant flow of UDP-packets flowing from server to my client. As
network adminstrator I think that IS VERY BAD. Currently the xpilot
has caused several problems with network load and it have even caused
our main nameserver to crash several times (ok, there was bug in
xpilot then, but if any of such thing is repeated with any other game
here it may cause that all games will be forbidden again). It is very
easy to fill in the network with junk just be sending the same data
again and again. TCP headers are small compared to sending all the
user visible data every time (tcp headers (20 bytes) - udp headers (8
bytes) = 12 bytes, full image 11 * 11 = 121 images). TCP will also
send ACKs etc together with data so if we have some data going another
way too the ACK will take no extra bytes. 

> I prefer simple graphical client, but this is partly only playing 
> with words. If we think Carl's protocol and don't require the whole
> map caching, it's graphical protocol since it tells client what
> player see, nothing more or less. Some object names are send, others

I would say it is world mapping telling the information player can see
from the world. It isn't graphical because it doesn't say draw that
image to there, but it tells that you see that item there. If client
wants to know how to draw that item it can requests some simple image
of item, but that isn't mandatory. 

> not. Of course client can show items which it 'remembers', but
> it has not knoledge if they are still there. The protocol gives 
> coordinates, but these aren't useful for player since they don't
> identify players location in world, only in one map. If server
> send updates 11x11 area then the protocol is graphical in nature,
> it doesn't make differentce if origo is upper left corner of map 
> or upper left corner of players view.

I don't see how that the server only sends stuff that player can have
information about makes the protocol graphical?

> I have to admit how Carl wants to keep his original protocol, if some
> feature requires more bandwidth then better drop feature and not
> find better protocol :) :).

Or add it as an extension that can be disabled if you don't have
enough bandwidth. 

> If shading is implemented and protocol use only graphical updates and
> not item updates, then this would add almost no overhead. Since server
> has to calculate this anyway why bother client with it, just give
> nice looking view.

The server could also send only the static shading information and the
client can add the light that items are emitting (add one more
information to item telling how much it will emit light). Because all
the shading is only to make display nicer (it may not have any effect
to play, because the information about items is send to clients anyway
even if they are mostly in shadows) there is no need it to be server
matter. Of course server can calculate the area seen by player using
lights but then it wont have anything to do with client, because
server is only sending information from player visible area.

> but object face could be changed so that one face can be more than
> one image (face image1,image2,image3). This is quite easy implement

This sounds good, perhaps we should add flips and rotations there too,
so the image can be (face (grass), (table, 45)) table rotated 45
degrees on a grass or (face (grass), (table,,h)) table flipped
horizontically on a grass. All this image manipulation can be done
quite fast when the image is first time needed, and after that it can
be cached. Of course you cannot rotate wall 45 degrees and assume it
will make join perfectly to other walls, but at least you can make
some more varations for items etc. 

> One more useful feature would be have different looking floors
> below walls (face woodfloor_left,grass_right,wall).

Cool...

> Any comments? Any one want to make code?

I hope I would have more that 24 hours time in a day so I would have
some time to hack on crossfire, but perhaps I will have more time in
the summer (I have said so every year :-)
-- 
              	     Work : +358-0-451 4032
Magnus Enckellin kuja 9 K 19, 02610, Espoo   Home : +358-0-502 1573