Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

Thanks!

share|improve this question
    
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. –  Dharwin Jul 19 '11 at 4:09

1 Answer 1

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?

share|improve this answer
    
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. –  Dharwin Jul 19 '11 at 6:37
    
I was using Pro, so I didn't have to deal with this limitation. –  Nevermind Jul 19 '11 at 9:54
    
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. –  Dharwin Jul 19 '11 at 17:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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