Server sided movement

[Ralph]

Sup guys,

I'm back and once again working on my side project now that school is out. I recently rewrote some of my server sided code, specifically the pieces that handle anti-cheat.

One problem I ran into is my anti speed hack mechanism. Prior to my rewrite (which was more of a cleanup) the way I handled movement on the server was I allowed the client to move however it liked. It would then send its new position (after ever frame) to the server. The server would then check to see how far the client moved (based on its last position which is saved on the server) and made sure that the client didn't move more than a certain amount of pixels each frame. If it moved legally, then it's "last" position would be updated with the new position the client provided and the client legitimately moved. If it moved too fast, the clients old position is kept as its server position, ensuring that sure the client isn't speed hacking (at least on the server side, can't stop the client from moving anywhere really).

Anyway, that's how the system works, and it works great, until I ran into the problem of different frame rates (at least I think that's what's causing the issue). After the rewrite of this system, clients are moving too fast to the server, and I think it could be because of slower fps'? Like Ill move right, but now instead of moving say 5 pixels per frame like the pre-rewrite code would detect, im getting 6, and 8 and 15 and other higher random numbers, as if the server was missing some calls. 

Regardless of the cause, I was wondering, how do people usually handle movement on servers. Am I going about this correctly? Any suggestions? What other ways can I verify a player isn't teleportating or speed hacking? 

Thanks.

[Skeptron]

I'm sorry to say you are quite wrong in your thinking.

First of all, you should try to make your game more deterministic and not rely on FPS. Players should not move of X pixels each update but of X pixels each second. So a player with 30 FPS will move just as fast as a player with 60 FPS. 

Then, if you really plan on preventing hack, your server should be completely authoritative, and not just a 'checking' tool. So the players should only send the keys they press, not their coordinates or speed or HP or anything. The server would then decide of whether the execution of such keys is legal or not, and calculate their result, and send it back to the clients. This way, no client could ever cheat. 

And of course, the server would be aware of speed bonuses, so that its velocity calculations would be accurate at any time.

[Ralph]

Just now, Skeptron said:

I'm sorry to say you are quite wrong in your thinking.

First of all, you should try to make your game more deterministic and not rely on FPS. Players should not move of X pixels each update but of X pixels each second. So a player with 30 FPS will move just as fast as a player with 60 FPS. 

Then, if you really plan on preventing hack, your server should be completely authoritative, and not just a 'checking' tool. So the players should only send the keys they press, not their coordinates or speed or HP or anything. The server would then decide of whether the execution of such keys is legal or not, and calculate their result, and send it back to the clients. This way, no client could ever cheat. 

And of course, the server would be aware of speed bonuses, so that its velocity calculations would be accurate at any time.

The reason I went with a monitoring approach over a fully server handled movement system is that i could never drop the lag. The movement lag from the server handling movement was too annoying for me, and I couldn't reduce it by much. 

The server does monitor by update, not by FPS, but currently the client doesn't move by update, it moves by frames, if that makes sense? So the server is calculating distance based on updates, but the clients move based on frames. An easy fix I just haven't gotten around to (I just need to make speed the client moves at proportional with their FPS).

To be honest, after I wrote this post, I found the real issue that was causing this movement bug, it was unrelated, but this is still something I know I will have to deal with in the future.

So your recommendation is to fully switch to a server sided movement system?

[Nesh108]

9 hours ago, Ralph said:

So your recommendation is to fully switch to a server sided movement system?

The way it is normally done, you have the client do the job as well as the server. If you have any major inconsistency, you force the player back to the position the server expects.

In this way, you can hide latency and allow a much smoother movement. The server intervenes only when someone actually cheated or lagged for too long. You obviously don't want to wait to hit the server an come back before the player can actually move around.

[Antriel]

I would direct your attention to the list of resources I mentioned in this other topic.

You want to implement client-side prediction. I recommend starting with the series by Gabriel Gambetta for bird's eye view of how it works in general.

Also I started a multiplayer platformer project and wrote about how I implement client-side prediction. You can read it here:
https://antriel.com/post/online-platformer-3/

[Ralph]

2 hours ago, Nesh108 said:

The way it is normally done, you have the client do the job as well as the server. If you have any major inconsistency, you force the player back to the position the server expects.

In this way, you can hide latency and allow a much smoother movement. The server intervenes only when someone actually cheated or lagged for too long. You obviously don't want to wait to hit the server an come back before the player can actually move around.

So this is basically what I have right now. The server is essentially fully handling the movement, but the client just assumes all moves are legal to remove the need for the server to send back to the client what it needs to do. 

[Antriel]

The server sends back where he thinks the client should be, and client then takes that and performs reconciliation.
Example:

• Client sends 3 "move right" commands, while executing them right away.
• Server sends back confirmation, "you are at x:3 after 3 commands".
• Client meanwhile executes 2 more "more right" commands, before it receives the confirmation.
• Client then takes the server confirmed position (x:3) and re-executes the commands that weren't yet confirmed.

Basically, the client corrects itself to where server thinks the client should be. But the correction is in the past, so client has to reapply commands to move to the current time.
The articles I linked explain this quite well.

[Skeptron]

There are lots of ways of doing such robust, anti-hack implementation, and the guys here mentionnend some absolutely brillant articles, but they all require a lot of time. Like a LOT. And skills, of course.

So you really have to ask yourself : how important is it for my game to be hack-proof? Because switching for a simple broadcast server to a hack-proof server is a huge step. I can never stress that enough. I am myself implementing a competitive, real-time action-paced game with Phaser, that I hope I can show you guys soon, so trust me when I say it's a lot of work. It's been months of testing various implementations, fixing the engine, rewriting almost everything because of a new character ability that breaks everything etc.

So if you don't really care about cheaters, you can remove all of this and simply broadcast, or perhaps go with your simple implementation to avoid big inconsistencies. Otherwise you should focus on gameplay and content. That's much more rewarding and players who have a good connection will be thankful for that (in the end noone will praise you and buy your game because the network handling is excellent. Noone cares. Focus on what's essential : that is, the gameplay).