Re: A few thoughts on client/server

[Tero Haatanen <Tero.Haatanen@lut.fi>]

From: Kjetil Torgrim Homme <kjetilho@ifi.uio.no>

> One of the advantages of using symbolic names for all of the images
> was that an entreprising client writer could draw his own superior
> sets of images.

Of course we need symbolic names if client is going to cache images,
but this hopefully mean that they are mapped to numbers beginning of 
connection and not used all time.

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.

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.

>   2. I think it is best that an animations replay speed can not be
>      changed via the protocol. Animations with same images but
>      different speeds should have different names. I don't think this
>      will be common, anyhow.

Huh! The animation speed is depended to object's speed and speed 
changes are really common. One example which I have wanted to done
long time is players animation. Is there anyone who wants to fix
animate_object() so that in can handle animations in 8 directions?
This could be really useful for directors, cannons, arrows, spells,
players and so on.

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

> We should make the protocol so that making a UDP version isn't more of
> a hassle than necessary.

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

> 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
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.
And I prefer that server sends only images, which are players view
and updates for them. Makes easy and new features server and keeps
client code very simple. (Of course) dump animations are done by
client. This issue is very specific also how much cache client has
to keep. If its only the current view. most object names is useless.
But if it keeps the whole map, then these names are little more
useful, but this makes clients more complicated and requires clients
be aware of maps, so server can't implemented so easily the big maps
(from Ultima).

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

> It would be a win over X, for sure, but not much else.

What this has to do with X?

[description some variant of sliding window mechanism deleted]

> (every packet has a byte-sized sequence number, which is reset eachly
> tick)

And this doesn't make sense. You loose everything which don't came 
through in one tick or did I misunderstand? And what is tick? Could 
you give definition of this. The smallest time unit of server, update
speed (fps) or something do with player speed?

About damage command: Server should give those text descriptions and
hint about scale of damage. Damage values like 1 or 100 don't tell 
client anything without useful scale. And server admins might like
implemented system where actually nimbers are not show to players.

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 :) :).
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.

And floor discussion seems that you are talking totally different
thing with same name. Mark refers floors with meaning they are
used currently, players can't see under them. Kjetil refers floors
as meaning background (and mostly nameless ones). If you want 
backgrounds you have to add flag and update archetypes and not change
meaning of floors. And I agree that the current floors should not be 
transparent, it really doesn't make sense.

Now one new idea since I have disagreed in this post almost anything :).

Only reason to stack backgrounds is that you get nice looking map.
So there is grass below citywall, it isn't there because object grass
has some meaning (wall has the meaning, of course), but because
wall in grass looks better. One solution would be draw the huge number 
of images (all walls top of all floors). This isn't the reasonable,
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
even currently. Add some support to crossedit make it easy to use. 
Achetypes could use default combinations which can be changed in
editor if needed. These could be drawed only ones and added to
dynamical array (same that player pixmaps use) or drawad each time
(not very good). Last image could be used if only one image is drawn.
Remember that one object size is little under 250 bytes, so getting
rid of unneeded objects from maps is useful in this way also.

Example: The first is the current way from starting map:

arch cobblestones2
x 17
y 19
end
arch sign
name Press 'A' for Dungeon List
x 17
y 19
end
arch dungeon_magic
x 17
y 19
end

would come:

arch sign
name Press 'A' for Dungeon List
face cobblesto1.111,sign.111
x 17
y 19
no_magic 1
end

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

Any comments? Any one want to make code?

I was just going to post this when Gregor Schmid writes

> The code could be changed that you still can't see anything below a FLOOR --
> except another FLOOR.

Could you consider my idea? It little more work, but much more general
solution. If game could even draw multiple faces same time would be
good, caching and crossedit support can be added later.

 -Tero