I am currently considering the pros and cons of two different approaches for networking an Android game.

First, I will specify some details about the game and its requirements, and then I will explain the considered approaches.

The game is a mobile game currently being developed for Android (but may be a port to iPhone in the future). The game is being built on the Unity3D engine using the Android Basic license, which does not allow direct access to .NET sockets.

The core functionality of the game consists of basic matchmaking, and the gameplay during a match. Matches are turn based. When another player finalizes his/her turn, each other player will receive the update and will see it rendered. The client will collect the turn from the player and send it off to the server. Nothing too special here.

The first approach I am considering is a mixture of a REST service and Google's Cloud2Device Messaging. With this, the general flow would be:

  • Collect the turn from the user.
  • Send the turn to the server via an HTTP POST to a REST service.
  • The server processes the turn and saves the match state, assigning it an "event id."
  • The server uses Cloud2Device messaging to send a notification down to each client. The notification consists of an "event id."
  • Upon receiving the notification from the Google servers, the client will perform a GET to the game server's REST service asking for details for the respective event id.

Given this approach, the pros I see are:

  • REST services are easy to write (much of my experience is in REST services).
  • No custom socket work, as Google's service is used to notify clients.
  • Easy to implement within Unity's Android Basic license.
  • Cloud2Device Messaging allows an app to be "woken up" if it is not currently running (could be helpful in certain cases, I suppose).

The cons I see are:

  • Networking code is at the mercy of Google's service.
  • If Google delivers the "turn start" notification too late, a player may miss his/her turn.
  • Porting to the iPhone would require a heavy rework of network management.
  • Google likely will begin charging for Cloud2Device Messaging.

The alternative approach is to use a workaround to the lack of .NET socket support within Unity Android Basic. This would basically use Android's built-in socket support mixed with some custom-made Unity plugins to allow sending/receiving of network messages.

The general flow of this approach would be a straight-forward client/server socket approach, where each user playing the game has a connected socket.

The pros I see for this are:

  • All networking is handled by my services (not Google's).
  • Easier porting to other platforms (iPhone, iPad, etc.)
  • Potential to show more real-time player actions, rather than receiving all turn data after the turn has been committed.

The cons I see are:

  • Very little personal experience writing socket servers for games (this point scares me the most right now).
  • Debating whether this is necessary or not, as a turn-based game does not exactly need constant socket communication. A REST service may be all I need.
  • Constant socket communication may require an unnecessary amount of CPU or network data for a mobile device (or does having a socket open not require many resources expect when transmitting data?).

My observations and speculations aside, can anybody weigh in on this issue? I do not have much experience when it comes to game networking (especially for mobile) and would much appreciate advice on this issue. Let me know if more details are needed.


  • \$\begingroup\$ Update: I was able to build a small networking demo that uses Android's socket libraries even with a Unity Basic license, so option #2 certainly is do-able. \$\endgroup\$
    – Dharwin
    Jul 19, 2011 at 4:09

2 Answers 2


I've used (.NET) sockets in Unity3d on iPhone and it was pretty simple. Nothing to be scared about. Open connection should not (noticeably) consume resources when no transmission takes place, so that's not an issue. In fact, it might be that opening new connection for every request consumes more power and bandwidth.

That said, for a turn-based game using a web-service is probably simpler. As I understand, the only problem with this approach is notifying the client that opponent's turn ended. Maybe you can get away with simple polling from the phone?

  • \$\begingroup\$ From the license comparison page (unity3d.com/unity/licenses), .NET Socket Support is only available on Unity Pro ($3,000 for Pro+iPhone Pro). Were you able to use .NET sockets with an iPhone Basic license, or did you use Pro? I am currently limiting myself to Basic, but I am able to use a workaround by using the Android OS socket libraries. As for fear of socket servers, I was able to relatively painlessly get a chat server/client system up and running, so you may be right. Polling is something I would like to avoid if possible. \$\endgroup\$
    – Dharwin
    Jul 19, 2011 at 6:37
  • \$\begingroup\$ I was using Pro, so I didn't have to deal with this limitation. \$\endgroup\$
    – Nevermind
    Jul 19, 2011 at 9:54
  • \$\begingroup\$ My hope is to switch to the Pro version after I deploy to Android, but before I deploy to iPhone. Thank you for your response, I find it very helpful. \$\endgroup\$
    – Dharwin
    Jul 19, 2011 at 17:41

I would not recommend "reinventing wheels" here. Backend functionality is very similar regardless what is your app genre. you need to manage XP, Players, Levels , coins, virtual economy, watch retention reports, etc'.

I would recommend checking existing platforms that can save significant R&D time and money. My recommendation to game entrepreneurs is to focus on what suppose to bring them money - THE GAME.... and to use existing solutions for everything else.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .