[CF-Devel] Combat animations/sound

Wed Feb 11 01:40:27 CST 2004

tchize wrote:

>

      Not really true. Move one step left, you get a mapscroll followed by the left 

     >

      map column sent by server. But then move one step right, the server send 

     >

      again the right column which disappeared when you moved left. 

  True.  At one point, and perhaps still for some clients, the client didn't 
store what disappeared off the edge.

  However, the bigger problem is how much do you presume the client will hold? 
20 spaces?  50 spaces?  How do you deal with the tiled world maps.

  I'd also note that there is the potential trading of bandwidth, similar to 
image caching (spend time at load time to get all the images, so it doesn't 
spend any time during play, or get the images during play).

  The same would hold true on maps.  First time you enter a map, potential 
larger delay as the entire map is sent down, but then less because you can move 
around with less data getting uploaded.

  The biggest problem I see is this adds a lot of complications - the server has 
to have some idea on what is defined as a stable space.  The client has to have 
some caching mechanism for these maps (being able to load and save them), 
verification if the map is the same different, whether the map is one that 
should be sent down or not, and probably other considerations.

  Also, while the argument that public maps are already in CVS, so players could 
download them, there is still the problem of giving stuff away.  Some maps I can 
think of are series of small rooms connected by teleporters - the client getting 
hte entire stable area now means it is much easier to see potential areas of 
secret chambers, and perhaps makes them immediately visible (I can see the wall, 
I can see there is floor behind it..  hmm).  If the client displays info the 
player isn't suppose to know about, you can't ask players to ignore that info.

>

     >

      And the backgrounds animations are a big problem too. Be near the seen ad you 

     >

      get agian and again map updates.

  Well, depends on number of animations and how fast they are animated.  Sure, 
standing near something that is animated will cause constant updates.  But if 
your only sending a few hundred bytes/second, that is hardly a big deal at all.

  Animating some images may make sense - if it can be figured what objects won't 
move, and which ones have constant animations, sending animation info for those 
probably makes sense.

  However, for some, syncrhonization here is also vitally important.  This 
certainly is not the case for anything in the player inventory.  But if you have 
something like spikes or gates, you have to be 100% sure that the client is 
displaying the same phase as what the server thinks it is - if it is off even a 
little, could cause serious player injury or death.  And keeping them 
syncrhonized that closely could be difficult.

  Probably the ones most worthwhile to animate are temporary images (burnouts, 
spell effects).  These are ones that can show up a lot over a map and animate 
relatively quickly.  Thus, there is little danger for the client to get too far 
out of sync with those, it saves a bunch of animations, and if the client knows 
they expire, means that the server can even save the bandwidth of 'clear this 
layer'.

>

     >

      Already thought about it. Think about something like sending 'object (eg orc 

     >

      5147831)' at location, and along with it a value derivated from speed_left 

     >

      (which is used to know when next step of animation is to trigger) the speed 

     >

      value and the animation. Because some object have different animation at 

     >

      different time,s server could send info like <change animation for object 

     >

      5147831 to animation number 7452>

     >

      or could send infos like <object 5147831 moves of -1,0>, but those info should 

     >

      only be send for non fixed part and only if  <object 5147831> is visible by 

     >

      player (or becomes visible or disappear) so this would prevent 'look thru 

     >

      wall/ track monster' cheats

  Yeah, there are lots of ways this could be done.  The real question is how big 
a gain it is (if your sending creature, animation speed, animation phase, and 
animation number, you are now talking potentially 8 bytes of data for that, vs 2 
bytes for just an image).  It pays for itself in 4 frames, if the creature stays 
in place that long.  But it also adds a lot of complication.

>>

       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.

     >

     >

     >

      and sea

  And sea is another one of those good cases - synchronization not important, 
phases isn't important, etc.

  However, in some cases, like sea, you'd almost want a simpler model - all seas 
are animated at speed X, so ideally, you'd want to be able to establish that 
speed once, and then just say 'space x,y is animated sea', and let the client go 
from there.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

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