Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (764)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (852)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Interpolating tile based movement with speed variable.  (Read 3434 times)
0 Members and 1 Guest are viewing this topic.
Offline unenergizer

Junior Devvie


Medals: 3
Exp: 5 years


Work hard, practice often, and you will succeed!


« Posted 2018-02-06 06:31:46 »

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.

<a href="http://www.youtube.com/v/vhtn-9K0aCw?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/vhtn-9K0aCw?version=3&amp;hl=en_US&amp;start=</a>

JGO is AMAZING!
Steam: unenergizer
Offline VaTTeRGeR
« Reply #1 - Posted 2018-02-06 10:03:20 »

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!
Offline bmanmcfly
« Reply #2 - Posted 2018-02-06 21:14:32 »

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!

Never really worked in multiplayer stuff, But I would have thought that interpolation like that would cause problems because of ping time and stuff?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline VaTTeRGeR
« Reply #3 - Posted 2018-02-06 22:11:03 »

Quote
I would have thought that interpolation like that would cause problems because of ping time and stuff?
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.
Offline bmanmcfly
« Reply #4 - Posted 2018-02-07 03:43:43 »

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. 
Offline unenergizer

Junior Devvie


Medals: 3
Exp: 5 years


Work hard, practice often, and you will succeed!


« Reply #5 - Posted 2018-02-08 13:22:56 »

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!

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?

JGO is AMAZING!
Steam: unenergizer
Offline VaTTeRGeR
« Reply #6 - Posted 2018-02-08 16:02:52 »

Quote
libGDX will often have +/- 100 ms (max) per loop
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 Tongue

Quote
get the clock times [...] bit more harder to speed hack
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
You will prevent exactly ... nothing Cheesy 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 f**ked 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.
Offline unenergizer

Junior Devvie


Medals: 3
Exp: 5 years


Work hard, practice often, and you will succeed!


« Reply #7 - Posted 2018-02-10 13:30:27 »

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.

JGO is AMAZING!
Steam: unenergizer
Offline VaTTeRGeR
« Reply #8 - Posted 2018-02-10 13:55:11 »

Sounds to me like it's working Cheesy

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

I don't know what else to recommend.
Pages: [1]
  ignore  |  Print  
 
 

 
EgonOlsen (591 views)
2018-06-10 19:43:48

EgonOlsen (694 views)
2018-06-10 19:43:44

EgonOlsen (478 views)
2018-06-10 19:43:20

DesertCoockie (831 views)
2018-05-13 18:23:11

nelsongames (1026 views)
2018-04-24 18:15:36

nelsongames (1083 views)
2018-04-24 18:14:32

ivj94 (1664 views)
2018-03-24 14:47:39

ivj94 (590 views)
2018-03-24 14:46:31

ivj94 (1501 views)
2018-03-24 14:43:53

Solater (568 views)
2018-03-17 05:04:08
Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46

Deployment and Packaging
by philfrei
2018-08-19 23:53:08

Deployment and Packaging
by philfrei
2018-08-19 23:50:04

Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!