Haftungsausschluss; Ich habe nicht viel mit Java und der Android-Plattform gemacht.
Meine umfangreichere Erfahrung mit den '.net'-Sprachen auf den Windows Mobile-Plattformen sowie der Windows-Plattform ist jedoch, dass gut 75-90% des gesamten Codes, der zum Erstellen und Verwalten einer Bluetooth- oder Netzwerkdatenverbindung erforderlich ist, beibehalten werden. unterstützt mit dem Betriebssystem oder den Bibliotheken, die für den Zugriff auf die Hardware erforderlich wären.
Bisher scheint dies auch für Android zu gelten, da das Betriebssystem Methoden zum Erstellen von Datenverbindungen über Bluetooth oder das Internet sowie zum Aktivieren / Deaktivieren der jeweiligen Hardware bereitstellt.
Ich würde mir vorstellen, dass Bluetooth die bevorzugte Verbindungsmethode ist, da dies am kostengünstigsten zu implementieren wäre (keine Server). Und ermöglichen Sie eine lokalere Versammlung / Spiel. Bluetooth ist recht einfach zu bedienen. Es funktioniert ähnlich wie normale Netzwerk-Sockets, sobald Sie wissen, mit welchem Gerät Sie eine Verbindung herstellen möchten.
Die anderen sind insofern richtig, als Bluetooth v2.0 / v2.1 derzeit keine großen Datenlasten unterstützen kann. Dies wird sich mit der möglichen Verbreitung von Version 3.0 und höher ändern. und es gibt Möglichkeiten, diese Einschränkung zu umgehen.
Im Moment gibt es jedoch ein einfaches Konzept und dennoch eine komplexe Lösung, die Sie vielleicht ausprobieren möchten. Ich benutze es seit einer Weile. Es ist ähnlich wie Peer-to-Peer, aber es beinhaltet, dass das Spiel auf allen Geräten gleichzeitig gehostet wird. Auf diese Weise sind andere Spieler nicht betroffen, wenn eine Verbindung vorübergehend unterbrochen, verlangsamt oder ein Spieler aus irgendeinem Grund unterbrochen wird. Auf diese Weise können Benutzer, die gelöscht wurden, wieder am laufenden Spiel teilnehmen, ohne andere Spieler oder ihr eigenes Spiel zu stören.
CON: Jeder Spieler würde tatsächlich seine eigene, etwas einzigartige Instanz des Spiels spielen, die mit den anderen Spielern verknüpft wäre, um zu verhindern, dass die Spiele zu weit von der Synchronisation abweichen.
CON: Der unterstützende Code kann umfangreich / komplex sein und es ist schwierig, den Kopf herumzureißen, je nachdem, was Sie erreichen möchten.
PRO: Kein zentraler Server oder Gerät erforderlich! Kein $$$ Unterhalt erforderlich.
PRO: Ein starker Datenaustausch würde nur stattfinden, wenn ein Spieler (erneut) beigetreten ist oder ein Spiel initialisiert wurde. - Auch dies kann reduziert werden, indem sichergestellt wird, dass alle Spiele generiert werden und alle Spieler auf die gleiche Weise vorankommen. MÖGLICHERWEISE Reduzierung des Energieverbrauchs aufgrund starker Netzwerknutzung.
PRO: Daten werden weniger zeitkritisch, da die Geräte bereits über alle Daten verfügen, die sie benötigen, um ein Spiel ohne die anderen Spieler am Laufen zu halten. So können Sie sich mehr auf das tatsächliche Spielerlebnis für die einzelnen Benutzer als auf eine Gruppe von Spielern konzentrieren.
Mir hat die Zeit gefehlt, eine ausführliche Spiel-Engine zu implementieren, die dies nutzt. Die Spiele, die ich gemacht habe, beschränkten sich auf die Neuerstellung von Spielen ähnlich wie Monopoly und Uno, die anscheinend sehr gut funktionierten.
Am einfachsten war derjenige, der Uno emulierte. Ich habe im Wesentlichen die Decks der Verlierer gestapelt, nachdem ein Spieler gewonnen hat, um sicherzustellen, dass der Spieler alle Spiele gewonnen hat. In über 95% der Fälle konnte ich nicht sagen, dass ich nicht genau das gleiche Spiel wie alle anderen gespielt habe.
Ich habe angefangen, ein Spiel zu entwickeln, das Master of Orion II ähnelt, aber das Spiel selbst war für mich ein wenig zu viel.