Interpolate 3d space

Need some math help again. I need to figure out how to interpolate movement (dead reckoning, I guess) between my client and server. The client tells the server it is moving and starts moving locally. the server gets the move and starts moving the server version of the object as well. The server then sends updates to the client with what the server believes are the x, z and heading of the object. For a very small number of clients, the numbers are only off by a wee bit, but I was not sure how to handle the “ramping up” to get the client and server to match when movement stops or at a set interval or whatever.
example data snapshot:
client: z = 10.024863f h= -2590.4539f
server: z = 7.2251563f h= -2601.2512f

As you can see, the are not off by too much after 30 minutes of movement and idle time, but I would like them closer or mathcing. What would be the best way to get the client vars to match the server vars at motion stop or pre-defined intervals?

anyone? (shamefull bump)

I’m not completely sure if I understand your question. If you want the server to match the client then it has to do exactly the same computations as the client. This includes any time variables. Using fixed time intervals will help. Then the client has to update the server about anything that changes it state. Then the server has to update it’s state it the exact same way. This may involve rewinding the simulation to incorperate changes that was delayed during transmition.

Well, in technopolies it works as following:

client: move to X,Y
server: ID XX moving to X,Y with SPEED Z
client : starts moving when acknowledgement from server comes

server : ID XX moved to position X,Y
client: synchronize position

client maintains a separate copy of world which is synchronized between server and client,
and additionally a facade for the server world which paints the world in 3D.

When an event arrives, client updates objects in it’s copy of server world. Movements in “server” world could be
rough because of the lag between server and client :

  1. the server sends notification that object A arrived to point P,
  2. client receives event (object A on client could still be several meters away from point P)
  3. client sets Object’s A coordinate to P

To make movements smooth, facade objects for game world add some inertia - they have own coordinates which are interpolated every tick towards coordinates in a client’s copy of the world.


    protected void smoothMovement(SimpleVector difference) {
        float length = difference.length();
        long currTime = System.nanoTime();
        long ticksDiff = currTime - smoothMovementTicks;

        float coeff = (float) ticksDiff / (float) 600000000;
        coeff = Math.min(1, coeff);

        float angle = Entity.calcAngle(difference.x, difference.y);
        setAngle(angle);

        //move immediatelly if the difference between server and client copy is too big
        if (length < 100) {
            difference.scalarMul(coeff);
        }

        getObject3D().translate(difference);

        float len = 0.06f * difference.length();
        if (len > 1)
            len = 0.2f;

        if (length < 5)
            moveAnimationCounter += 2 * len;
        else
            moveAnimationCounter += len;

        if (moveAnimationCounter > 1)
            moveAnimationCounter = 0;

        if (length < 5)
            WALK.animate(moveAnimationCounter);
        else
            RUN.animate(moveAnimationCounter);
    }

thanks, that gives me something to get my hands around…

Yeah I think the above probably says thsi in more detail but just to reiterate.

You have the approximated motion you performed in the past. You have the actual action in the past. If yo uwent abck in time and based your approximation on that knowledge, your current approximation would be different and more accurate.

Think of it like a dither. You have a carried over error term for each frame which is the difference between the current predicted motion position and the more correct position you woudl have precited had you had the information. (I say mroe correct because thanks to latency you never know the exact position in the present, only in the past.)

Each frame you want to calculate the error term. if you add the whole error term in then you’ld correct fine but you’ld “warp” so instead you want to only add in some portion of the error term. As I said, its like a dither. next frame you find the next error term and do it again. If you are doing it correctly the error term shoudl be decreasing over time UNTIL new information comes in. Then you’ll need to do it all over again.

I agree, the world has to be both on server and client. Another problem is synchronization. What I did in
one of my games was to send a synchronization packet to all clients from the server after 10 iterations
or so.

Similar to above, I did the following:
0. Server and Clients are initialized with the same world

  1. Server updates its world periodically and sends synchronization packets every so often.
  2. If a client changes:
    a) client sends move to server (the client that generated the move, does not move yet)
    b) server sends moves to ALL clients
    c) server & clients update world based on move (the server tells the time in which iteration the
    move has to apply.

It also depends on the game if this is a feasible option to you.

I’d seperate the issues here, really.

Whether you have a single server that has the “correct” world state or you use a scheme where responsability for the world state is split among the users (typically each suer is repsonsibel for themselves and their “shots”, the issue is fundementally the same-- one of prediction and correction of the non-local information to cover latencies.

This is assuming ofcourse this is an action game and not a turn-absed where you can afford to just sit and wait for updates for however long it takes, but if we were discussing the latter then it would be a non-issue and there would be no need for discussion 8)

A seperate issue is how you architect the understanding of what is “correct” in the world. As I mentioned, one solution is to have a server-side model that is the canonical oen and give everyone imperfect represontations of that. This is the only truely secure model for such an action game if you are worried at all about cheating as anything on the player’s machine cna be potentially manipulated by the player.

HOWEVER a simplsitic model like that leads to the LPB (“Low Ping Bastard”) phenomenon, as we saw in Quake 2, for any game that requries reaction timing. The lower someones latency to the server the mreo control they have and thus they have an unfair advantage. For this reason in action games we usually see a mixed server/client strategy that does not peanlize the high ping players so much but also doss leave some potential cheat holes up. The game developer in this case instead of focusing on cheat avoidance generally tries to create cheat-detection, with varying degrees of success.

Most MMOs get around this by removing the twitch element entirely. If you really loo kat their combat systems, even the most phremetic ones such as City of Heroes are really using a tactical system where the user is only sending one command every few seconds at most and there are generally reasonable “default” actions if the action has not gotten tp the server by the time the combat round needs to be calculated.

I hope that ramble helps some. As I say, ist best to clearly sperate the issues in your head. They come down to (1) latency hiding (2) world model and (3) combat system. The issues ofcourse are fairness (which includes security) , verismilitude, and fun.

It could also be “start/end” commands. Server sends notification when someone starts doing something, and then another notification when the action is changed/finished. It will reduce number of redundant packets to minimum.