I plan to make multiplayer realtime game for Android (2-8 players), and I consider, which solution for multiplayer organization is the best:

  1. Make server on PC, and client on mobile, all communition go through server ( ClientA -> PC SERVER -> All Clients )

  2. Use bluetooth, I don't used yet, and I don't know is it hard to make multiplayer on bluetooth

  3. Make server on one of devices, and other devices connect ( through network, but I don't know is it hard to resolve problem with devices over NAT ? )

  4. Other solution ?

  • 3
    \$\begingroup\$ Are you planning on this being a local-only game or do you want people to be able to play with people across the internet? Are you hosting machines for games? \$\endgroup\$ – Tetrad Nov 14 '11 at 8:23
  • \$\begingroup\$ I choose small-scale multiplayer game, I plan to make game where people meet in room, and can play the same game (this is topic of my thesis: multiplayer on mobile platform ). But if someone have interesting solution for playing across the internet I'm also interested. \$\endgroup\$ – piotrek Nov 14 '11 at 10:45

Disclaimer; I haven't done much with java and the android platform.

However my more extensive experience with the '.net' languages on the windows mobile platforms, along with the windows platform, is that a good 75-90% of all the code required to create and maintain a Bluetooth or network data connection are maintained/supported with the OS or the libraries that would be need to access the hardware.

So far this also seems true with Android, with the OS exposing methods for creating data connections over Bluetooth or the internet, along with enabling/disabling the respective hardware.

I would imagine that Bluetooth would be the preferred method of connection, as this would be the least expensive to implement (No servers). And allow for a more local gathering/game. Bluetooth is fairly easy as to use. it functions similar to normal network sockets once you know which device you want to connect to.

The others are are correct in that Bluetooth v2.0/v2.1 is not currently capable of support large data loads. This will change with the eventual spread of v3.0 and higher. and there are ways of getting around this limitation.

For now though there is a simple concept, yet complex solution, which you may wish to try. I have been using it for awhile, It is similar to peer to peer, but it involves having the game hosted on all the devices simultaneously. That way if a connection is temporarily lost, slowed, or a player is dropped for any reason, other players will not be affected. This allows users that have been dropped to rejoin the ongoing game with little or no disruption to other players or their own game.

CON: Each player would actually be playing their own somewhat unique instance of the game, that would be linked with the other players to keep the games from straying too far out of sync with each other.

CON: The supporting code can be extensive/complex and difficult to wrap your head around depending on what you want to achieve.

PRO: No central server or device required! No $$$ upkeep required.

PRO: A heavy exchange of data would only occur when a player (re)joined, or a game was initialized. - Even this can be reduced by ensuring that all the games are going to be generated, and progress the same way by all the players. POTENTIALLY reducing energy consumption that occurs due to heavy network usage.

PRO: Data becomes less time sensitive, as the devices would already have all the data they require to keep a game going without the other players. Allowing you to focus more on the actual game experience for the individual users, rather than a group of players.

I have lacked the time to implement a full in-depth game engine that utilizes this. The games I've made have been limited to recreating games similar to Monopoly, and Uno, which seemed to function extremely well.

The easiest was the one that emulated Uno. I essentially stacked the decks of the losers after a player won as to ensure that player won all the games. 95%+ of the time I couldn’t tell that I wasn’t playing the exact same game as everyone else.

I started building a game similar to Master of Orion II, but the game itself was a little much for me to undertake by myself.

| improve this answer | |

It heavily depends on the game, but some friends and I were thinking about the same issues only a couple months ago, and here's what we determined. I'm in a pros and cons mood again.

Computer Based Server


  • Tried and true
  • Scaleable


  • Need to write a "multi-server" that can host multiple games at the same time. This will likely use slightly different technology than your android phone. You can still use java, but can you still use the android packages?
  • Can be expensive to run, and maintain
  • You could potentially pull it down one day for a verity of reasons. Fans may not be happy if the server goes down only a couple months after purchasing the game.

Peer To Peer with one of them in control


  • Ad-hoc servers where friends can join other friends when they want to
  • Little to no running cost on your part
  • The server code will be mixed in with the client code, no need to write a separate server application.


  • Need to write a simple centralized peer-finder. (I did mine in php+mysql in a couple hundred easy lines)
  • The servers are running on phones. Phones can be slow. Will all target phones be able to host a game?
  • What happens if the server phone gets disconnected?
  • Easier than client-server for hackers to get in

As for bluetooth, I would expect that to be similar to the peer to peer method above. I also don't think you should have any issues with NAT.

EDIT: It also heavily depends on your experience. I'd start with writing some relatively small client/server games to get the hang of networking first. It's a tough topic that is easy to get wrong the first time. I got mine right on the third try. Follow known patterns, and don't try to make something up yourself.

| improve this answer | |
  • \$\begingroup\$ I don't think it could be done via bluetooth, I doubt it supports broadcasts: AFAIK it only connects one single host to another, have a very low max connections amount, and is slow. \$\endgroup\$ – o0'. Nov 14 '11 at 12:35

One of the biggest considerations you need to make is reliability. Phones are not very reliable; in fact, you should probably assume that in a 8 player game someone is likely to disconnect (incoming call, bad reception, player quits...)

With this in mind, understand that you should minimize the impact of a disconnected user. In your second option, you've essentially made a phone the server. If that phone goes MIA, the game is effectively over for all players.

John covered the pros and cons of a traditional client <-> server architecture. This is probably the most resilient way to provide a reliable multiplayer experience for everyone.

You could also consider a technique along the lines of a lock-step-simulation. This can be implemented in a purely peer-to-peer manner. The general idea is that every client is expected to send it's update (series of commands, or lack thereof) every simulation step. In a subsequent simulation step, the commands of each player are applied to the game logic. Many RTS games employ this kind of networking scheme.

The technique can be difficult to implement and can be very difficult to debug. It is certainly more difficult than having a more traditional client-server architecture. It also implies a lag between a player's input and when the game responds to the input. However, if one player were to drop off, the remaining players could just exclude him from the game and continue. It can also potentially decrease network traffic compared to other schemes.

If you want to learn more about this technique, start with this excellent article on the subject. Otherwise, I would strongly discourage a network scheme where a single phone is responsible for a multiplayer session, and suggest the simpler client <-> server architecture.

| improve this answer | |

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