In a multiplayer game, should everything that is not user input be done server-side to prevent cheating?

Question

I've heard this said before, but it seems somewhat unrealistic.

These are the two scenarios I'm working with:

User Presses move key, moves themselves, and tells the server -> server tells other clients

or

User presses move key, and tells the server -> server calculates if the user is allowed to move there -> server tells all clients

It seems like option one would make the users movements feel very floaty and delayed. Do most multiplayer games use a combination? (user moves itself, gets confirmation from the server, and moves itself back if it was an illegal move.) Maybe it's a non-issue and I'm overthinking it.

Answer 1

This is a very valid question, and the answers will probably differ between developers, as many will choose different approaches to secure the integrity of their games. The choice which implementation is eventually chosen will be impacted by numerous factors, e.g. how responsive the game needs to be, how much other information is being sent over the network already, how frequently user input is actually expected, and so on.

Your general considerations are two valid approaches, of which the first is probably more responsive but also more prone to abuse. The latter is technically the other extreme on the scale, providing the most security, but with the obvious potential to slow down the game significantly, if a lot of user interactions are to be expected.

One well-known hybrid model is using a similar approach to the one you also sketched out following your two proposed scenarios, that is based on implicit confirmation. Clients send all user actions to the sever, and periodically send their (full) world-state representation as well. Clients only receive periodic world-state updates and otherwise interpolate from previously received world states locally. The server is the authority on the world state (as it is the only place where all input information lands), and will check the periodically submitted world states for deviations/manipulations and the submitted user inputs for plausibility in general.

Note that in this approach there will usually be certain divergences between the clients' world states and the true world state (due to the interpolation nature of the client update), which necessitates the server-side updates of the world state to be issued on about a per-frame basis. Of course, numerous variations of this approach exist as well, depending on the requirements of the game.

Answer 2

I can't speak for other developers or games, but if I were in charge of security I would use a dictonary of moves or actions that are allowed in an online game or match. If a user somehow violates this dictonatlry, a flagging system should follow suit (just to be fair and certain), if say an illegal action is performed a certain ammount of times and/or within a pre-determined time period to ban or remove them from the game.

This way, you can use a standard player-registration system that won't be detremental to the game's performance. However, this may or may not work for your game. One thing that would be very important to remember is the likelyhood of a player (accadentaly or not) breaking your game's rules. The last thing you want is players being unfairly banned or removed from games due to a system like this because it does not bode well with the game in question. This is really a subjective matter that should be thought through very thuroughly before it's implementation is finialized.

Answer 3

user moves it self, gets confirmation from the server, and moves it self back if it was an illegal move.

Yes, that's usually what you do. But snapbacks usually only happen when the server position diverges a lot from the client position. Small inconsistencies will always happen due to network latency. They usually don't affect the game and can be compensated over time. Large inconsistencies which warrant to teleport the player to a different location are usually a result of either a long network lag, a bug, or an attempt to cheat.