next »

[Qwerku]

Hi all,

I'm designing a very ambitious new game, and while nearly all of the design pieces are fitting together nicely, I foresee the map hacking issue in Starcraft 2 happening to my game in the future.

The game is multiplayer turn-based where one player is the server (or it could be dedicated, doesn't matter).  All players broadcast their keyboard+mouse input for each turn. The game state is perfectly known by each player's client, and everyone increments the turn in lockstep. Everybody broadcasts out a hash of the game state periodically, so that should clamp down on clients modifying the game state.

This is all well and good for lean networking and for most cheating issues (just like Starcraft 2), but it clearly paves the way for maphack abuse where a player is able to see everything going on outside of their intended "view".

TL;DR Is there any sane way of defeating a map hack when all clients calculate the game state from user inputs on each turn?

Thanks for your time and insight!
Qwerku

[ThemsAllTook]

The game state is perfectly known by each player's client, and everyone increments the turn in lockstep. Everybody broadcasts out a hash of the game state periodically, so that should clamp down on clients modifying the game state.

It seems to me like this is the part that would need to change. To remove the possibility of inspecting game state that an individual player isn't intended to see, their client would need to only receive information about the parts of it they have access to. Sounds tough to implement, and it would also mean that revealing new parts of the map would have to involve a round trip to the game server. If you really want to prevent this though, I think this would be the way to go.

[ProgramGamer]

You could render the game on the server side and stream the resulting footage to your clients :^)

More seriously, the only way I can see to couterract map hacking is to only give each client information on things that the fog of war lets them see. This would probably complicate the code significantly and bloat the amount of bandwidth needed to keep the game state updated, as each time an entity comes into view its whole state would need to be sent over.

This is assuming that a server is used. If the game is peer-to-peer, then there's no way to prevent this sort of thing.

[Daid]

Having a game run correctly in lock-step is generally quite difficult to keep working correct. Just see the amount of "desync" bug fixes Factorio does in their updates.

It's also what exposes your game state to all clients, and thus makes map hacks an option, and not even that difficult to pull of in general. As you just look at the memory of your game with an external debugger, or monitor the network traffic.


So your best option, if you want to prevent cheating, is only sending the game state that the clients actually know about. I would argue that this actually makes your game easier to build. As lock-step is difficult. And with this change, the clients can become quite "dumb" where a lot of knowledge and dicision making is only done on the server.

[qMopey]

The problem is round trip latency for a fast action packed RTS. You can of course have a tiered fog of war, where there’s a middle layer not visible by a regular client, but still known to the client. Like a buffer zone of not rendered but network synced. Then there’s the fully visible layer where the only difference is the client renders units in this zone. Then the dark zone where the client is unaware of units.

This style will mitigate lag problems, and still be prone to maphacks, but now maphack only reveals a larger radius instead of revealing the whole map. However you can still get network traffic spikes if large areas of the map are suddenly revealed, such as watch towers or moving into high ground. There will also be latency spikes for such cases. You can try to design your game around fhese limitations, such as revealing new fog of war slowly like water pouring over a basin.

[Qwerku]

Thanks for the responses everyone! I am definitely worried about minimizing bandwidth. I'll take these ideas and see if I can come up with a sensical max area implementation for each client.  That's looks to be the best compromise I can hope for at this point.

May Aevans watch over you. (In-game lore)

[Daid]

I am definitely worried about minimizing bandwidth.

I highly recommend doing some basic math on bandwidth requirements. As you might be pre-mature optimizing...
For example, I thought my game code wouldn't work on the internet, as I made it for local network, and updating a lot of game state at 60 updates per second. In the end, it comes down to 30kb/s per client on heavy games. Which came down to pretty possible for a server to provide without issues.