1
\$\begingroup\$

I'm writing a card game in Swift. The idea is to make it work on the Apple Game Center framework. I've noticed an issue which I am not sure how to address.

  • I need the current game data to be the same for all players.
  • There are 6 players in the game.
  • There is a deck of 30 cards, they are shuffled.
  • Each player must have the same deck of cards (post-shuffle).
  • 6 cards are presented to the "table" one at a time (animation).

There are also other activities that a player does that are outside the bounds of this question.

My question is this;

How do I give each player the same shuffled deck of cards?

There are a couple of options I can think of, but perhaps none of these are the best way; hence my question

  1. The start player is the host. The host creates the shuffled deck, and this deck is sent to other players (ie: JSON); in short all activities are facilitated through him.

The problem with this is that the start player could lose internet, abandon the game or all sorts?

So I don't think this is a viable solution

  1. There is a middleman, the server.

There is a "lobby" (waiting area) There is multiple games. The game has players. An AI-bot could be used to fill in abandoned players

But wait, does this then mean the server shuffles the cards and sends the same data to all players and makes the players "thin clients"?

Can Apple's Game Center handle this for me?

I'm not sure about the best solution for this?

\$\endgroup\$
  • 3
    \$\begingroup\$ My immediate reaction was "use a seed." The seed could be arbitrary (such as "time in milliseconds since UTC 0" or whatever) so long as the value of that seed can be saved. Then a connecting player only needs two pieces of information: the seed (to shuffle the deck) and the number of cards already removed from the top. \$\endgroup\$ – Draco18s Jan 11 '16 at 21:05
  • \$\begingroup\$ Seeds sounds interesting idea. \$\endgroup\$ – zardon Jan 11 '16 at 22:51
4
\$\begingroup\$

Why shuffle the deck in the first place? All clients know which cards were already played and which cards are still in the deck. What they don't know is the order in which they come. So instead of fixing the order at the beginning of the game, why not determine it during the game?

Keep the deck as a sorted array and whenever a new card is needed, pick a random number and remove that card from the deck.

Generating the random number on the server would be the best way to prevent cheating. There are ways for multiple clients to agree on a random number together without any one client being able to predict or force the result, but they are quite complicated. So if you have the option of doing it server-sided, do it.

\$\endgroup\$
  • \$\begingroup\$ Ah, so; generate a random card to remove, remove this from the deck, then send this number (or seed) to other players; then the app on their side can then update or sync as required \$\endgroup\$ – zardon Jan 11 '16 at 22:53
  • \$\begingroup\$ This method has the advantage that no amount of eavesdropping or hacking on the client can let a player predict future draws, since each draw is decided on the server (or by a distributed algorithm) on demand. This is in contrast to the earlier suggestion of seeds, where an eavesdropper who intercepts the seed in transit, or a hacker who extracts it from the client's memory is able to predict all future draws. The (minor) disadvantage is more data needs to be stored to persist the state of the deck (identities of all cards played/remaining, rather than a seed plus a count) \$\endgroup\$ – DMGregory Jan 11 '16 at 23:26

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.