Advice for turn based game, web and mobile
Members - Reputation: 182
Posted 03 April 2011 - 01:16 AM
Initially, I was considering creating a web service for the client to call. The difficulty with this is that there's no way to notify players when something has happened, so clients would have to poll regularly, possibly every few minutes. Because of this, I'm considering creating a server that communicates with the clients using TCP. My concern is for mobile devices. If I switched to sockets, how would it fare? I assume mobile device connections drop often due to inconsistent reception.
Is there a better way to do this?
Members - Reputation: 230
Posted 03 April 2011 - 05:13 AM
However, Silverlight only runs on Windows Phone, so that will limit you to like 5 people.
Moderators - Reputation: 4356
Posted 03 April 2011 - 01:47 PM
TCP will handle this for you. Any connection issues will manifest as high latency, which won't really affect you since you're turn-based.
Not really. TCP can't deal with events like changing the IP address of the host, which I believe will happen when your phone goes out of coverage and comes back into coverage (or gets turned off, or whatever).
Also, your particular game may very well be killed by the phone because it's low priority, when the game is in the background and the user is using the phone for other things (surfing youtube or whatever).
Thus, I suggest you poll the service. If the game play speed is "days" then I suggest you poll maybe once an hour by default, and have a user option to poll manually if needed. The Twitter API, which probably has a lot more immediacy than a game where a turn is a day, is still based around polling.
I suggest that you keep a queue of events that the user needs to see. These can be numbered. When the user polls, you simply check whether there are any events with an id higher than what the user last saw -- which can be provided by the client. If you use Redis to keep state, or if you use a primary key of (userid, eventid), then the query will be fairly efficient. The code on the client is super simple, too:
1) find the highest event id seen since last poll
2) query https://mygame.com/events?last=<last-event-id> using HTTP Basic authorization for username/password (convenient, and safe over HTTPS)
3) for each event returned, deal with it, and save it as the highest seen event id