Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 7 sur 7
  1. #1
    Membre habitué
    Inscrit en
    octobre 2009
    Messages
    132
    Détails du profil
    Informations forums :
    Inscription : octobre 2009
    Messages : 132
    Points : 123
    Points
    123

    Par défaut [RTS] Une question de temps

    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.

  2. #2
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 161
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 161
    Points : 76 204
    Points
    76 204

    Par défaut

    Bonjour,

    Citation Envoyé par Fax37 Voir le message
    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

    Citation Envoyé par Fax37 Voir le message
    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)

    Citation Envoyé par Fax37 Voir le message
    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 )

    Citation Envoyé par Fax37 Voir le message
    Je vous tiendrai évidemment au courant de mes tests.
    Oui

    Citation Envoyé par Fax37 Voir le message
    Merci.
    De rien
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  3. #3
    Membre habitué
    Inscrit en
    octobre 2009
    Messages
    132
    Détails du profil
    Informations forums :
    Inscription : octobre 2009
    Messages : 132
    Points : 123
    Points
    123

    Par défaut

    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.

  4. #4
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 161
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 161
    Points : 76 204
    Points
    76 204

    Par défaut

    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 )
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  5. #5
    Membre habitué
    Inscrit en
    octobre 2009
    Messages
    132
    Détails du profil
    Informations forums :
    Inscription : octobre 2009
    Messages : 132
    Points : 123
    Points
    123

    Par défaut

    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...

  6. #6
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 161
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 161
    Points : 76 204
    Points
    76 204

    Par défaut

    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
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  7. #7
    Membre habitué
    Inscrit en
    octobre 2009
    Messages
    132
    Détails du profil
    Informations forums :
    Inscription : octobre 2009
    Messages : 132
    Points : 123
    Points
    123

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •