Sign in to follow this  

Efficient movement messaging

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

This topic is 3664 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this