Cherche retour d'expérience [multiplayer inside]

[NGTerenas]

Salut tout le monde,

Dans le cadre du développement d'un jeu (BattleGameTriad, cf forum Archos 5 IT), et surtout pour ma culture, je cherche des retours d'expérience sur le développement d'applications multijoueurs sur Android (ou autre plateforme mobile).

Quelle architecture technique avez-vous mise en place ? Difficultés rencontrées etc...

J'ai vu que le moteur "Mages" permettait de faire des choses, qui s'en est servi ? Pourquoi ?

Avez-vous privilégié une connexion permanente device2device (avec un des 2 devices qui fait l'host et l'autre client) ou bien une architecture client/serveur avec le classique PC serveur qui stocke les infos d'une partie et que les 2 devices interrogent régulièrement ?

Merci d'avance pour vos réponses !

'nas.

[Odin]

Bonjour,

Je serais aussi intéréssé par ce genre d'informations.

Je développe principalement en .Net normalement, et je voulait me lancer dans l'aventure Android avec un petit jeu multiplayer (j'ai qq connaissances en Java pur, mais les librairies et techno associés, c'est pas vraiment ca...).

Donc, imaginons l'exemple d'un simple jeu de dames où on pourrait voir une liste des personnes connectées à l'application, et la possibilité de créer / rejoindre une partie et evidemment de la jouer (tour par tour donc).

Quel genre d'architecture / technologie permettrait d'obtenir un résultat satisfaisant ?

Je pars du principe que ce n'est pas simplement du DeviceToDevice et qu'il faut un serveur (puisqu'on veut la liste des personnes connectées (et pourquoi pas la possibilité de chatter avec eux).

De plus, le serveur devrait avoir la possibilité d'envoyer directement des informations aux clients (pour éviter que le client n'appelle sans cesse le serveur pour voir si il y a du nouveau, bouffant la connection et la batterie.)

D'après mes première recherches, je pensait à tout simplement utiliser les Socket avec un serveur qui tourne constemment.

Y aurait-il d'autre pistes à explorer ? Comment VOUS vous y êtes pris ?

J'ai vu sur ce forum un jeu multi joueurs qui fait exactement ce que je cherche en fait : World of Bombs (très sympa d'ailleurs ;)), et c'est ce genre de resultat que j'aimerais obtenir.

(PS : si vous avez utilisé les Socket, comment héberger le serveur ? Une machine chez vous qui reste tout le temps allumé ? Existe t-il des serveurs "pro", payant ou gratuit, qui ouvre les ports et permettent l'hébergement d'un tel programme ?)

Modifié 11 décembre 2009 par Odin

[NGTerenas]

Bienvenue Odin,

J'ai exploré quelques pistes depuis la création de ce Thread :

- Device2Device n'est pas possible : le proxy/NAT des opérateurs pose problème pour faire communiquer en P2P les mobiles

- Client/Serveur puis Device2Device : Ouvrir une socket sur le serveur et quand 2 joueurs lancent une partie, les faire communiquer directement par socket : même problème que pour le Device2Device, on arrivera pas à les faire discuter

Il reste donc le Client/Serveur classique.

Le problème du Client/Serveur est au niveau du load du serveur... Avec un hébergement mutualisé standard (pire des cas) type 1and1 ou OVH, la machine ne pourra pas faire serveur de socket (pas d'accès SSH ni crontab ni rien quoi), ce qui force à une solution de contournement crade et gourmande en ressource : remplacer le serverSocket par des requêtes HTTP ou WebService à jouer en boucle (l'intervalle restant à définir).

Ca fonctionnera mais il ne faudra pas s'attendre à tenir une forte charge et une réactivité décente. Il faudrait que je prenne le temps de faire de l'OpenSTA sur mon hébergement mutualisé, juste pour voir ce que ça donnerait...

