Jump to content
  • Advertisement
Sign in to follow this  
mattm

Coordinated animations in FPS networked game

This topic is 2693 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I have been implementing a networked FPS game to teach myself the techniques that Valve et al use to implement a fast action game over a network.

I have had some success implementing interpolation, client side prediction and lag compensated firing but one thing that interests me is the coordination of animations across server and client, and the best way to do it.

I am currently implementing it with my normal interpolation routine. That is, every time an update occurs it looks at which actions where done that update cycle, which were done before and updates its animations, and times, accordingly. Given that both the server and client know the animations that an entity can perform, and the interpolation code on both is the same, this works very well and means that, baring the first message where the initial times of animations needs to be passed, no expensive animation timings need to be sent on the updates. However, I am now looking at filtering my messages so only those entities affected by them receive them (if your'e not visible to another player they don't care where you are etc). At this point my interpolation breaks down a little as if an action change is missed then the calculated timings of the animations will be wrong. I know I can solve this by optionally passing in the animation times at any point to allow the interpolation to restart from the correct point but there are other issues with my approach; for example animations not explicitly defined, such as when they become ragdolls, cannot be synch'd across clients. This is no big deal, they are only for effect anyway, but was still wondering if other people had experience similar problems and how they solved them?

Share this post


Link to post
Share on other sites
Advertisement

hen the calculated timings of the animations will be wrong. I know I can solve this by optionally passing in the animation times at any point to allow the interpolation to restart from the correct point but there are other issues with my approach; for example animations not explicitly defined, such as when they become ragdolls, cannot be synch'd across clients. This is no big deal, they are only for effect anyway, but was still wondering if other people had experience similar problems and how they solved them?


Generally, you separate animations into two categories: For display only (can differ between systems) and for physics/simulation. The physics/simulation animations must be synched, whereas display-only animations don't. Examples of display-only animations may include particle systems, muzzle flashes, ragdoll limbs, etc. You can simulate the trunk of a character physically, and make the limbs be display-only, btw. You can also have an interaction where the location of all joints is "snapshotted" and distributed to everyone after the ragdoll comes to a rest, if you want the end result to look the same.

Interest management -- who do you "see" or not -- is an interesting problem. There's a trade-off between initially having to seed everyone, and then receive update streams for everyone, versus only seeding and updating some number of entities, but then having to add new entities to the interesting set at some frequency. If you support late joining players, you need the ability to late-add an entity anyway, though, so you'd be more likely to use a limited visible set.

Hope this helps!

Share this post


Link to post
Share on other sites
That helps a lot, thanks.

In terms of syncing relevant animations I am guessing that this is normally done with a message to say an animation has changed, along with the time, and then allowing the client to interpolate to give the exact frame? I am guessing that sending location/rotation for each bone each client update is probably too expensive on the network and probably wouldn't yield better results anyway?

I am supporting late starting and this currently works by sending the current animation times for existing entities. Currently this is a little messy, but once I have cleaned it up it should simply be extended to support an entity reappearing on the visible list.

Matt

Share this post


Link to post
Share on other sites

frame? I am guessing that sending location/rotation for each bone each client update is probably too expensive on the network and probably wouldn't yield better results anyway?


Animation really is two things:

1) Movement that is based on physical simulation. For this kind of "sync," then the physical simulated bodies need to be synchronized. This generally involves four three-value quantities: position, orientation, linear velocity and angular velocity, so it's expensive to bring in sync.
2) Movement that is based on playing back a canned timeline animation. This can be synced simply by saying "animation X started playing at time Y" -- the client can always synchronize the animation by calculating current time minus start time, and find the right frame of animation to play.

There are blends, too. For example, walk/run animations are often advanced in time based on movement speed (to avoid foot sliding). While they are physically derived (from simulation), they aren't necessarily synchronized, because they may have set the first footstep at different points in time. This *can* be synchronized by saying "movement animation at frame X at time Y" and then dead reckoning forward based on velocity, but if you don't have a full history of your velocity, it won't be perfect. Usually, that doesn't matter.

Share this post


Link to post
Share on other sites

[quote name='mattm' timestamp='1304547213' post='4806617']
frame? I am guessing that sending location/rotation for each bone each client update is probably too expensive on the network and probably wouldn't yield better results anyway?


Animation really is two things:

1) Movement that is based on physical simulation. For this kind of "sync," then the physical simulated bodies need to be synchronized. This generally involves four three-value quantities: position, orientation, linear velocity and angular velocity, so it's expensive to bring in sync.
2) Movement that is based on playing back a canned timeline animation. This can be synced simply by saying "animation X started playing at time Y" -- the client can always synchronize the animation by calculating current time minus start time, and find the right frame of animation to play.

There are blends, too. For example, walk/run animations are often advanced in time based on movement speed (to avoid foot sliding). While they are physically derived (from simulation), they aren't necessarily synchronized, because they may have set the first footstep at different points in time. This *can* be synchronized by saying "movement animation at frame X at time Y" and then dead reckoning forward based on velocity, but if you don't have a full history of your velocity, it won't be perfect. Usually, that doesn't matter.
[/quote]


Thanks for the pointers. I think I am on the right line with my thinking. Sometimes I worry that the choices I have made have missed something obvious, but then I guess that is what learning is all about.

Share this post


Link to post
Share on other sites

why not send to server actual player frame index and then send it back to other clients


Because data you don't send is more efficient than data you send.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!