Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 4 sur 4
  1. #1
    Futur Membre du Club
    Profil pro Bastien Cramillet
    Inscrit en
    septembre 2010
    Messages
    55
    Détails du profil
    Informations personnelles :
    Nom : Bastien Cramillet
    Âge : 25

    Informations forums :
    Inscription : septembre 2010
    Messages : 55
    Points : 18
    Points
    18

    Par défaut [Conception] Avis sur architecture réseau

    Bien le bonjour !

    Aujourd'hui j'ai besoin de vos avis, conseils et critiques sur une architecture réseau.

    Contexte : Je bosse sur mon propre moteur de jeu 2D (classique ces jours ci), utilisant la SFML comme base principale, ainsi que Box2D pour la physique, entre autres ...

    Je souhaite intégrer une couche réseau à ce moteur et cette partie me semble clairement être l'une des plus caduques de ce type de projet. Je vais donc vous exposer mes idées et j'espère avoir des retours constructifs de votre part afin de corriger mes erreurs.

    Voilà grossièrement comment j'imagine la chose :

    Une séparation distincte entre la partie "vue" (affichage, son, gestion des entrées clavier, etc), et la partie "modèle" (traitements sur les composants du jeu, simulation physique, etc).

    Du côté serveur, seule la partie Modèle existerait, afin de centraliser les traitements sur le modèle et permettre la communication entre les différents clients.

    Du côté client, les deux parties existeraient. Bien évidemment la partie Vue étant nécessaire pour qu'un joueur puisse apprécier le déroulement d'une partie, mais aussi la partie Modèle.

    Avoir la partie Modèle à la fois dans le serveur et dans le client ayant pour objectif de palier aux problèmes de latence dues au réseau et de "pré" simuler et mettre à jour une scène de jeu. Le serveur viendrait corriger le modèle d'un client dans le cas où un évènement non connu du client à un moment t serait survenu et modifierait le déroulement du jeu.

    Ainsi j'imagine un système permettant de stocker les évènements (genre "déplacement de l'élément E en position x,y") sur plusieurs itérations de sorte à ce que le client puisse vérifier la justesse de ses simulations et les corriger au cas où.

    Tout ce bazar permettant au joueur sur son client de jouer de façon fluide et de ne pas avoir à attendre sur la simulation faite par le serveur pour voir affiché le résultat.

    Néanmoins, quelque chose me dit que cette méthode peut être très lourde et nécessiterait une vérification complète du modèle à une certaine fréquence pour être sur que tous les clients évoluent sur l'exacte même base.

    Enfin bref, voilà mes premières idées quant à la conception de la couche réseau de mon moteur. Qu'en pensez vous ?

    Merci d'avance pour vos commentaires =)

  2. #2
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    décembre 2006
    Messages
    1 622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34

    Informations forums :
    Inscription : décembre 2006
    Messages : 1 622
    Points : 1 951
    Points
    1 951

    Par défaut

    Salut,

    je pense que plutôt que vouloir vérifier les résultats des calculs sur ton modèle, il serait plus simple et moins 'couteux' de vérifier les données en 'input' de ton modèle qui ont conditionné les calculs. En effet, si les clients ont la même physique et les mêmes règles d'interaction, les données en entrées suffisent pour être capable de garantir que le résultat sera identique pour tous à la fin, juste en ayant les mêmes données en entrée au départ (sauf si tu tournes sur des archis CPU différentes genre ARM et x86, pour le calcul flottant, mais ce n'est visiblement pas ton cas)

    Dit autrement, si tu as un joueur qui rentre en collision avec un empilement d'une dizaine de caisses, plutôt que de vérifier que la trajectoire de chaque caisse après la collision est correcte, il vaudrait mieux vérifier que les clients ont bien prédit le point de collision entre le joueur et la pile de boites.

    - Si ça a été bien prédit (ou reçu à temps), c'est le cas idéal, il n'y a rien de plus à faire.

    - Si la prédiction était incorrecte, le client peut alors repartir un peu en arrière dans le temps, recalculer le modèle 'de référence', le comparer à son modèle 'prédit erronné' et décider de comment faire la réconciliation au niveau de la vue pour que ça ne choque pas trop le joueur devant son écran.

    My 2 cents.
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  3. #3
    Futur Membre du Club
    Profil pro Bastien Cramillet
    Inscrit en
    septembre 2010
    Messages
    55
    Détails du profil
    Informations personnelles :
    Nom : Bastien Cramillet
    Âge : 25

    Informations forums :
    Inscription : septembre 2010
    Messages : 55
    Points : 18
    Points
    18

    Par défaut

    Merci à toi pour ces éclaircissements. Je pense que je vais pouvoir bien plus facilement aborder cette partie de mon projet maintenant =)

  4. #4
    Membre régulier
    Homme Profil pro
    Architecte serveur
    Inscrit en
    septembre 2011
    Messages
    58
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte serveur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2011
    Messages : 58
    Points : 84
    Points
    84

    Par défaut

    J'apporterai quelques corrections pour ma part.

    Faire les calculs côté client est une bonne chose, surtout sur un jeu en temps réel, parce qu'attendre un ping avant d'avoir validation d'un déplacement, ça se sent, même pour des pings de l'ordre de 50ms (je parle pas de ping plus bas pour lesquels ton jeu deviendrait injouable).
    Faire les calculs côté serveur est obligatoire si tu souhaites éviter toute forme de hack. Sinon, effectivement, tu peux faire comme conseille Nounouk, ie faire tous les calculs côté client, et t'affranchir de la vérif du serveur.

    Revenir en arrière est une super mauvaise idée. Ca demande basiquement de faire un undo sur chaque action client. Autant sur un déplacement c'est possible (tu décalles le gars progressivement, ça se sent pas trop), autant sur, par exemple, la prise d'un objet c'est impossible. Si le son de prise de l'objet est déjà parti et que le joueur se retrouve sans l'objet, il va gueuler au bug.
    Donc pour toutes les actions sur lesquelles il peut y avoir interaction avec un autre joueur, il faut que tu attendes une vérif serveur. En gros, le client envoie le message au serveur, et attend la réponse du serveur (basiquement, le même message dispatché à tous les clients) pour faire le calcul. Ainsi, si un autre joueur a pris l'objet juste avant toi, tu reçois son message de prise d'objet avant le tien (voir uniquement le sien si tu fais une vérif serveur).

    Voila.

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
  •