[crossfire] map2 & animations

[Mark Wedel]

  I've started work on the map2 command - preliminary documentation on that has 
been in the Protocol file for a while, but I have made a few minor changes.

  However, I was looking/thinking about letting the client handle the map 
animations.  From a protocol perspective, this isn't really hard - we just need 
to send down some extra information.  My initial thought here is to just set the 
high bit on what is normally the face num field to denote this is an animation 
(this limits us to 32767 faces, but I'm not that worried about that).

  Also, to make things work better, I was thinking a couple extra bytes are 
needed - 1 for the animation speed, and one for the current animation position 
(where we are in the sequence).  The later may or may not be important depending 
on how we deal with things.  My thought is that for things like monsters, if we 
animate them, we want to send that - otherwise all the monsters are in a lock 
step formation.

  However, as I think about it, there are really 4 cases for animations we care 
about:

1) Animations that should be lock step.  Point in case would be the ocean spaces 
- it would look better if they were all in phase - right now, you can see the 
edges of the tiled maps because the phase between the two maps is different.

2) Cases where it should be randomized.  Monsters come to mind in the case - the 
phase of animation for things like goblins isn't important, and it does look 
better if they are in different phases.  Randomizing this on the client works 
better than sending current phase because of timing.  Think creatures that have 
a speed of 0.20.  Once every 5 ticks, they move and their animation change.  If 
we only send current phase, that means the client will have all of them on 
'phase 2' go to phase 3 at the same time, and then all of them don't change for 
the next 4 ticks.  If the client randomizes this on its own, then 20% will 
change animation each tick.

3) Animations in which phase is important (or temporary). Example here would be 
things like gates/spikes.  In this case, the client really needs to know what 
phase the gate is in when it shows up - it can't lockstep it or randomize it. 
In addition, timing here is important - if the server spends a second loading a 
map, the client has to be aware that those gates haven't done anything for a 
second.  This isn't that hard to solve by adding something like a 'S-C> 
hearbeat' protocol command which the server sends each tick it processes.

  But here, we still get a timing case - suppose those gates move at speed 0.2. 
  Just telling the client that it is on phase 2 really isn't enough - the gate 
could go to phase 3 the next tick, or to that phase 5 ticks from now.  So to 
handle this, not only do we need to send the phase, but also how soon until the 
next phase.

  My personal thought is this:
Add new flag(s) which says how to handle animations.  My personal thought is 
leaving case #3 as a server side is probably the easiest (server side being that 
we don't send animation to clients, just send face for the space like we do 
now).  This doesn't get us as much of a bandwidth savings as possible, but does 
keep things simpler - at some level, its a balance of how much complication do 
we add to save some bandwidth.

So I'd suggest addition of two new flags - one to handle case 1 
(FLAG_CLIENT_ANIMATE_SYNCHRONIZE) and case 2 (FLAG_CLIENT_ANIMATE_RANDOMIZE). 
These flags would be used to tell the server that we should like the client 
handle the animation (hence the CLIENT part) as well as to tell the client how 
it should handle the animation.  My thought is the top bits could be used to 
convey this.  So something like:

<MSB>: If set, this isn't a face, but animation id:
<MSB-1, MSB-2>:  Convey animation type.  Right now, there are only 2, but it is 
good to leave a little room for expansion (I could perhaps seeing something like 
a FLAG_CLIENT_ANIMATE_ONCE for things like burnouts to denote that that once the 
animation gets to the last step, it should stop animating and not cycle)

  This leaves 13 bits for animation id, which is 8191 animations.  Given we only 
have 989 right now (and that could actually be brought down by merging some of 
the multipart images to big images), I'd think that should be plenty.

  Thoughts/comments?