1

TL;DR

  • android, board-like game.
  • latency unimportant.
  • client-server via LAN/Global, potential high score => no trust.
  • potential bluetooth layer in future => full trust.
  • mobile means expensive traffic, upstream more expensive than downstream.
  • PRNG used a lot, must be deterministic.
  • kryonet for serialization + transmission

Me & a couple of pals are building our "port"/"flavor" of a board-game (with a lot of different event-types and permutations of all sorts) to Android and adding a networked multi player aspect to it. We are no encryption or networking experts =)

The game:s default multi player layer will be client-server based (server is either dedicated host or run on an android device [in case you're out in the woods with your friends and you've no network] ). This might be a global server, or LAN - it doesn't matter much. But there might be a potential high-score which needs some anti-cheating mechanisms As it is a turn-based board-like game, latency is neither an issue.

In the future, if we've time - we might add a bluetooth based layer, but in this case cheating is not an issue as the assumption is that the people know each other well.

Since we're dealing with a (most likely) mobile network where upstream is more expensive than downstream, downloading from server is cheaper than sending the models from client.

We'll probably be using kryonet for the serialization and transmission of data.

The game will use PRNGs quite frequently, and as such it needs to have some good anti-cheat and verification logic, so after a lot of searching and reading at gamedev & stack overflow, I've devised the following logic. I need some input on how sound the plan is. All tips and recommendations are greatly appreciated.

Assumptions / Considerations:

  • PRNG behaves deterministically ( thinking of using Mersenne Twister ).
  • Normal game play shouldn't be penalized due to anti-cheat measures.

Scheme / Plan:

  1. On "handshake" / first connection since "onResume()" - acquire PRNG seed from server and store it. Each player has its own seed in server.

    1. Also send hash of game state to server in same request and if out of sync, sync game state.

  2. On action / user input, get next random number -> save to "bucket of randoms" (hence known as bucket - the bucket is a "trapped list" to which you may add but never remove). Also save input ID/Type/Enum to a list.

  3. Accumulate changes until other players have to know (i.e next players turn) / PNR (Point of No Return)

  4. PNR reached

    1. Send change ID/Type/Enum ( ca. 64 bits ) + bucket + hash (post change) of model. Should bucket + hash be encrypted, maybe AES 256 (other encryption tech that's more suitable?).

    2. Check bucket against N consecutive random numbers where N = size( bucket ). If no match, goto 6, then 7.

    3. Make changes to model temporarily (without committing to full game model).

    4. Compute hash and check against client provided hash. If invalid goto 6.

    5. Valid: commit to game model on server.

    6. Invalid: ask client to revert to state sent back by server.

    7. Cheat: Ban ( not IP [dynamic IPs...], rather MAC addr or UID ) / Remove from game on several cheats.

EDIT: Also - another question regarding anti-cheat... Any good ideas for antimeasures for bot teams of 2 farming highscores for a board-like game?

EDIT2: Here's the links to the pre-question research I did:

Look into:

5) Use some lightweight polymorphic encoding on your game connections.

6) Use some anti-debugging techniques to prevent debuggers from attaching to your processes. Google anti-debugging and you should be able to find lots of stuff.

7) Use a custom proprietary PE packer to prevent useful disassembly of your game.

8) Using hashes as a promise, and then reveal the meaning of the hashed promise once conditions on the behavior of other players are met. It's complicated, and it has performance impact, but some of the ideas may be useful, particularly to peer to peer games.

9) I think a good way to make harder the problem to the crackers is to have the only authoritative copies of the game state in your servers, only sending to and receiving updates from the clients, that way you can embed in the communication protocol itself client validation (that it hasn't been cracked and thus the detection rules are still in place). That, and actively monitoring for new weird behavior found might get you close to where you want to be.

Realtime FPS related, less relevance to us:

That's about it, hope you've got some tips!

Community
  • 1
  • 1
Centril
  • 2,224
  • 17
  • 28

0 Answers0