Interpolating tile based movement with speed variable.

Networking & Multiplayer
#1

Hello!

I have been creating a small multiplayer game. The game uses 2D Tile maps and libGDX. I am wanting to interpolate the movement of entities between tiles while also allowing for different movement/running speeds. I am not a math guru by no means so I am a bit lost. The networking works fine, the grid movement is implemented server side. However, on the client, the player jumps around between tiles and isn’t the prettiest thing to see.

The effect I am going for is something similar to Runesapes movement, however in only 4 cardinal directions. I am not exactly asking for code, but more or less to be pointed in the right direction. I also want to prevent the client from using speed hacks so it would be nice to have some sort of timing implementation on the server to say when it will start accepting move packets again.

Here is a game play video of an effect I am trying to emulate.

vhtn-9K0aCw

#2

You could let the client do it’s own thing but the server simulates in parallel and corrects the clients movement with some delay.
You would need to save an history of movements on the client that can be gradually corrected with the data from the server.

The essence is:
1.Client simulates movement and sends movement commands to the server
2.Server simulates movement based on commands and sends back position of player
3.Client corrects his past (two times RTT ago) prediction with the position received from the server

It’s explained better in the article with graphics and stuff, check it out!

http://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html

The article also touches interpolation!

This is also useful to know:
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

The server should NEVER accept position data from the client, only commands, like button XYZ pressed or action ABC requested. And then the server should still do sanity checks, it should NEVER just execute or your players WILL eventually cheat!

#3

Never really worked in multiplayer stuff, But I would have thought that interpolation like that would cause problems because of ping time and stuff?

#4

[quote]I would have thought that interpolation like that would cause problems because of ping time and stuff?
[/quote]
WHICH problems, can you be more specific?

Interpolation always causes additional delays proportional to your update rate, that’s just the way it works.
You get consistent smooth motion for slightly increased latency, that’s usually a good trade off.

#5

I was thinking more chance that there would be jittery motion…

But based on your answer that’s a non issue. If/whenever I get to that point I’ll concern myself more with it… Was more of a side question to the OP.

But you covered the concern I was thinking of, and the averaging out of the client/ server positions.

I have a hard enough time with simpler issues atm.

#6

Thank you for posting those links. After reading both of those documents, I have a very understandable idea on how to achieve the effect I am going for. Now its just time to try and implement that. Since were on the subject, do you have any documentation on syncing clock/time differences with the client/server?

My server code runs almost perfectly at 20 ticks per second while libGDX runs at 60 fps. However, libGDX will often have +/- 100 ms (max) per loop. I know that is very game dependent, but if I can get the clock times of the machine I believe it will help me create something a bit more harder to speed hack. This way I can prevent move requests from the client if they haven’t waited the “correct” amount of time.

Your thoughts?

#7

[quote]libGDX will often have +/- 100 ms (max) per loop
[/quote]
There’s something very seriously wrong with your game if this happens “often” even after playing for a while.
100ms are 6 whole frames at 60fps :stuck_out_tongue:

[quote]get the clock times […] bit more harder to speed hack
[/quote]
tf2_engineer_says_nope.avi

nothing you do on the client prevents cheating.
Everything you do on the client will eventually get dissected, bugged/glitched out and pissed on.
Everything that matters gameplay-wise MUST (also) be simulated on the server if you really want to stop cheaters.

[quote]prevent move requests from the client
[/quote]
You will prevent exactly … nothing :smiley: if the counter-measure is on the client-side, some user will hack it and you can’t do shit about it!

Let’s say you write the “perfect” client with butter smooth packet send times, you release it to the public and some user with a fucked up network plays your game and nothing works anymore because you rely on the packets coming in at certain times and rates.

Look at all the complicated DRM that AAA studios use to prevent people from making cracks for their games, even that doesn’t hold up long because in the end all that code runs on an insecure machine aka client, the more interest the more hacks are getting written.

This means that your server also needs to simulate what the client does so that there’s one secure game-state that every client can agree on.

If the client spams the server it should never just execute the additional commands, it should just do what’s allowed/possible and kick any badly misbehaving player.
You can’t really call it commands either, request is a better word, the user just requests that something should be done, but there is no authority in these requests unless you want to let other users feel the pride and accomplishment of being killed across the map by d1ngd0ngFaceMCgregger2019.

#8

I completely agree that the game logic should be handled server side. My reason for asking about a time sync is mainly for the purpose of keeping the client from sending extra packets. The server man receive them but won’t process them unless X amount of time has passed. The server already rejects of extras are sent.

Here is the logic that I have come up with based on the articles you mentioned.

  1. Client wants to move.
  2. Beginning walking animation to next time.
  3. Sending packet move request.
  4. Rejects any move request packets between tiles.
  5. And fractional before the player reaches the destination time accept a move request packet so player can continue moving and the animation keeps going looking like continuous walking.
  6. When the move request is received by the server check Collins and if collided, snap player back to previous time.

If you can improve on that please let me know. We have multiplayer moment but as you go from one time to another their is a small stutter because the client previously had to wait for the server to reply with accepted or rejected move information. So based on the article, we will continue to let them move and while they are bet6tiles we will wait for the reply. If something isn’t right, we snap them back. To better this we are doing collision checks on both the client and the server. Previously we only checked on the server.

Thanks. And this was typed in my phone so sorry if their are any mistakes.

#9

Sounds to me like it’s working :smiley:

Have you tested it with artificially worsened conditions like increased packet loss, jitter and latency?

I don’t know what else to recommend.