Discussion :

[GoldenEye]

Bonjour à tous
Dans le cadre de développement de jeu amateur (que ce soit un Quake like ou un Monopoly like), je me pose une question existentielle quant à la technique à utiliser pour la partie réseau (le jeu est en C++ sous OpenGL) :
- architecture client-serveur avec des sockets TCP/IP avec sockets + multithreading. J'ai déjà donné là-dedans, le protocole peut devenir complexe si beaucoup de données sont échangées mais on maîtrise bien les données et leur état
- architecture middleware Corba. L'idée de partager des objets permet de s'affranchir de la couche basse mais est-ce aussi performant (je n'ai jamais essayé)
- autres suggestions ?
Quels critères permettent de choisir l'une ou l'autre des solutions ?

Merci d'avance

[nouknouk]

salut,

sans aucune hésitation, utilise quelque chose de moins lourd que CORBA pour programmer un client/serveur pour un jeu.

Utiliser CORBA pour un 'petit' besoin en réseau, c'est un peu comme vouloir utiliser Oracle pour stocker des infos sur une collec' de DVD persos.

Il existe des frameworks sous license libre dispos sur le web.

Si rien ne te convient parfaitement, il est relativement aisé de se construire sa petite librairie sur mesure, d'autant plus si tu as déjà une première expérience du développement d'applis 'réseau'.

MY 2 cents.

[Mat.M]

Utiliser CORBA pour un 'petit' besoin en réseau, c'est un peu comme vouloir utiliser Oracle pour stocker des infos sur une collec' de DVD persos.

Je trouve également que prendre CORBA c'est un peu lourd pour un jeu vidéo sans compter que je crois que c'est pas gratuit...
GoldenEye tu crois pas commençant avec Php et MySQL ça serait plus simple au départ ?

[nouknouk]

GoldenEye tu crois pas commençant avec Php et MySQL ça serait plus simple au départ ?

PHP et MySQL sont des technos à faire tourner sur un serveur web.

GoldenEye recherche apparemment des librairies C++ pour intégrer ça dans un logiciel.

[Ti-R]

Pour un Quake like ou un Monopoly like, je pense aussi que Corba, c'est peut être trop.

Mais si tu maîtrises très bien cette techno, pourquoi pas !

De mon point de vue, il y a "peu de chose" à échanger dans un FPS ou un monopoly. Quelques coordonnées, divers autres éléments, rien de très complexe à échanger, donc de l'extérieur, je vois peu l'utilité de Corba.

[IrmatDen]

Salut,

Je recommanderais plutôt UDP selon l'usage. Pourquoi?
* les opinions sur Corba ont déjà été données
* TCP ne conviendra pas pour un Quake like: trop de problèmes de vitesse (pour un monopoly like par contre, pas de soucis )

Edit: et pour la lib, tu peux regarder du côté de Raknet qui a atteint une certaine réputation sur le sujet

[GoldenEye]

Désolé pour le retard dans mes réponses, pas d'internet aujourd'hui :-)
J'ai déjà fait joujou avec des sockets bloquantes mais en mode multithread
Ce serait peut-être intéressant de regarder ce qui se fait en UDP dès lors que l'on transbahute des données pour lesquelles ce n'est pas trop grave d'en perdre un peu (positions d'ennemis), je prends note
Par contre pour du Monopoly, il faut bien être en TCP pour être certain que chaque client a la bonne vision du jeu avant de jouer son tour ?
Existe t'il d'autres méthodes à part
- Corba et autres middlewares
- sockets TCP-IP
le tout pour du C++ bien sûr !

Merci beaucoup en tout cas

[IrmatDen]

Par contre pour du Monopoly, il faut bien être en TCP pour être certain que chaque client a la bonne vision du jeu avant de jouer son tour ?

En UDP, ça reste possible, mais c'est une perte de temps puisque les mécanismes nécessaires sont déjà implémenté en TCP au niveau du protocole. Donc oui, pour un tel jeu, le TCP sera plus adapté et plus simple.

[nouknouk]

Existe t'il d'autres méthodes à part
- Corba et autres middlewares
- sockets TCP-IP
le tout pour du C++ bien sûr !

Techniquement, non: on se base toujours sur le TCP (90% du temps) ou de l'UDP (lorsque les contraintes temps réel sont fortes).

il te reste surtout à décider si tu veux refaire une lobrairie complète en partant de rien (ou si peu: les sockets fournies par ton OS), ou bien si tu préfères t'appuyer sur un framework déjà existant. Cela en fonction de tes connaissances, de ton temps disponible, de ton intérêt à apprendre de nouvelles choses (dév réseau), etc...

si tu veux t'appuyer sur quelque chose déjà fait, tu peux regarder du côté du net pour des librairies open source :

- légères, qui vont te fournir uniquement les fonctionnalités de base dont tu as besoin pour le réseau

