Discussion :

[Davidbrcz]

Plop all.
En grand noob que je suis dans la réalisation de jeux 3D et réseaux (comprendre que j'ai seulement fait du jeu 2D mono joueur), je me pose une question fondamentale étant donné que je souhaite réaliser un petit jeu (en 3D et en réseau )

Dans un jeu en réseau, qui réalise les calcules ? Les clients, le serveur ?

L'avantage du serveur, c'est que les calculs sont centralisés et les clients sont légers. En effet, le serveur calcul, les clients affichent et tout est synchronisé facilement. Problème, le serveur doit être une bête de course.

Avec les clients qui calculent, le serveur n'est plus qu'une plateforme tournante. Dans ce cas, n'importe quel PC peut faire office de serveur mais les clients doivent être plus lourd et le risque de désynchronisation entre les clients est plus grand.

Le mieux serai un système de load balancing, mais bon, je débute

Alors, vos avis ?

[nouknouk]

L'avantage du serveur, c'est que les calculs sont centralisés et les clients sont légers. En effet, le serveur calcul, les clients affichent et tout est synchronisé facilement. Problème, le serveur doit être une bête de course.

Non, le véritable problème, c'est la latence, ie. le temps qu'il faut pour qu'un client x envoie les données au serveur (typiquement l'action du joueur x, genre "je me déplace d'un pas en avant") + le temps que le serveur transmette les données de x aux autre clients, avec éventuellement les résultats des calculs qu'il a fait lui même.

Dans un réseau local (deux ordis connectés entre eux via un simple switch par exemple), le temps d'aller retour d'un paquet de données (client => serveur + serveur => clients, appelé Round Time Trip, ou RTT) sera inférieur à 5ms. Dans ce cas idéal, aucun souci: ton approche pourait éventuellement fonctionner.

Par contre, dès que tu vas vouloir jouer sur internet, la latence va dramatiquement augmenter pour passer de quelques ms à quelque chose entre 60ms et 400ms. En d'autres termes, ça voudrait dire qu'entre le moment où le joueur x effectue son action et le moment où l'action va réellement être affichée, il va s'écouler entre 60ms et 400ms. C'est inacceptable dès qu'on parle d'un jeu autre qu'un jeu en tour par tour (genre jeu de carte).

Je te passe les autres soucis inhérents aux transmissions sur internet (perte de paquets, gigue (ie. variation de la latence) et limitations en bande passante) qui accentuent les contraintes et ne sont surtout pas à négliger non plus.

Avec les clients qui calculent, le serveur n'est plus qu'une plateforme tournante. Dans ce cas, n'importe quel PC peut faire office de serveur mais les clients doivent être plus lourd et le risque de désynchronisation entre les clients est plus grand.

Si seulement les clients font les calculs, tu as deux autres soucis qui pointent le bout de leur nez:

- les situations de conflits: exemple de trois joueurs dans un FPS: x tire sur y qui lui même tire sur z.
* Dans le monde de x, il a tiré sur y qui est mort. z est toujours vivant.
* Dans le monde de y, il a tiré sur z juste avant de recevoir une balle de x (l'information du tir de x ne lui est parvenue que quelques instants après son propre tir). z est mort d'abord ; y est lui-même mort ensuite.

On en est arrivé à une situation incohérente entre les trois clients: dans un cas on a un seul mort ; dans l'autre on en a deux. Qui a raison, qui a tort ? Sans un serveur qui joue le rôle de l'arbitre au milieu, pas moyen d'avoir une réponse définitive en un temps court.

- la triche : si seul les clients font les calculs et qu'un client dit par exemple que son joueur n'est pas mort, le serveur n'a aucun moyen de le vérifier. Si le client est en fait une version modifiée de ton jeu destinée à tricher, ça peut poser un souci pour par exemple établir des high-scores, etc...

Dans un jeu en réseau, qui réalise les calcules ? Les clients, le serveur ?

La réponse est complexe et dépend beaucoup du type de jeu que tu comptes programmer. Un FPS, un RTS et un jeu de cartes ont tous les trois des besoins en terme de réseaux totalement différents, et leur brique réseau est donc à chaque fois radicalement différente.

Il y a pas mal de bons papiers sur le sujet (généralement en Anglais) sur le web. Je posterai quelques liens si j'arrive à mettre la main dessus. En attendant, quelques recherches sur le forum (tcp, udp, latence, perte de paquets, gigue, dead reckoning, ...) devraient t'offrir quelques bonnes bases ... au moins pour comprendre à quel point les jeux d'action en réseau c'est pas un sujet simple.

EDIT: un premier lien, une mine d'infos sur la façon dont le réseau est géré dans le moteur réseau de CounterStrike. Il faut fouiller un peu, mais il y a des parties qui valent vraiment le coup (genre ça).

[Davidbrcz]

Merci beaucoup nouknouk de cette réponse même si elle fait un peu peur .

Par contre, dès que tu vas vouloir jouer sur internet, la latence va dramatiquement augmenter pour passer de quelques ms à quelque chose entre 60ms et 400ms. En d'autres termes, ça voudrait dire qu'entre le moment où le joueur x effectue son action et le moment où l'action va réellement être affichée, il va s'écouler entre 60ms et 400ms. C'est inacceptable dès qu'on parle d'un jeu autre qu'un jeu en tour par tour (genre jeu de carte).

Ouais, je connais ca du coté user.
A: "Arf, head shoot, lag de merde"
B: "Non cherche pas t'es nul en fait"

Je te passe les autres soucis inhérents aux transmissions sur internet (perte de paquets, gigue (ie. variation de la latence) et limitations en bande passante) qui accentuent les contraintes et ne sont surtout pas à négliger non plus.

Je m'en doute. Mais j'avais lu que dans certain jeux, une perte de paquets de temps à autre n'était pas génant.

- les situations de conflits: exemple de trois joueurs dans un FPS: x tire sur y qui lui même tire sur z.
* Dans le monde de x, il a tiré sur y qui est mort. z est toujours vivant.
* Dans le monde de y, il a tiré sur z juste avant de recevoir une balle de x (l'information du tir de x ne lui est parvenue que quelques instants après son propre tir). z est mort d'abord ; y est lui-même mort ensuite.

On en est arrivé à une situation incohérente entre les trois clients: dans un cas on a un seul mort ; dans l'autre on en a deux. Qui a raison, qui a tort ? Sans un serveur qui joue le rôle de l'arbitre au milieu, pas moyen d'avoir une réponse définitive en un temps court.

bah suffit de mettre un compteur de temps et de voir qui à fait en premier

- la triche : si seul les clients font les calculs et qu'un client dit par exemple que son joueur n'est pas mort, le serveur n'a aucun moyen de le vérifier. Si le client est en fait une version modifiée de ton jeu destinée à tricher, ça peut poser un souci pour par exemple établir des high-scores, etc...

C'est loin d'être mon problème numéro 1. Et ca peut se régler avec l'envoie de la somme MD5 de l'éxécutable avant de jouer.

La réponse est complexe et dépend beaucoup du type de jeu que tu comptes programmer. Un FPS, un RTS et un jeu de cartes ont tous les trois des besoins en terme de réseaux totalement différents, et leur brique réseau est donc à chaque fois radicalement différente.

Je compte faire une sorte de mini-clone de MechWarrior (un FPS où l'on dirige des robots géants à la Transformer)

Il y a pas mal de bons papiers sur le sujet (généralement en Anglais) sur le web. Je posterai quelques liens si j'arrive à mettre la main dessus. En attendant, quelques recherches sur le forum (tcp, udp, latence, perte de paquets, gigue, dead reckoning, ...) devraient t'offrir quelques bonnes bases ... au moins pour comprendre à quel point les jeux d'action en réseau c'est pas un sujet simple.

EDIT: un premier lien, une mine d'infos sur la façon dont le réseau est géré dans le moteur réseau de CounterStrike. Il faut fouiller un peu, mais il y a des parties qui valent vraiment le coup (genre ça).

Merci beaucoup, je ne connaisais pas, si tu en as d'autres comme ca .

[nouknouk]

Merci beaucoup nouknouk de cette réponse même si elle fait un peu peur .

C'était en partie le but: le réseau, qui plus est pour un FPS, c'est extrêmement compliqué.

Et vouloir se lancer là dedans quand on est un débutant complet, c'est pas loin de l'Evrest pour un unijambiste: c'est pas impossible, mais ça reste l'exception ... et dans tous les cas, le gugus mettra énormément de temps pour arriver à son but.

Je m'en doute. Mais j'avais lu que dans certain jeux, une perte de paquets de temps à autre n'était pas génant.

Pas gênant pour le gameplay, oui.
Mais ça ne veut pas dire que ce qui a été programmé dans le code du jeu pour palier à ces pertes de paquets est simple.
C'est plutôt tout le contraire !

C'est loin d'être mon problème numéro 1. Et ca peut se régler avec l'envoie de la somme MD5 de l'éxécutable avant de jouer.

Lis l'article dans mon deuxième lien, et tu comprendras qu'il y a mille et une façon de pirater un client (genre hack indécelables côté serveur de type man-in-the-middle).
D'où l'assertion bien connue qu'on ne peut jamais raisonnablement faire confiance à un client. Et d'où l'expression bien connue qui résume à peu près tout "never trust the client"

Merci beaucoup, je ne connaisais pas, si tu en as d'autres comme ca .

Pas sous la main, mais google en a plein, c'est sur

EDIT: tiens, encore un lien (en français en plus) que j'ai trouvé en quelques minutes sur le forum.

[Davidbrcz]

Et vouloir se lancer là dedans quand on est un débutant complet, c'est pas loin de l'Evrest pour un unijambiste

Oui, je vois bien. Dans ce cas, comment prendre du galon ? En faisant des petits jeux en réseau avant ?

Lis l'article dans mon deuxième lien, et tu comprendras qu'il y a mille et une façon de pirater un client (genre hack indécelables côté serveur de type man-in-the-middle).
D'où l'assertion bien connue qu'on ne peut jamais raisonnablement faire confiance à un client. Et d'où l'expression bien connue qui résume à peu près tout "never trust the client"

Ouais, enfin si les gens veulent tricher c'est leur problème aussi :p.

Pas sous la main, mais google en a plein, c'est sur

Avec quelle genre de requête ? Car toutes celles que j'ai faite me renvoit à des liens minables.

EDIT: tiens, encore un lien (en français en plus) que j'ai trouvé en quelques minutes sur le forum.

Thanks

[nouknouk]

Oui, je vois bien. Dans ce cas, comment prendre du galon ? En faisant des petits jeux en réseau avant ?

En commençant par des jeux en réseau qui ont le moins de contraintes réseau (temps réel principalement). C'est ypiquement les jeux du type "tour par tour" (jeu d'échec, jeu de carte, jeu de société, ...). Tu pourras évoluer petit à petit vers des types de jeux où les contraintes réseaux sont de plus en plus fortes
[MYLIFE](c'est typiquement ce que j'ai fait ... et pourtant j'ai un diplôme d'ingé. télécom en poche)[/MYLIFE].

Ouais, enfin si les gens veulent tricher c'est leur problème aussi :p.

Non, c'est le problème de tout le monde. Si tu proposes un endroit centralisant la liste des parties disponibles et si dans ces parties il y a 50% de tricheurs, le joueur 'lambda' va très vite délaisser ton jeu.

Avec quelle genre de requête ? Car toutes celles que j'ai faite me renvoit à des liens minables.

avec entres autres les mots clefs de mon premier message ... et bien sûr une dose de méthode et de patience évidemment.

[Davidbrcz]

En commençant par des jeux en réseau qui ont le moins de contraintes réseau (temps réel principalement). C'est ypiquement les jeux du type "tour par tour" (jeu d'échec, jeu de carte, jeu de société, ...).

Tu pourras évoluer petit à petit vers des types de jeux où les contraintes réseaux sont de plus en plus fortes

J'ai un plateaux fini qui traine sur mon DD. Mais comment veut tu évoluer vers des contraites de plus en plus forte ? Soit c'est tour par tour, au quel cas les contraintes sont quasi nulle, au temps réel où les contraites sont très fortes. Je en vois pas d'entre deux.

Non, c'est le problème de tout le monde. Si tu proposes un endroit centralisant la liste des parties disponibles et si dans ces parties il y a 50% de tricheurs, le joueur 'lambda' va très vite délaisser ton jeu.

Avant de m'attaquer à la triche, il faut que je finisse mon jeu et qu'il ait du succès .

[nouknouk]

Soit c'est tour par tour, au quel cas les contraintes sont quasi nulle, au temps réel où les contraites sont très fortes. Je en vois pas d'entre deux.

- tu peux faire des jeux en tour par tour où pendant le tour de chaque joueur tu as une partie de temp réel, un worms-like par exemple. Ca introduit la notion de synchronisation temporelle entre chaque client et le serveur.

- tu peux ensuite continuer avec du jeu plus 'temps réel' mais moins contraint qu'un FPS, genre un RTS (tiens, un lien supplémentaire).

- etc...

Avant de m'attaquer à la triche, il faut que je finisse mon jeu et qu'il ait du succès

Pourquoi pas, mais c'est amha un risque car l'ensemble doit en règle générale être pensée comme un tout.
De la même façon que pour un jeu qui n'est pas conçu dès le départ pour être joué en réseau, le risque est d'avoir à réécrire la quasi totalité de la brique réseau le jour où tu voudras implémenter des techniques anti-triche.

[screetch]

le meilleur moyen (jusqu'a présent) c'est :
- le serveur fait les calculs, et c'est lui qui a raison (si un client n'est pas d'accord... il devra utiliser la position corrigée, tant pis pour lui)
- le client envoie ses données puis applique lui aussi les calculs pour prédire ce qui va se passer

le serveur et le client sont dans des echelles de temps différent; le serveur recoit des informations du passer, le client essaye de prédire ce que le serveur va renvoyer (l'avenir)

il n'empeche que lorsque tu vois quelque chose sur ton ecran, le serveur ne voit pas la meme chose mais la, c'est le client qui doit gagner.
Le client a prédit que grosso modo le joueur se trouvait a cet endroit a l'instant T, il tire dessus
a l'instant T+40, le serveur recoit l'info de tir. C'est LUI qui doit decider si le joueur a été touché ou pas.
Mais il sais que le client n'est pas a l'instant T+40, il sait que le client a tiré a l'instant T. il vérifie alors la position du joueur a T, puis renvoie l'info.
a T+80 tu as la confirmation/l'infirmation "as tu touché le joueur a l'instant T". en attendant tu ne peux que "prédire" ce qui se passe "si tu as toute les infos"

[yamashi]

Deja, tu as le choix du protocole qui est tres importants.
il faut que tu te poses les questions suivantes :
1) Est-ce que c'est une information cruciale ? si oui (protocole d'authentification) -> TCP, autrement -> 2
2) Est-ce que l'ordre est important ? si oui (commande joueur) -> TCP, autrement -> 3
3) Est-ce que l'information subit des mises a jour frequentes ? si non préférer TCP, si oui (position d'un joueur) -> 4
4) Est-ce que la vitesse est un facteur important ? si oui -> UDP, si non -> 5
5) Est-ce que je risque d'encombrer le reseau de paquet UDP ? si oui -> TCP, si non -> UDP

