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.