I'm working on an online Web RPG game (jRPG) with a map, that characters can go around. Also, an important part, is that each player has his own world and each player can invite his friends to play on the map together.

Almost any action can be processed by a dedicated server as well, except for the character's movement/animations, because the server is written over WebSockets, that are using TCP under the hood.

Actually, those actions can be processed with an overhead of package reliability.

But I thought, what If I create a peer for each player and use it in combination with an authoritative server? And then, in a case, if one player invites the second player to play together, then the second payer just connects to the first one using p2p technology.

But at the same time, each action, like setting a new prop on a map or opening a chest with a reward (that can be hidden in the forest) is processed by a dedicated server (through the WebSockets)

So, the purpose of p2p here is to transmit not reliable(or too frequent) data, such as user's movements(position)/animations/etc. Also, my opinion is that will work great for hubs (some locations, where 16-32 random players can meet each other, like in No Man's sky)

All looks perfect, except for one thing:

I want players to be able to move over the map(want to WASD), but not to be able to move through the objects (e.g. wallhack) So, if players enter a dungeon, I want to be sure, that they solve a dungeon, but not finished it by moving through the walls.

There is another problem similar to prev: Not allowing fast map exploration (e.g. speed hack)

Is there any way to handle this issue without processing player movements(and other frequent unreliable data) on the main server for each update tick?

I know that p2p is for players that love to cheat as well, but in that case, I have an additional Authorative server that can approve/reject a lot, I just do not want to make all the stuff laggy on the main server (if there will be a lot of messages per update)

Btw. positions are only used by the player(dungeons, map exploration) or the group of players that play together, it's NOT an MMO, where thousands of players can see each other. As for me, it's useless to update the player each frame or to make the game a real MMO, so there will be a sense to update all the positions on the main server.

P.S. I know, If there will be no WASD, but mouse clicks then the movement path can be built using the main server. In this case, p2p will work as expected. But I really want to use a joystick on mobile devices to move around.

  • \$\begingroup\$ "Is it possible" -> what law of physics do you worry would make this "impossible"? If you just want help solving the problem, ask "how" not "if". It's unclear to me why you believe analog movements can't be verified by an authoritative server. Fast-paced shooter games do this all the time. If it's the time latency of TCP rather than UDP, would it not suffice to batch up sequences of movements and let the server mark cheaters asynchronously? \$\endgroup\$
    – DMGregory
    Oct 26, 2022 at 16:14
  • \$\begingroup\$ @DMGregory, sorry, changed the title. By batching up sequences of movements - do you mean to send all the movements through the p2p, but at the same time send the same data (but grouped) on the main server? Then it probably doubles the data size that is sent through the wire from the player. In this case, it's easier to send positions directly to the main server (without p2p), but to battle with the latency of WebSockets(+packages overhead) Then it will get down the maximum amount of users that can play smoothly. In other words, it will increase main server machine requirements. \$\endgroup\$ Oct 26, 2022 at 16:28
  • \$\begingroup\$ Yes, adding extra requirements to your game tends to come with costs to fulfill those requirements. There's no such thing as a free lunch. But this is something games have been doing successfully for decades, even when networks/servers were vastly weaker than today. Continuous position changes tend to be very predictable and thus compressible, so the additional network overhead here should be quite small - especially if you only care about relatively coarse-grained collision checks or path validation. Have you done any math/profiling to prove this creates an unsustainable overhead? \$\endgroup\$
    – DMGregory
    Oct 26, 2022 at 16:40
  • \$\begingroup\$ Hmm, probably I should perform a few tests to compare, thanks. \$\endgroup\$ Oct 26, 2022 at 17:19

1 Answer 1


You should really go with an authoritative server in this case. Web sockets do not allow peer-to-peer connections. So you are going to need a relay server anyway. When you need a relay server anyway, you can just as well turn it into an authoritative server.

But if an authoritative server would indeed be too expensive for you, then you could as a compromise use a server which just acts as a relay, but does occasional plausibility checks. Like keeping a journal of player positions with timestamps and verify that they are not further away from each other than it should be physically possible for the player.

If you want to catch cheaters, then it might not even be necessary to verify every action. A cheater isn't going to cheat only once. They are going to cheat all the time. So you just need to pick a random sample of actions that get verified by the server. This also doesn't need to delay the execution of those messages. You can just do that on a separate thread while the game continues. When too many actions of the player get flagged as implausible, that player gets banned for cheating. But be aware of false positives. Especially when it comes to movement and pathfinding. Latency and jitter mean that the players and the server never see the exact same gameplay state. So it is not uncommon for them to occasionally disagree about what is and isn't possible.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .