Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Jasten

The effects of mouse orientation on client prediction

This topic is 5316 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

For those of you who have not read past threads, I am currently developing a third person capture the flag game for a senior project. My task is to write a networking engine from the ground up using sockets and a client server archetecture. Over the past week I have been working on reducing lag to get player movement looking smooth. The basic setup for the game is as follows: -Synchronized Timers on all clients and server that is used to run prediction when a position packet arrives. -All keystate information is sent to the server every 200ms or if there is a keystate change. -The keystate packet arrives to the server along with the clients position and velocity and position is adjusted for travel time. -Every 200ms the server sends client position,velocity and orientation data to clients. -The clients recieve position data and adjust it for travel time based on the synchronized timer. OK now for the problem: ----------------------------- Currently positional lag is looking pretty good. Prediction is reducing the jerks to very small and can be hidden behind the animation, hopefully. The problem at hand is with the orientation of the character. The mouse movement determins what direction the character is facing and consequently what direction moving forward will take him. Now obviously I cannot send a packet to the server every time there is mouse movement so I send orientation whenever I Send keystate information. The problem is that by the time the server gets the packet the client has most likely kept moving the mouse. So when a client moves forward and uses the mouse to change direction, the client gets out of sync with the server. Once a positional packets gets to the client he is snapped over to his position on the server. So essentially I have smooth movement until I start moving the mouse to change my direction. From my experiences with first person shooters that use mouse orientation I have seen it done very smoothly. Does anyone have any suggestions for how to reduce the lag for mouse movements from client to server? Thanks, Daniel Doptis

Share this post


Link to post
Share on other sites
Advertisement
The trick is hiding the position updates. On the client, assume that everyone play just like the server says they do. When you receive a server packet saying "oops, they''re over there because they turned" then you don''t immediately snap the mesh to the new position. Instead, you blend the position of the mesh between the old predicted position and the new predicted position, over the duration of one time step (i e 200 ms in your case).

Yes, this means you use a different orientation and position for your dead reckoning physics code than you do in display, because you need to update the physics state to the latest from the server, immediately.

Also, you should probably send packets more often than 5 times a second, if this is an FPS. Work on making the packets small, and send them 10, or even 20, times a second for a smoother feeling. Even though it may take 200 milliseconds for a packet to go from server to client (over modem), having another two packets in the pipe when the first packet arrives is not a bad idea; it''s actually usually a good idea.

Share this post


Link to post
Share on other sites
Orientation can be compressed into a 2 byte form, which can indeed be sent every update cycle. At 20/sec update that''s only 40 bytes/sec upload. I think you can spare that bandwidth

-ddn

Share this post


Link to post
Share on other sites
Thanks for the helpful advice. I implimented the interpolation this morning and it cleaned up the mouse movement issues nicely. Just one major issue left that im going to create a thread about. Once again thanks to everyone on the forum for helping me through these issues, Im learning so much from this project and the helpful people here.



Thanks,
Daniel Doptis

Share this post


Link to post
Share on other sites
usually in FPS the client is authoritative regarding his orientation.
In the last game I worked on we sent n keystates per second
and each one contained the current client orientation.
Result, very accurate aiming and smooth navigation.

ciao
Alberto



-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net

Share this post


Link to post
Share on other sites

  • 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!