Descargo de responsabilidad; No he hecho mucho con Java y la plataforma Android.
Sin embargo, mi experiencia más extensa con los idiomas '.net' en las plataformas móviles de Windows, junto con la plataforma de Windows, es que se mantiene un buen 75-90% de todo el código requerido para crear y mantener una conexión de datos de red o Bluetooth / compatible con el sistema operativo o las bibliotecas que serían necesarias para acceder al hardware.
Hasta ahora, esto también parece cierto con Android, ya que el sistema operativo expone métodos para crear conexiones de datos a través de Bluetooth o Internet, junto con habilitar / deshabilitar el hardware respectivo.
Me imagino que Bluetooth sería el método de conexión preferido, ya que sería el menos costoso de implementar (sin servidores). Y permita una reunión / juego más local. Bluetooth es bastante fácil de usar. Funciona de manera similar a los enchufes de red normales una vez que sabe a qué dispositivo desea conectarse.
Los otros son correctos en que Bluetooth v2.0 / v2.1 actualmente no es capaz de soportar grandes cargas de datos. Esto cambiará con la eventual difusión de v3.0 y superior. y hay formas de sortear esta limitación.
Por ahora, aunque existe un concepto simple, pero una solución compleja, es posible que desee probar. Lo he estado usando por un tiempo, es similar a peer to peer, pero implica tener el juego alojado en todos los dispositivos simultáneamente. De esa manera, si una conexión se pierde temporalmente, se ralentiza o un jugador se cae por algún motivo, otros jugadores no se verán afectados. Esto permite a los usuarios que han sido eliminados volver a unirse al juego en curso con poca o ninguna interrupción para otros jugadores o su propio juego.
CON: Cada jugador en realidad estaría jugando su propia instancia algo única del juego, que estaría vinculada con los otros jugadores para evitar que los juegos se alejen demasiado de la sincronización entre sí.
CON: El código de soporte puede ser extenso / complejo y difícil de entender dependiendo de lo que desee lograr.
PRO: ¡ No se requiere un servidor central o dispositivo! No requiere mantenimiento $$$.
PRO: Un intercambio intenso de datos solo ocurriría cuando un jugador (re) se uniera o se iniciara un juego. - Incluso esto puede reducirse asegurando que todos los juegos serán generados y que todos los jugadores progresen de la misma manera. POTENCIALMENTE reduciendo el consumo de energía que ocurre debido al uso intensivo de la red.
PRO: Los datos se vuelven menos sensibles al tiempo, ya que los dispositivos ya tendrían todos los datos que requieren para mantener un juego sin los otros jugadores. Lo que permite que se concentre más en la experiencia de juego real para los usuarios individuales, en lugar de un grupo de jugadores.
Me ha faltado tiempo para implementar un motor de juego completo que lo utilice. Los juegos que hice se han limitado a recrear juegos similares a Monopoly y Uno, que parecían funcionar extremadamente bien.
La más fácil fue la que emuló a Uno. Básicamente, apilé los mazos de los perdedores después de que un jugador ganó para asegurar que ese jugador ganara todos los juegos. Más del 95% de las veces no podía decir que no estaba jugando exactamente el mismo juego que todos los demás.
Comencé a construir un juego similar al Master of Orion II, pero el juego en sí fue un poco difícil de realizar por mí mismo.