[CF-Devel] Combat animations/sound

Tue Feb 10 02:31:27 CST 2004

tchize wrote:

>

      - additionnal layers (bottom of everything, bottom, middle, top, on top of

     >

      everything). Not yet fixed, see point below.

      > - More than one visible item available in a layer (they just stack at that
 > layer)

  Note that also requires rework on the server side - currently, the server only 
calculates the face for 3 layers (floor, middle, top).  So at some level, there 
will always be some imposed limit on the number of layers - there is some 
practical limit (in very early hacking I did (before the client/server split), 
aside from performance of drawing every object on a space, after you get a few, 
the pile just looks like a complete jumble - only the top couple were 
distinguishable).

  That said, adding layers could be nice.  One of the problems right now related 
to the map sending is that faces can 'change' layers.

  eG, you could have floor, food, orc.  However, now an arrow is fired, and 
passes over the orc - that space would now be drawn as floor, orc, arrow - 
basically meaning 2 faces get updated.

  If you say there are like 4 layers, that could work reasonably well - you 
could basically have up to 2 objects/layer - the layers being floor, 
equipment/misc objects, creatures (monsters & players), and flying objects.

  That would generally fix the problem above - food would be on the equipment 
layer, orc on the monster layer.  So when the arrow shows up, it just goes on 
the flying laying, so the stuff underneath doesn't need to get updated.

>

      - Map is made of 2 concurrent part: * The mostly fixed one (ground,

     >

      buildings, non pickable/non killable items) * The non fixed one (mainly

     >

      monsters and pickables).

  As I mention below, I don't see the gain in doing this.  Server already works on
not re-sending data the client knows about.

  So the only perceived gain I could really see is that somehow the protocol 
itself could be made more efficiently.

>

     >

      The mostly fixed part of map would be send to client only one time. This 

     >

      would includes additionnal info like blocked squares (so client can 

     >

      precalculate moves, and make things look softer). Changes to this part of map

     >

       (which may happen from time to time) will trigger a patch event from server 

     >

      to client so map are against in sync. I am thinking about using a big picture

     >

       for the map background/buildings/Walls(so mapmakers could design a map made 

     >

      of something else than squares)

  Well, a big picture is a different issue.  The idea itself is nice.  However, 
that is more of a nature of the client itself sending the background, and the 
other layers still being drawn on top of it.  So I'd then say that gets into an 
issue that the map shouldn't have the extra layers if it is designed with that 
background.

>

      No need to say map animations would be handled only by client.

  Note that map animations get trickier than inventory animations.

  This is mainly for two reasons - 1) inventory animations don't change much 
(eg, the only one I am aware of that will change animation speed is the power 
crystal) and 2) You need to send more state info for map animations.

  The second point is consider a map with 20 orcs.  You don't want them all 
animated in the same phase - there is code to make it so that doesn't happen 
(There speed is randomized).  Likewise, there are many more things that can 
effect the animation phase of creatures (spells, terrain, etc).  So now for 
those 20 orcs, for each orc, you need to store away the phase, animation speed, 
and animation.  And I'd have to look at the code, but the time to next phase may 
be necessary (eg, a creature that has speed 0.25 will sit in phase 1 for 4 
ticks.  So even if we say it is on phase 1, does it stay on phase 1 for 1 more 
ticks, 3 ticks, etc).

  So it becomes a much trickier issue of whether the client handling all that, 
and the server sending that once is greatly more efficient.  Eg, if the player 
is standing still, kills an orc, and another orc steps up, need to send all that 
stuff for the new orc, which is not likely to be on the same phase

  Now there are some cases where it is more a clear cut gain.  The moving 
spikes, burnouts, etc, are things that won't get effected, and our stationary.

>

      That's why 'mostly fixed' should be choosen with care. Nothing. Also note 

     >

      that client already knows more than player (aka disable darkness code an see

     >

       better. i know complete dark is not send but nearly complete dark is alaos 

     >

      difficult to see). The main idea is to prevent sending map info to client if

     >

       they are the same as in released maps.

  But darkness was always optional - it is a visual effect, and is known that
clients may display it differently (some settings within the gtk client may make
  the images more/less visible).  However, for all purposes, a dark space is
still considered with view (eg, if you look at the space, you get the same level
of detail).

  Note that the server already does work to make sure we don't send data the
client already knows about.  So I'm not really sure what is gained by trying to
send the static data only once - that is basically already happens only once.

  And I really don't want to add the extra complexity of 'this is a public map,
handle with method X' vs 'this is a custom map, handle with method y'.

  And from a client perspective, this can get more complicated.  Eg, one can
rightfully consider using fog of war not cheating (it is just showing you what
you've seen before).  But the simplest implentation of the client basically says
if we have info for a space draw it.  So now you could get players seeing stuff
on the fog map that they havent' actually seen yet.  In a sense cheating, but
not intentional on the client side.

  Since I started this, a few thoughts on what I'd like to see in the map protocol:

1) Sound support.  Current sound stuff could use this, but I'm also thinking 
about if you have recurring sounds or the like (sounds of a waterfall, those 
moving spikes, etc.)

2) Lighting - instead of sending darkness for each space, tell the clien that 
the map is dark X, and instead send the light sources (and their intensity). 
This would actually reduce bandwidth, and should also make it easier for better 
lighting effects (server would still calculate darkness just in terms of line of 
sight).  Related to this, light sources could potentially have different colors 
- of course, up to the client if it can do anything with that.

3) Clean up some of the handling as related to big images and their heads. 
Ideally, server can mark there is a head object on a space so that the code for 
sending the packet doesn't have to do as much work.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel