2
\$\begingroup\$

I'd like to create a turn-based multiplayer game on Android. I'm thinking of using Google Play Game Services and get rid of any other webservice to create and host games.

The problem is the game involves dice rolls. I don't believe GPGS offers the possibility for third party dice roll, so my first thought was to integrate them in the app, however this gives great opportunity for cheating.

I've read the answers given in this question: Fair dice over network w/o trusted 3rd party , but they require all players to participate in the roll, which isn't possible if everyone isn't in the app at the same time.

Is there any alternative solution? Or do I have to use a third party for this?

|improve this question
\$\endgroup\$
2
\$\begingroup\$

I'm not familiar with Google Play Game Services, however it might be worth looking into how old console games did randomness. Often random number seeds were taken from hidden but not random states within the game and then the numbers come off a hidden list or calculator.

  • What frame of the game's start menu 'start' was hit on.
  • What enemies were killed in the prior room.
  • What frame of animation the target of an attack was on.
  • The X*Y coordinates of the player or enemies.

While these tricks don't directly apply to your case you still can learn from the past here.

One option could be to generate a seed value that all players know from the start of the game. This seed value decides the starting point on a known list or represents the first value in a known method of generating pseudo-random numbers. Because all players know both what the initial value is, and how many random numbers have been selected for secure actions, they all know exactly what the next value should be.

Another could be to hash all the specific relevant information about the game state to create a key (plus a game key to ensure each game is unique) that can be used to generate a pseudo-random number at both ends that is ensured to be the same number given the same game state. The numbers will differ only if the games are not exactly the same on both sides.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ But knowing the seed value, and thus what the next value should be could be also exploited to predict which rolls will appear next and chose the next move accordingly, doesn't it? And the same problem would occur by using the game state, if a user finds out what is used to seed the random, he could use it at his advantage. \$\endgroup\$ – Jukurrpa Mar 19 '14 at 16:20
  • 1
    \$\begingroup\$ You are correct. There are no ways to prevent all cheating other than keeping the software for running the game on an impartial (owned by you) server. These methods will prevent the players from changing the random values. You can keep the exact methods of generating the random numbers secret and encrypt the data. But this will of course not be invulnerable to snooping. You could also expose the random value to the players somehow, at least then both players have the same advantage. All non-deterministic multiplayer games have this issue. \$\endgroup\$ – DampeS8N Mar 19 '14 at 17:28
  • \$\begingroup\$ Alright, so it's mainly about how secure I want the game to be. Considering GPGS also has other issues (nothing to check legality of moves, amongst others), I guess I'll go for a game server. Thanks for your answers. \$\endgroup\$ – Jukurrpa Mar 20 '14 at 10:00
1
\$\begingroup\$

There is a concept called "synchronous networking", that means that all actions in the game are deterministic and thus will return the same result on all devices. If that is a given then you simply execute all actions on all devices in the same order and will end at the same state.

onMovePlayerLeft(player):
  player.X += 1

Now instead of sending over the result of onMovePlayerLeft, you just send over the fact that the "onMovePlayerLeft" was executed. Upon receiving the message you can than execute exactly the same code and both games are in the same state again.

Almost all calculations are deterministic as long as they don't depend on the hardware or the OS. (Unfortunately you will have to avoid using floats as different CPUs implement floats differently.)

But Beast, how does that help?! A dice roll isn't deterministic!

No, that is wrong. Random numbers as we use them in games aren't actually random, they are pseudo random. If the state of the RNG is the same the result will also be the same.

So if your game is synchronous then you just need to make sure that both clients use exactly the same seed at the start of the session.

Edit: But Beast, I don't want the player to know the result of the throw before hand!

In that case you'll need to negotiate a secret every time you want to make a throw.

This could look like this.

Peer A: I want to roll a dice for Action and need a RNG Seed for that.
Peer A: The checksum of my part of the seed will be 459023.
Peer B: The checksum of my part of the seed will be 390564.
Peer A: My part of the seed is 38000.
Peer B: My part of the seed is 76000.

The checksum is needed to enforce that the seed is generated before the peer has received the other seed.

Now you can generate the actual value of the negotinated seed by doing some simple math, such as (38000 + 76000) / 2.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ This is kind of the same answer as DampeS8N, and unfortunately if the players are able to tell which roll will come next they'll know what move to do or not... \$\endgroup\$ – Jukurrpa Mar 20 '14 at 9:49
  • \$\begingroup\$ You could let both devices send a seed to the other for every time a random number is needed and use the average of both seeds for the calculations. Since both clients don't know what seed they will get they can't influence the outcome reliably. \$\endgroup\$ – API-Beast Mar 20 '14 at 15:36
  • \$\begingroup\$ This works, but the problem is the game isn't synchronous, a player may take his turn while the other one isn't on the app. So I can't get users to share checksums and seeds before doing the actual roll. \$\endgroup\$ – Jukurrpa Mar 20 '14 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.