architecture - Best solution for multiplayer realtime Android game

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 ?

   
   

Answer

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.