Consensus-Based Cheat Detection for Multiplayer Games
Because making multiplayer games is hard
Last time I wrote about running an On-Demand Game Server Architecture on AWS for multiplayer games. Usually you need to roll your own game server if you want to mitigate cheating as much as possible; your game clients would need to act as dumb input machines and your server would evaluate every single movement and catch cheaters as necessary.
But what if you don’t want to deal with the hassle of setting up your own game servers? It’s quite the endeavor after all, with a bunch of pitfalls, unexpected issues and costs that require a specific expertise to solve.
When I think about game moderation in real life, generally speaking I think of two distinct ways of doing so:
- There’s a dedicated referee who watches everything (i.e. authoritative game server)
- Players in the game watch out for rule breakers and call them out; then they decide what the outcome should be (i.e. consensus-based cheat detection)
Both approaches have their pros and cons and while they aim to solve the same problem, they require very different circumstances to work with.
When does consensus work?
Some examples of game types where it might be good:
- Cooperative games with at least 4 players
- Free for all games with at least 4 players
- Team games with at least 6 players where player parties can’t exceed 2 players (think League Of Legends Duo Queue)
When does consensus fail?
Typically this engine fails if there are enough clients connected to the game who are actually cheaters — usually referred to as 51% attack. It can happen that a game has multiple cheaters running around, rendering the consensus flawed — they might not evaluate consensus or just evaluate moves incorrectly
If that’s the case, the following scenarios might happen:
- Cheaters don’t get recognized and so they stay in the game
- Cheaters actually boot legit players (though I don’t know why they would do this)
How does this work?
I’ve built a prototype to demonstrate the usage of a cheat detection system like this. Mind you, this is not production ready code, it’s just a demo.
The whole thing starts with the Cheat Detection engine. Every client needs to run this engine to be eligible to play the game. If a client fails to initialize the engine within the configured timeout period, they are automatically considered cheaters. This could happen if someone hacks the client and removes the engine from it. Now, of course, they might still just send the signal to the others saying “hey I’ve registered” without actually initializing the engine, but that’s fine. It’s just the first layer of defense.
There are many configuration options for the engine, but probably the most notable one is the rules parameter. This is where we define the rules of the game. We do this by mapping Moves to Rules.
A Move defines an event that is important from the game’s perspective. Technically this could be anything from moving the player character, to attacking, to picking up objects, etc. Any action that’s important for the game should be declared a Move.
A Rule defines how a certain move should be evaluated. Typically this will resolve to a bool value indicating if the movement was allowed or not.
Once every client has initialized and is running its own cheat detection engine, the clients need to subscribe to other players’ moves and forward them to the engine. Each client will then start evaluating every other clients’ Moves against the configured Rules. When a client evaluates a Move as invalid, they will cast a vote and let the other clients know.
If enough (by default more than 50% of the) players deem an action as cheating, all clients will then unsubscribe from any other move from the cheater, essentially shadow banning them from the game. While the player might still be technically connected to the game, everyone is just going to ignore their actions from that point on.
If the game has a “leader” or “room owner” who has the ability to boot the cheater, this would be the time to do that.
An example of the engine configuration can be found in this Virtual Client.
The following screenshot shows an example where there are 5 players and one of them (Player 5) is a cheater. All the other players recognize that Player 5 attempted to move more than the game allows so they all unsubscribe from further events coming from Player 5.
So what’s next?
I’m toying with the idea of writing a Unity compatible library that can be integrated with Photon cloud. I think that could be cool.
If you’re interested in collaborating or just want to roll your own solution, feel free to use any of the code provided in the linked example as your starting point. I wouldn’t recommend just copy-pasting it as it was never intended for production use.
If you enjoy reading about content like this, please consider dropping a follow to get notified about future posts.
