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!