- plus généralistes, qui te founrniront - en plus d'autres choses - une API réseau. exemple Qt qui offre plein d'autres choses genre GUI, intégration OpenGL, portabilité Win, Linux, MacOS (n'est-ce pas irmatDen )

[IrmatDen]

- plus généralistes, qui te founrniront - en plus d'autres choses - une API réseau. exemple Qt qui offre plein d'autres choses genre GUI, intégration OpenGL, portabilité Win, Linux, MacOS (n'est-ce pas irmatDen )

Je ne vois pas de quoi tu parles

Concernant les libs réseaux, j'ai déjà cité RakNet, mais boost.asio est aussi disponible (et boost oblige, il doit y avoir un seuil de qualité plutôt haut, mais pas forcément adapté aux jeux). Pour donner un avis, je passe mon chemin par contre, c'est juste des libs à tester un jour...

[Mat007]

Salut,

La FAQ de GameDev.Net résume relativement bien le consensus général.
Personnellement je pense que beaucoup se jettent un peu vite sur UDP et que TCP utilisé correctement fonctionne beaucoup mieux que ce qu'on se laisse croire...

MAT.

[IrmatDen]

Personnellement je pense que beaucoup se jettent un peu vite sur UDP et que TCP utilisé correctement fonctionne beaucoup mieux que ce qu'on se laisse croire...

Tu aurais plus d'infos là dessus pour justifier cet avis ? J'imagine trèèèès mal TF2, ET:QW ou UT3 fonctionner en TCP :/

[nouknouk]

Personnellement je pense que beaucoup se jettent un peu vite sur UDP et que TCP utilisé correctement fonctionne beaucoup mieux que ce qu'on se laisse croire...

Je suis globalement d'accord avec Mat007 (si j'ai bien compris le sens de sa phrase): en effet, il ne dit pas ici que l'UDP ne sert à rien et que tout ce que l'UDP peut faire, le TCP le fait aussi bien ; il dit que les développeurs ont parfois tendance à trop surestimer leurs contraintes temps-réel, et s'orientent dès le départ vers l'UDP alors que le TCP aurait pu suffire.

Autant du temps des modems RTC (56k et compagnie), le TCP récupérait une proportion non négligeable de fautes de transmission (paquets perdus, détruits faute de congestion, altérés, désorganisés, ...), autant maintenant ce n'est plus vraiment vrai.

N'oublions pas que la qualité des réseaux actuelle est telle (surtout en France), que le pourcentage des paquets altérés est devenue très faible ; de même, l'augmentation des débits des connexions font que l'utilisateur est de moins en moins en situation de saturation de sa bande passante (cause de perte de paquets principale).

Un exemple parlant: une application qui "par essence" semble avoir un besoin impératif de l'UDP : Skype et la transmission de la voix.
Si on y regarde de plus près, on peut se rendre compte que dans certains cas (ordi NATé & derrière un firewall 80+443), Skype utilise tout bêtement le TCP (encapsulé dans de l'HTTP qui plus est). Et ça fonctionne tout de même très bien.

Bien entendu, il reste quelques domaines où l'UDP doit être la règle ; les FPS en sont un bon exemple.

Mais pour moi l'idée de base - si on n'est pas tout à fait familiarisé avec le réseau - est plutôt de commencer par utiliser TCP (plus facile à implémenter) pour un premier 'jet' et ne se tourner vers l'UDP qu'ensuite, et uniquement si on constate que le TCP est insuffisant (et qu'on a bien prouvé que le problème venait de là )

My 2 cents.

[IrmatDen]

Exprimé ainsi, c'est plus clair pour ma caboche

[Djakisback]

Salut,
un peu hors-sujet mais je me pose une question, est-ce qu'on est pas obligé d'utiliser les 2 dans le cas d'un fps, UDP pour les déplacements, TCP pour les tirs, à moins de gérer la vérification en manuel en UDP ?

[nouknouk]

un peu hors-sujet mais je me pose une question, est-ce qu'on est pas obligé d'utiliser les 2 dans le cas d'un fps, UDP pour les déplacements, TCP pour les tirs, à moins de gérer la vérification en manuel en UDP ?

Je ne suis pas expert en framework réseau pour FPS, mais il est certain qu'on a bien les deux besoins:
- des flux "non sécurisés" pour les données à fortes contraintes temps-réel (déplacement des joueurs)
- des flux "sécurisés" pour les données importantes (je ramasse un objet, le joueur a perdu x points de vie, ...).

Comme tu l'as fait remarquer, les 'services' supplémentaires que propose TCP peuvent très bien être implémentés 'à la mano' au dessus d'UDP. Même si ça représente une charge de travail supplémentaire de développement, je pense que la voie choisie par les éditeurs de FPS est du "tout UDP avec des mécanismes maison de sécurisation de certains flux" (et donc avec une implémentation à la mano de techniques de sécurisation de certains flux).

Quelques idées qui me font pencher dans ce sens:

- utiliser un seul protocole augmente les chances que les flux empruntent le même chemin dans le réseau, et donc augmente la probabilité pour que les flux soient globalement synchronisés entre eux.

- utiliser un seul protocole permet de n'utiliser qu'un seul port sortant pour le client. Cela permet de ne pas avoir à demander à l'utilisateur final de rediriger plusieurs ports sur son routeur ni d'ouvrir plusieurs ports sur son firewall.

Ceci dit, ce dernier post n'est que mon opinion est basée sur mon expérience en dév. réseaux, et mon intuition (forte). Le mieux serait de vérifier, car il se peut que j'aie tort. Il doit bien y avoir des développeurs de FPS dans le coin... John Carmack ne surferait pas sur developpez.net par hasard ?

[IrmatDen]

La lecture de la page Source Multiplayer Networking chez Valve devrait répondre à quelques questions

En fait, il faut considérer que tout les flux sont important, du moins, dans un FPS sérieux, pas un fait avec des potes pour s'amuser sans se prendre la tête sur ces problèmatiques. L'orientation, la position, etc... du joueur est absolument cruciale.

[Djakisback]

Merci pour les réponses et le lien très instructif

[GoldenEye]

Super intéressant ce débat, merci pour vos réponses
Je n'ai pas l'ambition de faire un FPS mais la problématique est aisément généralisable à un autre type de jeu (RTS, course de voiture, sport, etc...)