Meilleure solution pour le jeu Android multijoueur en temps réel [fermé]


11

Je prévois de faire un jeu multijoueur en temps réel pour Android (2-8 joueurs), et je considère quelle solution pour l'organisation multijoueur est la meilleure:

  1. Faire serveur sur PC, et client sur mobile, toutes les communications passent par le serveur (ClientA -> SERVEUR PC -> Tous les clients)

  2. Utiliser le bluetooth, je ne l'ai pas encore utilisé, et je ne sais pas si c'est difficile de faire du multijoueur sur bluetooth

  3. Rendre le serveur sur l'un des appareils et les autres appareils se connecter (via le réseau, mais je ne sais pas, est-il difficile de résoudre le problème avec les appareils via NAT?)

  4. Autre solution?


3
Envisagez-vous que ce soit un jeu uniquement local ou voulez-vous que les gens puissent jouer avec des gens sur Internet? Hébergez-vous des machines pour les jeux?
Tetrad

Je choisis un jeu multijoueur à petite échelle, je prévois de faire un jeu où les gens se rencontrent dans la salle, et peut jouer le même jeu (c'est le sujet de ma thèse: multijoueur sur plateforme mobile). Mais si quelqu'un a une solution intéressante pour jouer sur Internet, je suis également intéressé.
piotrek

Réponses:


2

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.


9

Cela dépend fortement du jeu, mais certains amis et moi pensions aux mêmes problèmes il y a seulement quelques mois, et voici ce que nous avons déterminé. Je suis de nouveau d'humeur pour et contre.

Serveur informatique

Avantages

  • Essayé et vrai
  • Évolutif

Les inconvénients

  • Besoin d'écrire un "multi-serveur" pouvant héberger plusieurs jeux en même temps. Cela utilisera probablement une technologie légèrement différente de celle de votre téléphone Android. Vous pouvez toujours utiliser Java, mais pouvez-vous toujours utiliser les packages Android?
  • Peut être coûteux à exécuter et à entretenir
  • Vous pourriez potentiellement le retirer un jour pour plusieurs raisons. Les fans peuvent ne pas être satisfaits si le serveur tombe en panne quelques mois seulement après l'achat du jeu.

Peer To Peer avec l'un d'eux en contrôle

Avantages

  • Serveurs ad hoc où les amis peuvent rejoindre d'autres amis quand ils le souhaitent
  • Peu ou pas de frais de fonctionnement de votre part
  • Le code serveur sera mélangé avec le code client, pas besoin d'écrire une application serveur distincte.

Les inconvénients

  • Besoin d'écrire un simple chercheur centralisé de pairs. (J'ai fait le mien en php + mysql en quelques centaines de lignes faciles)
  • Les serveurs fonctionnent sur des téléphones. Les téléphones peuvent être lents. Tous les téléphones cibles pourront-ils héberger un jeu?
  • Que se passe-t-il si le téléphone du serveur est déconnecté?
  • Plus facile que client-serveur pour les pirates d'entrer

En ce qui concerne le bluetooth, je m'attendrais à ce qu'il soit similaire à la méthode peer-to-peer ci-dessus. Je ne pense pas non plus que vous devriez avoir de problèmes avec NAT.

EDIT : Cela dépend aussi fortement de votre expérience. Je commencerais par écrire des jeux client / serveur relativement petits pour commencer par mettre en réseau. C'est un sujet difficile qui se trompe facilement la première fois. J'ai eu le mien au troisième essai. Suivez les schémas connus et n'essayez pas de créer quelque chose vous-même.


Je ne pense pas que cela puisse être fait via Bluetooth, je doute qu'il prenne en charge les émissions: AFAIK, il ne connecte qu'un seul hôte à un autre, a un nombre de connexions max très faible et est lent.
o0 '.

4

L'une des plus grandes considérations que vous devez faire est la fiabilité. Les téléphones ne sont pas très fiables; en fait, vous devriez probablement supposer que dans une partie à 8 joueurs, quelqu'un est susceptible de se déconnecter (appel entrant, mauvaise réception, joueur quitte ...)

Dans cet esprit, sachez que vous devez minimiser l'impact d'un utilisateur déconnecté. Dans votre deuxième option, vous avez essentiellement fait d'un téléphone le serveur. Si ce téléphone passe en MIA, le jeu est effectivement terminé pour tous les joueurs.

John a couvert les avantages et les inconvénients d'une architecture de serveur client <-> traditionnelle. C'est probablement le moyen le plus résilient de fournir une expérience multijoueur fiable pour tout le monde.

Vous pouvez également envisager une technique dans le sens d'une simulation de verrouillage. Cela peut être implémenté de manière purement peer-to-peer. L'idée générale est que chaque client est censé envoyer sa mise à jour (série de commandes, ou son absence) à chaque étape de la simulation. Dans une étape de simulation ultérieure, les commandes de chaque joueur sont appliquées à la logique du jeu. De nombreux jeux RTS utilisent ce type de schéma de mise en réseau.

La technique peut être difficile à mettre en œuvre et peut être très difficile à déboguer. C'est certainement plus difficile que d'avoir une architecture client-serveur plus traditionnelle. Cela implique également un décalage entre l'entrée d'un joueur et le moment où le jeu répond à l'entrée. Cependant, si un joueur devait abandonner, les joueurs restants pourraient simplement l'exclure du jeu et continuer. Il peut également potentiellement réduire le trafic réseau par rapport à d'autres schémas.

Si vous souhaitez en savoir plus sur cette technique, commencez par cet excellent article sur le sujet. Sinon, je déconseille fortement un schéma de réseau où un seul téléphone est responsable d'une session multijoueur, et suggère l'architecture de serveur client <-> plus simple.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.