Avec un serveur dédié qui fait office de serveur de socket (je pense que c'est ce qui est fait dans WoB), la solution est idéale mais il reste le problème de charge... Combien d'utilisateurs simultanés peuvent être supportés par un serveur dédié "pour amateur" (sans devoir vendre un organe tous les ans) ? 10 ? 100 ? 1000 ? ...

Une autre solution est un serveur dédié qui fait "master server" (à la manière d'un load balancer) et qui n'est utilisé que comme solution d'authentification des utilisateurs et redirection vers des slaves servers qui s'occupent de traiter les parties.. à la manière des realms dans des jeux bien connus (les jeux Blizzard notamment pour ne pas les citer).

L'utilisateur s'authentifie au master server qui lui renvoie la liste des serveurs dispo.

L'utilisateur accède avec un token à un de ces serveurs et communique dans ce périmètre restreint. La charge est donc répartie et contrôlable...

Après suivant la logique métier et le besoin de gérer de manière sécurisée des statistiques, on peut stocker les parties, dialogues & co sur les slaves mais ne stocker les statistiques des joueurs que sur le master... Si ca peut permettre de sécuriser les "scores" d'une manière globale, c'est une problématique à prendre en compte.

Si l'auteur de WoB pouvait se manifester ici, ça serait super... Même si je suis 95% sûr qu'il utilise un socketServer qui communique avec ses clients Flex (me trompe-je ?) et Android.

[NGTerenas]

Ohhh ! On a à faire à un expert en optimisation =)

Et monsieur a déjà une bien belle infrastructure à ce que je vois... J'étais pas trop loin avec mon erzatz de loadBalancer ;p

Je vais faire court car je veux rentrer chez moi (le boulot c'est sympa aussi mais bon) mais je suis globalement d'accord avec ce que tu racontes... En tout cas je te rejoins sur la vision des architectures physiques et réseau.

Après, pour l'implémentation, je ne suis pas développeur Java à la base (à vrai dire, BGT est mon 1er soft en Java) donc je ne jugerai pas les solutions proposées, ne les connaissant pas/peu...

Mais dans tous les cas, à priori, un/des serveur(s) dédié(s) sont nécessaires pour garantir une QoS acceptable : Tu sors déjà l'artillerie pour gérer ~20k joueurs, je pense que ça donne une bonne vision du problème du temps réel.

Bon courage pour l'optimisation de l'IHM, mais je me doute que ça ne devrait pas être un problème pour toi... et bravo pour la technique !

Olivier.

[Profete162]

Archos va créer beaucoup de rage ce soir!

[Alocaly]

J'ai exploré quelques pistes depuis la création de ce Thread :

- Device2Device n'est pas possible : le proxy/NAT des opérateurs pose problème pour faire communiquer en P2P les mobiles

- Client/Serveur puis Device2Device : Ouvrir une socket sur le serveur et quand 2 joueurs lancent une partie, les faire communiquer directement par socket : même problème que pour le Device2Device, on arrivera pas à les faire discuter

Juste une petite question : je ne comprends pas bien pourquoi du Peer2peer serait vraiment impossible ?

C'est comme ca que sont fait la très grosse majorité des jeux consoles / PC, et dans l'ensemble, ca marche pas trop mal.

Le matérial indique qu'il est toujours possible de tomber sur deux personnes qui ne pourront jamais se voir, mais ces cas là sont relativement rares, normalement...

Donc a priori, tu peux avoir un serveur non temps réel qui fait juste de la mise en relation, puis apres, toutes les communications se font en peer to peer....

J'ai raté quelque chose ?

Sinon, Albus, tu aurais un lien pour qu'on en connaisse plus sur Commet ? Je ne connais pas et ca peut m'interesser !!!

Merci bien,

Emmanuel / Alocaly

[NGTerenas]

@Alocaly :

Dans le principe, ce n'est pas impossible (suivant la politique de l'opérateur)... Je suis d'accord sur le fait que c'est comme ça que font tous les jeux (enfin une grande majorité). On se connecte à un Realm et après un des joueurs devient host, le Realm ne servant plus qu'à faire la mise en relation.

Le premier problème majeur, c'est qu'il faut se gaufrer les trames à la mano... Je sais pas toi mais je ne me sens pas capable de le faire actuellement. Ce que je suis capable de faire, c'est de déterminer l'IP privée du mobile sur le réseau de l'opérateur ainsi que l'IP public (sortante) de l'opérateur.

Supposons que je communique ces informations là au serveur, et donc aux autres clients... Il faut écrire les entetes de paquets qui vont bien pour qu'ils puissent arriver à bon port ET prier pour que les proxy/routeurs/firewalls de l'opérateur téléphonique autorise la connexion d'une IP qui n'a pas été initiée au préalable par le mobile (99% sûr que ce genre de paquet est détruit).

Quand on voit comment des jeux galèrent sur le multijoueur dès le game lobby (Dawn of War 2 et ses problèmes de NAT, L4D à ses débuts, Borderlands...), j'imagine même pas sur mobile avec les problématiques supplémentaires que sont la médiocrité du réseau, les déco/reco intempestives, etc...

Parce que même si on arrive à pondre un P2P qui marche... Les problèmes de connectivité font que ca ne tiendra jamais bien longtemps. J'ai pas vérifié si l'IP privé du mobile est en DHCP statique ou dynamique, mais ça serait une blague supplémentaire à gérer. A chaque perte de connexion, il faudrait contacter le serveur pour transmettre les nouvelles IP à l'ensemble des participants et relancer le P2P. Ouch.

Pour "Commet", je pense qu'il y a une faute de frappe et qu'il voulait dire "Comet"... En gros c'est pour faire du serveur push. Le client se connecte au serveur (web), le serveur initie la connexion, renvoie le résultat mais ne ferme pas la connexion (avec une loop qui va bien et du buffering), ce qui permet au serveur d'envoyer des données (mise à jour par exemple) sans que le client n'en fasse la demande.

http://en.wikipedia.org/wiki/Comet_%28programming%29

[Odin]

Merci pour vos retours.

Vu que je vais pour l'instant me contenter de tour par tour, je veux essayer de me débrouiller avec un serveur Web.

J'ai donc chercher quelques information sur Comet, et je dois avouer que j'ai le cerveau qui commence a fumer...

Entre les differentes implementation, les serveurs, et les différentes sources qui disent tout et son contraire sur ce terme, j'ai failli craquer et me contenter de socket finalement ^^.

Mais j'ai perséverer et je commence a y voir a peu près clair, et je vais faire quelques test pour voir ce que j'arrive a pondre en utilisant Jetty et Cometd (probablement implémenter du long pooling) et voir si ça "scale" bien.

Maintenant, "y a plus qu'a" comme on dit ;)