Jump to content
  • Advertisement
Sign in to follow this  
sipickles

Efficient movement messaging

This topic is 3976 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'd like some advice on efficient ways to move client objects, and although the forum FAW is illuminating, I'd like to expand on that abit. First some background. I am making a strategy/adventure game. Twitch response is not required, but I would like direct player control of their object to be possible. My prototype used simple periodic updates containing position, heading and speed, calculated by the server. The client also tried to map objects movement, deferring to the server updates and blending where necessary. I then planned to change to a dead reckoning system, so instead of instantaneous speed, position and heading updates, I would send: startPosition endPosition durationOfMovement These would only need sending when some aspect of the movement had changed, like turning, theoretically slashing the network bandwidth. The client could lerp to fine actual position. I then realised that stationary rotation is not included, plus accelerating/decelerating objects would generate huge streams of updates, since they are effectively changing their endPosition. I now wonder about some sort of Hybrid of the two options. What have others done in this situation? Thanks Si

Share this post


Link to post
Share on other sites
Advertisement
I've decided that position is a function of time, f(t), and send the function f over the network as a closure (a function-pointer identifier and any necessary parameters).

Share this post


Link to post
Share on other sites
True, a straight path would have a function representing a 3D gradient for which lerp() is used, with a curve or orbit represented by errr..... centre, radius, quaternion?

Quaternion Slerp is used in this second case?


Share this post


Link to post
Share on other sites
Another way to think about it is to interpolate the player controls, and run the simulation just like you would on the client. If you run physics, say, 30 times a second, then simulate the interpolated objects the same way, using whatever control information you have handy. To guard against drops, baseline the information every once in a while, and interpolate towards the baseline-derived position to hide any snaps.

A third way to think about it is that you'll get updates often enough that linear interpolation will look round to the player. This is the approach taken in EPIC (Entity Position Interpolation Code).

Share this post


Link to post
Share on other sites
Is your engine deterministic? If so then just have the server pass around input.

"Player selected from (10,20) to (50,100) rectangle and made a move action to (20,40)"
but in binary format, of course.

If for some reason the game gets out of sync just pause it and do a quick full state update.

If your engine isn't deterministic then your idea seems sufficient. Storing things like:
EVENT_ID_MOVE//byte
number of entities
entity 1 ID number//short?
position //(short, short)
move to //(short, short)
entity 2 ID number
...etc

The orientation when the player stops would just be the facing direction when they stop I'd imagine?

By this idea sending out updates at 5 times a second (probably the most you'd need to send) then you have where n=number of entities, packetSize = 1+2+(2+2+2+2+2)*n or 3+10n bytes 1400 = 3+10n so n = 139 entities. But that's with no optimization. Also 139 entities in an 8 player game is 17 entities per player. If the server delayed and only allowed 1 state update a second for each player then it's not a problem. Also the server could very easily optimize the actions sending only 120 a second in queue and "throw away" the ones at the end.

"I would like direct player control of their object to be possible."

What did you mean by that? Like as in the player controls the character with w,a,s,d?

//whoops realized this is non twitch. Still fun info dealing with serialization
If efficiency is a problem, also take a look at how you're sending the data.

If the max speed of an object is 127 and the mantissa isn't important then you should be using a byte. (-127 to 127). If the orientation isn't based on velocity and you only need 360 then use 9 bits. or use 8 bits and calculate the difference. I mean 5 bits would allow 32 angles of rotation.

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!