How do you usually handle game state for online multiplayer games to avoid cheating? My background isn't on making games, but knowing more about this domain is something I'm curious about
I'm guessing you can use timestamp by having PlayerA and PlayerB send udp packets, but wouldn't that cause latency, even if you put the instance region zones close enough to both players? How about direct socket connection between PlayerA and PlayerB and sending some results to the backend, but how do you prevent cheating on the client side then?
This is a deep topic, and people write entire thesis papers on this topic. This is/was a major performance issue in Star Citizen for years.
Because cheating tends to be an outlier activity, some companies choose to invest more in identifying cheaters after the fact using pattern recognition and machine learning tools rather than outright prevention. Depends on if your game inherently resets between game loops (i.e. battle royale, deathmatch, MOBA, etc), or if you have a continuous persistent state that has to be kept stable (i.e. MMORPG).
Full security means validating every activity with a fully trusted server before broadcasting to other players. Full performance basically means full client trust, whatever the implementation ends up looking like.
There's a whole spectrum of solutions somewhere in the middle for most games.
It also completely depends on what kind of multiplayer game it is. If you're doing a simple turn-based card game, obviously you can run the entire game on the server, and have the clients just do input and display of the game state. If you're doing a fast-paced first-person-shooter, you need to run more logic on each game client and trust them more. Add a real-time physics engine and it gets even trickier, because now you need to make sure it's deterministic regardless of client hardware.
If you can solve the latter problem in a general way, you can easily build a company around it. There's already a bunch that do nothing but this. It's just a fundamentally hard problem because the speed of light is what it is, the distribution of computing hardware is what it is, and the distribution of players is what it is.
Depends on the game/cheat we are talking about really.
Some cheaters try to fool server/other clients. For example in a game of chess, a client can try to move his pawn like a queen. In this case a server would run the "game simulation" it self and would detect that the client is making an illegal move and a cheater. But this is not always possible/feasible. In an mmo for example it may not be feasible to run physics simulations on server and maybe a server can trust clients when they say "I moved from my old point A to new point B" but in reality there may be a wall in between point A and B
Not all cheats are about fooling the server. Some runs on entirely on cheater's side. A board game example would be battleships. A cheater can decide to "look" other side of the board and cheat by looking at opponent's ships. This kind of cheats are solved by only sharing necessary information with clients. For battleships, this would be server only responding the bombing coordinates a client sends and the answer would be a simple "hit/miss". Again, this is not always practical. In a game like counter strike, ideally you would share enemy positions only when they should be visible on someone's screen. But due to lag or not being able to detect this visibility information, a server can choose to always share this information and clients can cheat by presenting that information
A harder to catch cheat would be aim hack. In this case a cheater neither fooling the server or benefiting of an information it doesn't have. They usually catch these by checking programs that does this or via player reports or automated systems that catches players that are too good to be legit.
Any sensitive data (i.e. things you can cheat with) is generally server-authoritative. There are lots of tricks you can use for predicting/interpolating data to make up for the latency created by going from client -> server -> client
Edit: As cheschire said, it entirely depends on the type of game and what kind of actions the player is performing
Like with any Risk, the actions are: Prevent, Detect, Correct (and least used Transfer).
Rule of thumb that is used in banking, 'sanity check'. Cheap and effective way to see if the gains-number (e.g. xp/coin gain) is making sense. If a top player can make 100k per hour and you get a newbie making 500k/h, you better start reading logs/snooping. The value of equip when a player saves & exits would not be x100000 from the previous time he/she saved and exited (and other similar metrics).
It is an ongoing process to make and maintain a useful dashboard. Also (I've seen it happening in some MUDs), you start snooping random players at times (preferably ones with massive gains) and see what is what.
Imho the cheapest way is to detect and correct, not prevent cheating. Unless you have an army of devs scouring the internet looking for cheating solutions that can work out preventative methods.
The important two points are that the client must react immediately to a user's input, but at the same time the server has to have the authoritative game state.
One way of doing that is that the server runs the authoritative simulation and the clients send input to the server, but the clients also run their own simulations. In some games the client will try to predict what the server will do. If there's a conflict with what the client simulates compared to the server then the client gets rolled back to the server's state. This usually happens when there's a second player that interferes in some way.
I remember in World of Warcraft, your internet connection could drop completely and you wouldn't notice until you realized you hadn't seen mobs or another player for a while.
World of Warcraft is not fully server authoritative. There have been speedhacks going on. Also, an entire guild was banned once because they modified the client-side model files to remove the stairs in the dungeon, allowing them to fall down the pit and skip most of the dungeon.
I found this out recently when playing wow classic I somehow fell out of the sky, and survived when on a computer "controlled" Griffin, if I had any control of the bug I could use it to drop off in more convenient locations
I had that too, if taking the flight path from Goldshire to Stormwind and my game crashed/disconnected, I often found my character next to Stormwind gates.
While it's mostly about ensuring both clients have a smooth experience and how to achieve that (prediction, rollback, etc) many of the same techniques apply to cheat prevention - have the client "echo" or predict what it thinks will happen, but have the source of truth be the server. "Desync" is a common term for what happens when they disagree, the server keeps its version of events and kills the client connection. In peer-to-peer or direct connection games, one player is the server and this does present a problem, but keeping it random will reveal statistical irregularities.
In general, how it works depends on the cheat. You cannot stop someone running a program to automatically aim and shoot at enemies. The enemy data is in memory so pinpoint accuracy is simple to achieve. Usually, statistical analysis, recording, allowing an admin to view their screen, and other methods can be used. Often, anti-cheat software is installed to scan for known cheats or by using heuristics (much like anti-virus software). This is a bit of a hot topic right now as a recent game tried to install such a program in Ring 0 (lowest level device driver) in Windows, which runs at startup even if the game isn't running, and won't automatically uninstall. Some people reported it stopped their PC booting.
For informational cheats (such as seeing players through walls) that data is also in memory and is harder to detect if the player doesn't make any illogical plays taking advantage of it. You might ask why the client has player position data for people you can't see? That again depends, but IIRC in at least one case a game tried to suppress the information until just before they became visible but the cheaters realised that the game had to generate sound (footsteps) for the players and reverse engineered the directional sound back into positions.
In other cases, passing network data through a proxy defeats local anti-cheat. Packet scanning and direct injection can be used for superhuman speed (such as claiming unique monsters in an MMO before anyone else can).
In general, stopping cheats is largely impossible, it's more about how to catch them and policies to handle the fallout e.g. If I cheat and earn a bunch of ingame money then trade it to you, should you lose it? How do we know you're not an accomplice?
I'm guessing you can use timestamp by having PlayerA and PlayerB send udp packets, but wouldn't that cause latency, even if you put the instance region zones close enough to both players? How about direct socket connection between PlayerA and PlayerB and sending some results to the backend, but how do you prevent cheating on the client side then?