1
\$\begingroup\$

My friends and I are creating a game for mobile platforms. We are now in the phase of creating the multiplayer part of the game.

We know how to do it but we are not sure how the multiplayer should work. Our game is turn-based, so if we would do something like Wordfeud. Where there is a time limit.

How could we be certain that [User2] knows that [User1] has ended his turn if lets say [User2] has his phone turned off.

Should we let the server control this time limit or should we let the client count for itself?

|improve this question
\$\endgroup\$
  • \$\begingroup\$ Google has a turn based api ready for you. You have to integrate Google play services to access it. There is also a example online. I'm on my phone now, but you should be able to find everything yourself easily. \$\endgroup\$ – Madmenyo Aug 2 '15 at 20:28
  • \$\begingroup\$ You should always do all logic on the server. If you have multiple clients and no server then make one of the clients also the server. \$\endgroup\$ – zoran404 Aug 2 '15 at 21:15
1
\$\begingroup\$

You should store all the state and place all the logic on the server (never trust any data coming from the client!).

In my opinion the best way to do it would be keep track of when User1 ends its turn, and in that moment send a push notification to User2. Then, whenever User2 opens the app, to retrieve the current game info it will need to send a request to your server, so store that time in your server and keep also a timer locally.

If User2 is a "normal user" and its local timer runs out, your app should notify the server. But he is a cheater and sends a fake petition manually after the local timer has ended, your server should check against the stored time to see if his timer is really running.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Not that you just copied my comment, but you also contradicted your answer saying players should act based on local image of the game state. There is absolutely no need to have this timer variable stored locally if your logic is on the server. You only have to refresh the game state on the client. \$\endgroup\$ – zoran404 Aug 3 '15 at 8:24
  • 1
    \$\begingroup\$ @zoran404 I didn't copy your comment (I didn't even read it) and while yours is merely a comment mine is a full answer. If he wants to let User2 how many time is remaining, he must keep a local timer just to keep updated the countdown, but perform the validation in the backend. Of course, as you say you could only refresh the game state, but sending a request each second seems like an unnecessary bottleneck, a significant extra load for the server and a waste of data (on smartphones with data plans) for the player. \$\endgroup\$ – Arcadio Garcia Aug 3 '15 at 9:15
  • \$\begingroup\$ Server can tell the client when to refresh. Or just send the update to the client when it occurs. Refreshing the game every second would introduce lag, but it would work and I don't think anyone would care if the game used few hundred extra bytes of bandwidth per session. Your argument is invalid. \$\endgroup\$ – zoran404 Aug 3 '15 at 10:19
  • \$\begingroup\$ But it is an overkill compared to just display a countdown with the local timer and just verify the requests. Both would work but this is more efficient and also does not mix the model (the game state) with the view (a countdown that will only be displayed, with no gameplay implications). \$\endgroup\$ – Arcadio Garcia Aug 3 '15 at 10:49

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.