Hacking & Cheating Protection

Any game is vulnerable to cheating. Quite often, when you block one hack, some other will be invented and you have to act again.

Running all logic on the server sounds like the solution but is expensive and it's not a guarantee cheating is impossible.

Protection Options

There are more or less four approaches to cheat protection:

• Pure client side.
• Client side with cheater reporting and banning via a backend.
• Server side analysis of a running game.
• Full server side authority.

Each option is increasingly effective but also more expensive as you have to run more logic and systems on the server side.

Typically, we suggest variant two: Make all clients check for cheats and report those. Ban/block users from your game, who have been reported too many times (and those who report hackers too many times, too).

This means you quite effectively get rid of cheaters and can ruin their progress. That should be somewhat demotivating (but not entirely so).

You will need to identify users with some account or per device. Also, you will need to store and evaluate reports with some backend service like player.io, Playfab, Steam or other. Last but not least, you have to setup your Photon game to require Authentication to access the server.

Client Side

PUN and Unity

PUN is a pure client-side implementation without server logic, so it's economic but of course it's not cheat proof.
For some games that's OK, for competitive games, it may be not.

Unity builds are quite hackable unless you use IL2CPP and take a few extra steps on the client side to make sure your clients are somewhat hack proof.

Have a look at the Anti-Cheat tools from the Asset Store. The Anti Cheat Toolkit is just one example.

Check out also tips like these: A practical tutorial to hack (and protect) Unity games.

Photon Bolt

Bolt has some built-in features to make cheating less likely overall, even without a server. It defines the state and all messages, which makes it less likely arbitrary info can be injected.

Any client which is hosting a Bolt game, can be made authoritative about the state. This means that a random client (hopefully not hacked) can check everyone's state.

Also, you can run Bolt in headless mode, which opens the option to run it on dedicated machines. To do so, you have to orchestrate the PCs to run those instances and you have to make sure players use those (at least for some games).

There are a few services, which will deploy and manage game servers for you. One example would be Unity's Multiplay service. We have no direct experience with it but Bolt should work well with it.

Server Side Monitoring

You can use our Photon Server Plugin SDK to implement "server side analysis of a running game". You can modify the core operations and events of your game, so you can have any amount of control on the server.

There is no built-in support to run your game engine (or your full game), so the server has no access to the scene/level or any other data. This makes this solution a better fit for games that are "abstract" and do not rely on a scene.

In best case, you run the same game logic on the server as on the client and make the server create status updates for the client.

You can host custom logic on your own or let us handle it in the Photon Enterprise Cloud.

Full Server Authority

Again, if your game is "abstract" and does not need level data, it is relatively easy to implement full server authority right within the Photon Server.

If you need to run physics in various scenes, doing this directly in Photon is probably more effort than benefit.

In that case, using Photon Bolt or other in-Engine hosted solutions makes most sense.

Bolt has built-in features to support FPS and TPS, has a server-authoritative mode and can be hosted on your machines. We think it can be combined with Unity's "Multiplay" service but we have no experience in doing that.