[crossfire] map redo: more layers.
David Delbecq
delbd at oma.be
Tue Sep 6 05:04:24 CDT 2005
Le Mardi 6 Septembre 2005 09:38, Mark Wedel a écrit :
>
tchize wrote:
>
>
>> The trickier part in all this is how to condense it down for the 3 objects for
>
>>old protocol. May idea would be to basically set up a table which says order of
>
>>objects you are looking at. The order would always be the same, but it may be
>
>>something like:
>
>
>
>
>
> why adapt old protocol, keep it's old behaviour (floor + 2 topmost objects)
>
>
I'd have to look, but I think the old display logic has a more complicated
>
logic than that (eg, things like monsters have pretty high importance in the
>
display order).
>
>
The old system basically had 3 layers:
>
1: Floor
>
2: Most important object, typically determined by visiblity value or other critier.
>
3: top object.
>
>
The problem with just taking the floor + 2 top objects is a couple spells now
>
obscure all monsters beneath it, which may not be a good thing. I suppose that
>
can be used as a first pass to see how things look, and if it breaks a lot of
>
stuff, work on refining i.
You don't get it, i meant, use the old code for that :) It's working so why change it.
Your problem is to get old client to receive old style message. Aswar is easy, call
old functions :)
>
>
>
> may i suggest static things like buildings/floor be sent once and for all to client
>
>
Static things in general will only be sent once - the new system should make
>
that more consistent - one problem with the old system is things can 'jump'
>
layers depending on other objects.
>
>
But if you mean send all static data for the map once, that creates a few
>
problems:
>
1) Imposes even more lag when hopping maps, as a potentially very large burst of
>
information needs to be sent.
Am not sure about it. A display of 25x25 client side currently means upon entering,
at a rate of 1.5 object/square a send of 938 data informations. Go left 6 steps, go right 6 steps
you send again 12 rows, that is 450 data object (containing face information mainly).
Total 1388.
Exit map (to heal for example) and renter it twice: +1876
total to enter a map, fight a bit, get out to heal, get in, get out to heal, get in:
3274 objects sent.
Now if map is 50x50 (map are not usually bigger), and assuming only floor is send separately, you get:
2500 floor object send upon first enter.
313 dynamic object sent
move left move right 6 steps:
150
exit enter twice:
616 additionnal information send
total:
3579
the gap between the 2 ways will reduce as long as player use the map.
Also as floor level is most of the time made of block of same arches, it will gain to get
some basic compression :)
>
2) potentially gives away map information (I'm ignoring the issue that most all
>
maps are available for download - one could envision a server running private maps).
if a set of map need not to be downloaded a simple thing is to have
a map flag 'this map is purely dynamic' then the computation of 'static parts of map'
will end with a list of zero items.
>
3) Gets trickier for the outdoor world maps
>
Not so much imho. Just let the client display 'several maps' at the same time.
>
IF you mean we only send that building once, then we need to track somehow we
>
don't need to sent it again (I imagine the case you're talking about here is
>
player steps to side so portion of map is no longer visible, then steps back
>
that direction so it is again). I suppose we can track that player has seen
>
that space before.
Tracking is easy. For each map, extract 'static information', do some checksum on it.
When a static information change (like is case from time to time using weather system)
obviously checksum changes.
2 things happens:
- players present in map simply recevie the new object like any dynamic object, but considering the layer
they are in, the client can detect easily this was the place of a static object, then client replace static object
with a new static object
- for player outside, nothing special happen until they enter the map.
When this happens, server compare checksums and decide client need to received again the static list for that
map.
What is interresting is, client can cache data even after disconnect! When client reconnect again it could tell to server
"Hello, here is the list of mapkeys i support and associated checksums".
Also, mapkeys could be quite small (24bits serial) if they have only a meaning during server runtime (which is supposed to be longer
than client runtime, so caching could be used at least for a few days). If we limit cache to 1000 last seen maps and assume
a 56bits checksum this brings only 10k to connecting protocol (last time i checked server badnwidth use it was about 3K/second while running and
am still convinced static caching+client side animation can improve this a lot.
Perhaps hacking a server to count what has been send as map data during game and what could have been send if static was send only once
could be a good idea. But the problem is static animations which will get in the way of stats (static part will change while if we let animations
handled client side, they don' t need to be resent). Deactivating animation code could be a good way to do check it (and would be partial as
in both protocol, face don't need to beresend :).
>
>
However, in both cases, I think the bandwidth savings by doing this are
>
relative trivial - granted, a player stepping back and forth constantly will
>
cause a row to be redrawn, but if players want to abuse stuff, they can hop back
>
and forth between maps.
>
>
>
> Also, think about integrating ground animations in protocol (i mean, do not send
>
> sea each time it change, better tell client there is an animated object on that layer)
>
>
This is reasonable, but I think we need to establish 'constant' animations.
>
What that means is that this is the animation sequence and this is the speed and
>
will always be the speed (which for things like water is true).
>
>
Then, we could send that animation info once, and then when we get such an
>
animation, just send the fact is is constant animation XYZ.
>
>
If we have to send animation speed/phase for such objects, this is less a
>
gain. And if we try to do it for monsters, I think it adds a lot of
>
complication for what once again may not be a lot of gain.
>
>
>
_______________________________________________
>
crossfire mailing list
>
crossfire at metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>
--
David Delbecq
Royal Meteorological Institute of Belgium
-
Is there life after /sbin/halt -p?
More information about the crossfire
mailing list