Discussion :

[Fax37]

Je développe en ce moment un RTS multijoueur et je voudrais qu'il ne "lag" pas et que tout les clients recoivent bien les mêmes informations en même temps.

Je pensais tout d'abord utiliser une connexion client/serveur par socket, mais je ne sais pas du tout si le temps de réponse est satisfaisant ou si je dois me pencher sur une autre technologie??...

J'aimerais avoir votre avis sur la question avant que je ne commence le développement "dur" de mon jeu.

Je vous tiendrai évidemment au courant de mes tests.

Merci.

[LittleWhite]

Bonjour,

Je développe en ce moment un RTS multijoueur et je voudrais qu'il ne "lag" pas et que tout les clients recoivent bien les mêmes informations en même temps.

Impossible ... cela dépend de la position géographique du joueur, de la vitesse des différents routeur / relais , du FAI, des cables ... de la longueur ... du serveur ... pfu ... trop de facteurs. Internet ne peut jamais garantir la vitesse ... et même que certains paquets se perdent O_o

Par contre il existe des méthodes pour palier à ce problème:
- Synchronisation des horloge
- Tampon sur les messages
- Simulation du jeu client et chez le serveur.

On devrait pouvoir s'en sortir

Je pensais tout d'abord utiliser une connexion client/serveur par socket, mais je ne sais pas du tout si le temps de réponse est satisfaisant ou si je dois me pencher sur une autre technologie??...

Les sockets ... vous êtes un peu obligé (je ne connais pas grand chose d'autre), je pense donc que la question est mal posée. D'ailleurs la question c'est plus: "Quel protocole utilise t-on?" (TCP / UDP / ou autre)

J'aimerais avoir votre avis sur la question avant que je ne commence le développement "dur" de mon jeu.

Voilà j'en ai donné je coirs (vive mes cours de multiplayer de cette année ; merci à mes professeurs donc )

Je vous tiendrai évidemment au courant de mes tests.

Oui

Merci.

De rien

[Fax37]

Par contre il existe des méthodes pour palier à ce problème:
- Synchronisation des horloge
- Tampon sur les messages
- Simulation du jeu client et chez le serveur.

Voilà ce que je voulais entendre .

Synchronisation des horloges : J'imagine que l'information envoyé par le serveur peux contenir une variable de temps T0 que je pourrai comparer avec une variable côté client T1 qui se déclarera lors de la lecture de ladite information. Ca permettra de "rattraper" le retard (bien que je ne vois pas encore trop comment )

Tampon sur les messages : c'est surement ce que je viens d'expliquer au-dessus (j'imagine).

Simulation du jeu client et chez le serveur : Tu veux dire par là que le jeu anticiperait sans attendre les infos du serveur, et que donc, les messages du serveur ne seraient que des "confirmation" ou des ajustements?? Comme par exemple pour le déplacement des unités contrôlé par l'IA qu'il sera donc possible de "prévoir" côté client ET serveur.

On devrait pouvoir s'en sortir

Tu veux te joindre à moi?


Mon plus gros point faible est que je n'ai aucun "cours" sur lesquels m'appuyer étant donné que je ne suis pas du tout du métier. Donc par exemple, les protocoles à utiliser (TCP/UDP/...) je ne sais pas vraiment à quoi cela correspond ni les avantages qu'a l'un par rapport à l'autre. Mais je me renseignerai.

[LittleWhite]

La synchronisation des horloges:
Faire en sorte que les deux PCs sont synchonisé (s'il est 10h50:32 sur un, il est aussi 10h50:32 sur l'autre)
Le point c'est que cela n'est pas aussi facile à faire que cela puisse paraitre ... il y a des informations partout sur google à propos de cette technique (du moins en anglais)

Le tampon sur les messages:
Pour chaque message envoyé, l'ordinateur indique le temps "virtuel" de l'action. Le temps virtuel, c'est le temps du jeu.
Par exemple, au T=30 ... la joueur à déplacer son unité de ... à ...
Cela permet de faire la simulation de la même façon sur tout les PCs.

La simulation ... en fait est plus une technique anti triche ... mais aussi permettant de faire en sorte que le semble temps réel. Dans un FPS (je ne sais pas trop où dans un RTS cela peut être efficace, mais j'imagine que cela l'est), si un joueur tire sur son ennemi, le tir va être effectué, les bullets vont partir, l'ennemi pourra même être impacté (animation de dégats), par contre, pour savoir si l'ennemie est mort, c'est la simulation du serveur qui va confirmer. (Bon je résume le principe).
S'il fallait attendre tout le temps que le serveur confirme le tir, le déplacement des bullets ... et tout ... on surchargerai le réseau pour pas grande utilité ...

Et ... non je ne veux pas me joindre (manque de temps et tout et tout) mais je veux tout de même voir votre jeu

Pour les cours, tout est trouvable avec Google (ce sont des cours simple de réseau et de multiplayer ... même une lecture des RFC sur l'UDP / TCP peut aider )

[Fax37]

La simulation, si je comprends bien, c'est le fait que le jeu s'exécute de manière autonome sur le poste client, en envoyant régulièrement les informations importantes au serveur, qui les vérifie mais ne renvoi pas forcément de réponse.
Pour toutes les actions importantes (mort d'une unité par exemple ou action du joueur) le serveur va transmettre l'information à tout les clients.

Ca permet en effet de ne pas surcharger le réseau par des infos qui peuvent très bien être calculée côté client. Ce que j'ai du mal à comprendre c'est :
Si je tue une unité avec mon héros, je vais envoyer l'information au serveur qui va la confirmer ou l'infirmer. Si il la confirme, l'unité va être tué également sur le poste client de mon adversaire. Mais il faut pour cala que l'autre joueur ai vu que son unité se faisait attaquer et perdait de la vie...
C'est tout de même sacrément complexe ^^.

Je vais me payer du doliprane je le sent...

[LittleWhite]

Le multiplayer, c'est tout de meme compliqué.

Toutes les commandes doivent etre envoyées au serveur afin que l'on reproduise sur tous les clients la meme chose (une unite bleue qui se deplace devra se deplacer chez tous les clients et si possible, au meme moment)
Apres, le serveur doit verifier tout de meme ce que le serveur envoye (au cas ou que celui ci soit un tricheur)

Pour l'exemple du FPS, on peut imaginer qu'il y ait un premier tir qui blesse l'ennemi (accepter et reproduit chez les clients en questions), puis un tir qui tue. Enfin c'est une idee.

Bon courage

[Fax37]

Merci de ton aide.

De toute façon je n'y suis pas encore mais ca m'aide de comprendre la logique de la chose avant de la coder.

Si ça peut en aider d'autres qui sont dans la même situation que moi, je suggère ce thread tiré de la même section.