Une fois que tu as le protocole pour chaque paquet, il te faut travailler sur la synchronisation, le ping en lui même n'est pas forcément un problème, dis toi que dans le pire des cas le ping sera de 200 si la personne est de l'autre côté du globe. Si ton serveur et ton client ne sont pas synchronisés, tu ne pourras pas faire une prevision correcte, par synchroniser je veux dire que tu n'envoie pas 500 frame pendant 1 seconde et que la seconde d'apres tu en envoie 20...
Il faut essayer de garder les meme rates d'envoie aussi bien du côté client que du côté serveur.

Et générallement il faut faire les calcules côté client et serveur, les mêmes enfait, le serveur ne fait que valider et corriger le client.

[nouknouk]

le meilleur moyen (jusqu'a présent) c'est :
- le serveur fait les calculs, et c'est lui qui a raison (si un client n'est pas d'accord... il devra utiliser la position corrigée, tant pis pour lui)
- le client envoie ses données puis applique lui aussi les calculs pour prédire ce qui va se passer

le serveur et le client sont dans des echelles de temps différent; le serveur recoit des informations du passer, le client essaye de prédire ce que le serveur va renvoyer (l'avenir)

Super bien résumé
Le détail pouvant se trouver dans la publication de Valve à propos du Source Engine.

Une fois que tu as le protocole pour chaque paquet

Oui et non: on préfère en général ne pas mixer l'utilisation de plusieurs protocoles (TCP et UDP), les deux peuvent interagir et causer des soucis de pertes de paquets, retransmission, etc... Ca ajoute par ailleurs des contraintes supplémentaires pour réordonner l'information reçue ; les deux flux étant totalement disjoints.

Donc dans l'idéal soit on ne fait que du TCP en s'accomodant des contraintes qui en découlent, soit on ne prend que de l'UDP quitte à implémenter soi-même les mécanismes qui nous manquent (typiquement la garantie de réception des paquets 'importants').

le ping en lui même n'est pas forcément un problème, dis toi que dans le pire des cas le ping sera de 200 si la personne est de l'autre côté du globe.

Certainement pas. Un test utile te montrera que:

- le ping peut facilement monter à 350ms dans le cas d'un internaute éloigné et d'un backbone globalement chargé. Sur mon dédié OVH (physiquement en Belgique ; interconnexion considérée comme assez bonne en règle générale), les pays du pacifique sont systématiquement au dessus de 300ms ; l'Afrique du sud détient la palme avec 530ms.

- plus l'internaute est éloigné du serveur, plus la fréquence des pertes de paquets et l'importance de la gigue va se faire sentir, ça peut monter jusqu'à 20% chez moi.

Il faut essayer de garder les meme rates d'envoie aussi bien du côté client que du côté serveur.

Globalement il vaut mieux, mais il ne faut pas tomber dans l'extrême en voulant absolument avoir un flux constant. Au contraire, les techniques de dead reckoning et autres optimisations vont permettre de ne pas envoyer une portion des paquets quand la situation s'y prête. Donc la quantité de paquets envoyée va forcément varier au cours du temps.

Et générallement il faut faire les calcules côté client et serveur, les mêmes enfait, le serveur ne fait que valider et corriger le client.

+1, tant qu'on parle des calculs relatifs à 'la logique de jeu'. Evidemment, le serveur ne va pas perdre son temps à calculer des choses inutiles (effets visuels genre particules dans un monde 3D, ...).

Bonus: Des liens "mine d'or" qui renvoient vers d'autres liens (évidemment tout en Anglais):
- Gaffer on games - Game networking resources
- GameDev.net - multiplayer and networking

[yamashi]

plus l'internaute est éloigné du serveur, plus la fréquence des pertes de paquets et l'importance de la gigue va se faire sentir, ça peut monter jusqu'à 20% chez moi.

20% ?! J'avais plutôt entendu du 0.2% de nos jours...

le ping peut facilement monter à 350ms dans le cas d'un internaute éloigné et d'un backbone globalement chargé

Oui mais dans ces cas la tu joues sur un autre serveur, c'est comme quand tu vas sur un jeu du type counter strike ca ne te viendrais pas a l'idée d'aller jouer sur un serveur au japon...

[nouknouk]

20% ?! J'avais plutôt entendu du 0.2% de nos jours...

Mon chiffre se basait sur un test avec mon serveur dédié grâce au site justping.com (testé au moment où j'ai écrit mon post).
20% est le pire du pire des cas parmi l'ensemble des requêtes émises lors du test. Effectivement, en règle générale le taux de perte de paquets est inférieur à 1% ; l'idée que je voulais faire passer est que rien ne doit être considéré comme acquis dans un réseau 'best effort' comme internet et qu'il faut donc se préparer à toute éventualité ... et faire beaucoup de tests 'grandeur nature' au fur et à mesure du développement.

A noter également que l'essor des connexions wireless (3G, WiFi) peut faire remonter le taux d'erreurs de transmission qui avait tendance - ces dernières années - à baisser de façon sensible (cause passage du modem RTC vers l'ADSL) ainsi que la gigue (collisions de paquets entre un support physique dédié comme l'Ethernet filaire + switch à comparer à un support physique partagé (WiFi, ...).

Oui mais dans ces cas la tu joues sur un autre serveur, c'est comme quand tu vas sur un jeu du type counter strike ca ne te viendrais pas a l'idée d'aller jouer sur un serveur au japon...

Ca dépend de ton jeu.

Si tu fais un FPS comme Counter Strike et que chacun peut héberger sa partie, effectivement les joueurs privilégieront les parties où ils ont les meilleurs ping (*)

Si tu fais un MMO où n'importe quel autre jeu où le serveur est centralisé (ie. les joueurs ne peuvent pas héberger leurs propres parties, mais se connectent systématiquement au serveur de l'éditeur), les choses sont radicalement différentes.

(*) A noter également que dans le cas d'un jeu où chacun peut héberger des parties (et donc jouer le rôle de serveur), le choix du protocole de communication (UDP, TCP) peut avoir des conséquences sur la facilité pour un joueur de créer un serveur qui soit accessible par d'autres joueurs (cf. notions de NAT, redirection de ports, ...).

[Migosh59]

Tout d'abord désolé de déterrer un ancien post mais j'ai trouvé ça moins grave qu'en ouvrir un autre sur un sujet similaire.

J'envisage de développer un jeu de plateau type échecs multijoueur sur navigateur et j'hésite entre deux approches :

1ère approche : Les clients recoivent du serveur le dernier coup joué par l'autre joueur, ils ont la charge de calculer l'état du plateau en conséquences (les pièces à retirer dans l'exemple des échecs). Le serveur ne fait qu'enregistrer les coups et les transmettre.
Avantage : Cette approche permettrait de facilement revoir la partie, ou d'afficher n'importe quelle partie enregistrée sous un format normalisé directement dans le client.

2ème approche : Les clients recoivent du serveur l'état de la partie et ne font que l'afficher sans se poser de question, lorsqu'un coup est joué, c'est le serveur qui calcule l'état du plateau et le transmet.
Avantage : Cette approche permettrait un client plus léger.

Sachant que la technologie que j'ai choisie est GWT (2.0), quelle approche me conseilleriez vous ?
PS : j'ai bien lu le post et je comprends les avantages / inconvénients des deux solutions, je ne sais juste pas prévoir ce qui est préférable dans ce cas d'école simple.

[nouknouk]

salut,

premièrement, tu as tout juste: les deux solutions sont viables et le choix d'une plutôt que l'autre se fait plus sur des choses secondaires.

Concernant la première approche, il ne faut pas oublier que le serveur aura également la charge de vérifier que le coup joué est 'valide' (par exemple que le déplacement est en accord avec les déplacements autorisés par la pièce, que c'est bien à ce joueur là de jouer, que la pièce existe bien, que le roi n'est pas mis en échec, ...). Sinon, il serait très facile de 'hacker' le jeu.

Concernant la seconde approche, elle sera effectivement un peu plus légère côté client, mais ce que tu gagneras en lignes de code, tu le perdras sur un autre point qui est en règle générale le facteur limitant: la charge réseau et CPU du serveur: un paquet réseau contenant un seul coup est bien moins 'lourd' à générer et à envoyer qu'un plateau entier.

Perso, je penche pour la première approche ; après à toi de voir.

[Migosh59]

Merci, ça confirme ce que je pensais, ça m'aurait embêté, de devoir soliciter le serveur pour pouvoir "reculer" dans la partie pour revoir les coups précédents (ou rejouer la partie depuis le début pour les clients "spectateurs").

[bachir006]

meme avec la deuxieme approche, tu peux enregistrer les diffrents etats du plateau au fur et a mesur que la partie avance, et ansi pouvoir reculer sans solliciter le serveur.