Avertissement; Je n'ai pas fait grand chose avec java et la plateforme android.
Cependant, ma plus grande expérience avec les langues «.net» sur les plates-formes Windows Mobile, ainsi que la plate-forme Windows, est que 75 à 90% de tout le code requis pour créer et maintenir une connexion de données Bluetooth ou réseau sont maintenus / pris en charge avec le système d'exploitation ou les bibliothèques qui seraient nécessaires pour accéder au matériel.
Jusqu'à présent, cela semble également vrai avec Android, avec les méthodes d'exposition du système d'exploitation pour créer des connexions de données via Bluetooth ou Internet, ainsi que l'activation / désactivation du matériel respectif.
J'imagine que Bluetooth serait la méthode de connexion préférée, car ce serait la moins coûteuse à mettre en œuvre (pas de serveurs). Et permettre un rassemblement / jeu plus local. Le Bluetooth est assez simple à utiliser. il fonctionne de manière similaire aux sockets réseau normaux une fois que vous savez à quel appareil vous souhaitez vous connecter.
Les autres sont corrects dans la mesure où Bluetooth v2.0 / v2.1 n'est actuellement pas capable de prendre en charge de grandes charges de données. Cela changera avec la diffusion éventuelle de la v3.0 et supérieure. et il existe des moyens de contourner cette limitation.
Pour l'instant, il existe un concept simple, mais une solution complexe, que vous voudrez peut-être essayer. Je l'utilise depuis un certain temps, c'est similaire au peer to peer, mais cela implique d'avoir le jeu hébergé sur tous les appareils simultanément. De cette façon, si une connexion est temporairement perdue, ralentie ou qu'un joueur est abandonné pour une raison quelconque, les autres joueurs ne seront pas affectés. Cela permet aux utilisateurs qui ont été abandonnés de rejoindre le jeu en cours avec peu ou pas d'interruption pour les autres joueurs ou leur propre jeu.
CON: Chaque joueur jouerait en fait sa propre instance quelque peu unique du jeu, qui serait liée aux autres joueurs pour empêcher les jeux de s'égarer trop loin les uns des autres.
CON: Le code de support peut être étendu / complexe et difficile à comprendre selon ce que vous souhaitez réaliser.
PRO: Aucun serveur ou appareil central requis! Aucun entretien $$$ requis.
PRO: Un échange de données important ne se produirait que lorsqu'un joueur (re) rejoindrait ou qu'un jeu serait initialisé. - Même cela peut être réduit en s'assurant que tous les jeux vont être générés et progresser de la même manière par tous les joueurs. Réduire POTENTIELLEMENT la consommation d'énergie due à une utilisation intensive du réseau.
PRO: Les données deviennent moins sensibles au temps, car les appareils auraient déjà toutes les données dont ils ont besoin pour continuer à jouer sans les autres joueurs. Vous permettant de vous concentrer davantage sur l'expérience de jeu réelle pour les utilisateurs individuels, plutôt que pour un groupe de joueurs.
Je n'ai pas eu le temps de mettre en œuvre un moteur de jeu complet et approfondi qui utilise cela. Les jeux que j'ai créés se sont limités à recréer des jeux similaires à Monopoly et Uno, qui semblaient extrêmement bien fonctionner.
Le plus simple était celui qui imitait Uno. J'ai essentiellement empilé les decks des perdants après qu'un joueur a gagné afin de s'assurer que ce joueur remporte tous les matchs. 95% + du temps, je ne pouvais pas dire que je ne jouais pas exactement le même jeu que tout le monde.
J'ai commencé à construire un jeu similaire à Master of Orion II, mais le jeu lui-même était un peu trop pour moi à entreprendre par moi-même.