next »

[Robotacon]

Do you use anti-cheating code in your multi-player game?
Got any tricks of the trade to identify cheaters?

I've gotten the advice to make the clients as thin as possible and calculate hits and movement on the server. This feels like it will increase lag so I'd rather have a mechanism to identify cheaters if for any strange reason there will ever be any.

[Cthulhu32]

If you are going to research this a lot more, I HIGHLY suggest checking out Greg Hoglund's book, "Exploiting Online Games." http://www.amazon.com/Exploiting-Online-Games-Distributed-Addison-Wesley/dp/0132271915  He goes into great detail about how bots work, how to hack dlls and memory pointers, and how to generally totally screw an unsecure game. It should give you some really good pointers on where to improve server/client communications, and how to deal with cheaters that use subtle techniques (like slowly ticking their money forward every minute, or using memory glitches like the WoW force-sit glitch to kill other players in PvP)

[mewse]

Do you use anti-cheating code in your multi-player game?
Got any tricks of the trade to identify cheaters?

I've gotten the advice to make the clients as thin as possible and calculate hits and movement on the server. This feels like it will increase lag so I'd rather have a mechanism to identify cheaters if for any strange reason there will ever be any.

You definitely want to calculate hits and movement on the server.

That doesn't mean you can't also calculate them on the clients, to avoid lag.  The point is that the server is authoritative;  so if the client and server disagree about what happened, the server wins.  (But if you write the code correctly, this should be an unusual occurrence)  Best online reference I've found for how to implement this sort of system is this discussion about how it's done in Unreal.   Scroll down to the "Player Prediction" section.

[bateleur]

I'm in no sense an expert on this subject, but I've been thinking about it recently for a multiplayer project I'm working on (not my main project, just a little toy thing). It occurs to me that it should be possible to put basic anti-cheat protection in without running the game engine on the server for any game involving at least three players. It would work something like this:

* For each frame, collect actions from all players (that is, only the processed data from their UI).
* Send the actions to all clients.
* Each client runs the game engine separately.
* Each client then calculates a game state checksum (or to be more precise, this should be kept up to date continuously).
* Clients then send the checksum back to the server.
* Checksum reports are broadcast to other clients.

This approach has two advantages:

1) Because only UI actions are sent, any kind of cheat which involves doing impossible things in the game world is blocked.
2) In the unlikely event that clients do diverge in their model of the game world, this is detected instantly and cannot be exploited.

Note that it doesn't block all cheats, since stuff like macros to make you do things beyond mortal dexterity are still possible! Also, if clients communicate things like win/loss stats to the server you need to decide what the handling protocol is if the clients in a game disagree over the result. (Taking a simple majority is no good if players can populate their games non-randomly.)

[Core Xii]

Because only UI actions are sent

In a fast-paced game that's not feasible. Imagine having a 50-100 ms lag between pressing a key and your character moving in an FPS for example.

mewse has it pretty much there. You should calculate everything that's not a binary event on the client, but correct any mistakes from the server.

By binary event I mean events that have two possible outcomes, like dying. Either the shot hit you and you died or it didn't and you didn't die... Don't try to predict things like that client-side, just wait for server confirmation.

To prevent wallhacks and aimbots, only send data to the client the client can actually see. Take Counter-Strike for instance: The position of all players is transmitted to all clients even though they can't see them... Then a cheat makes this information visible to the player by digging it up from the game's memory.

[bateleur]

In a fast-paced game that's not feasible. Imagine having a 50-100 ms lag between pressing a key and your character moving in an FPS for example.

That would indeed be completely unacceptable, but it's a red herring since your own inputs arrive instantly.

(It may not be ideal for an FPS for other reasons, but I am using it for real-time gameplay and it's working fine.)

[Robotacon]

I forgot to say that I'm making a team based 2D platformer. I'm not really afraid that anyone will want to be cheating but you never know.

My plan before posting was to let every player calculate their own movement so that there is no lag between key pressing and visual updates and then send that movement data to the server that decides on what other players needs it. Then I was thinking I'll track movement over time and shut down anyone that moves longer than possible or if anyone has moved through a wall.

Bullets are spawned by the player shooting and then the source coordinates are sent to each client that spawns their own ghost of the bullet and the rest of the movement for that bullet is deterministic and won't be transmitted.

While map collisions will be calculated on the client all object collisions will be calculated on the server and transmitted to the players involved.

I'm going to have a map that can be updated by the players but possible those updates can be updated until the players is close enough so that no one can monitor changes in the map to pin-point where other players are.

Sending keystrokes and letting the server use that to either calculate or validate the movement sounds pretty straight forward. I don't know why I'm against sending keystrokes, it just feels so brute force-ish but I guess that's the route to go.

Bots on the client side on the other hand I have no idea of how to deal with but if someone actually would create a bot that played my game I'd accept that as legal. You shouldn't discriminate against robots. They will rule the world one day and I don't want to be singled out as one of the trouble-makers.

[Zaphos]

I forgot to say that I'm making a team based 2D platformer. I'm not really afraid that anyone will want to be cheating but you never know.

Do you mean it is co-op only, or are there multiple teams which compete?

[Robotacon]

I forgot to say that I'm making a team based 2D platformer. I'm not really afraid that anyone will want to be cheating but you never know.

Do you mean it is co-op only, or are there multiple teams which compete?

Currently two teams of several players that compete with each other with a focus on teamwork.
Being a solo developer I don't believe in planing too far ahead so the vision won't outgrow me.

[Ivan]

There is really only one solid solution and is the one pioneered by Quake and used in most commercial multiplayer games, which is: Do all cheatable stuff on the server and then account for the lag that creates on the client side. This includes collisions, damage modelling, movement, etc. In quakelike engines, the client is basically just a dummy renderer for what is happening on the server that accounts for lag and does some local simulation to make sure that things don't look choppy when you're receiving data only 10 times a second.

Here's a great article that outlines how multiplayer networking works in the Source engine, and is a pretty good model to base your own code on:

http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Of course, there are other client-side cheating issues like disabling certain graphical features (like wallhacking in Coutnerstrike) or automating input (like autoaim bots), which you can't solve 100% no matter how hard you try. That's why there is still ample cheating going on in Valve's games even though, I'm sure they spent a lot of time thinking about this problem. The only way to solve this is to run some sort of clientside validation (like PunkBuster or Valve's VAC system) that will monitor the local computer and check for known hacks. But that's really a completely different problem.