←

JEU VIDEO

LEVEL 1 « SENSIBILISATION »

Notion essentielle : Le réseau

Réseau

Intro

  • Plusieurs joueurs éloignés physiquement
  • Environnement de jeu cohérent
  • Interactions immédiates entre les joueurs
  • Environnement de jeu évolutif fluide

Contraintes

  • Performance réseau
    • temps de latence
      100 ms = perçue comme instantanée
      => 10 paquets par seconde
    • Bande passante
      1 mbps => 128 Kb, ~ 13000 octets pour chaque paquet
  • Synchronisation

Réseau - Architectures

  • a. Noeud seul
  • b. Peer-to-Peer
  • c. Client / serveur
  • d. Réseau de serveurs

Architecture Peer-to-peer

Stratégie : Peer-to-Peer Lockstep

  • Découper le jeu en tour par tour
  • Tous les clients synchronizent leurs commandes et jouent le tour localement
  • Un serveur joue les tours de la même façon et sert de référence en cas de conflit
  • Nécessite des tours de jeux déterministes
  • Nécessite d'attendre toutes les commandes avant de pouvoir jouer un tour

Architecture : Client / Serveur

Stratégie : Client / Serveur pure

  • Un serveur maintient l'état du jeu à jour en temps réel
  • Tous les clients envoient les commandes des joueurs
  • Le serveur distribue les évolutions de l'état à tous au fur et à mesure
  • Les clients affichent les états envoyés par le serveur

Architecture : Client / Serveur

Stratégie : Client-side prediction

  • Idem qu'en mode pure, mais prédictions côté client
  • Le serveur reste authorité
  • Permet de masquer les temps de latence

Architecture : Réseau de serveurs

  • Appliquer la stratégie peer-to-peer ou Client / Server à plusieurs noeuds serveurs

Réseau - Données

Données centralisées

Pour les données critiques, non déterministes

Données dupliquées

Pour les données déterministes, simulées, partagées

Données réparties

Pour les données locales (prédictions) ou personelles (infos joueur), non déterministes

Réseau - Protocole

TCP

  • Authentifié (les nœds établissent une connexion)
  • Fiabilité (pas de perte de paquet)
  • Ordonné (les paquets arrivent dans l'ordre)
  • En flux (stream) (les paquets sont découpés automatiquement)

UDP

  • Envoi de paquet brut vers une [IP]:[Port]
  • Non connecté
  • Pertes possible
  • Désordre possible
  • Les paquets peuvent arriver incomplets

Pour les jeux vidéo ?

  • En TCP, le stream part quand assez de données est prêt à partir.
    => Délai des données avant envoi. Option TCP_NODELAY.
  • En TCP, la robustesse et l'ordonnancement sont gérés par des ACK et renvois.
    => En cas de pertes de nombreux allez-retours sont nécessaires
  • Contraintes de temps réel rends TCP inutilisable.

Pour les jeux vidéo : UDP

  • La fiabilité comme surcouche de UDP (quand nécessaire)
  • L'ordonnancement comme surcouche de UDP (quand nécessaire)
  • authentification et sécurisation comme surcouche de UDP (quand nécessaire)
  • UDP + TCP ? => interférences

Equation du principe de l'information

Ressources nécessaires = M × H × B × T × P
  • M le nombre de messages transmis,
  • H le nombre moyen de nœuds recevant le message,
  • B la quantité moyenne de bande passante nécessaire pour chaque message,
  • T la rapidité de prise en charge nécessaire pour le message (Une grande valeur de T nécessite un délai de traitement très court),
  • P le nombre de cycles processeurs nécessaires pour recevoir et traiter chaque message.

Compression

  • Augmenter P pour réduire B
  • Sans perte (lossless)
  • Avec perte (lossy)

Sans perte

  • Algorithmes de compression
  • Utiliser des deltas plutôt que des valeurs
  • Agrégation des messages (diminue M et T, augmentation moindre de B et P)

Avec perte

  • Réduire la précision
    Ex: encoder un angle (double, 4 octets) en half-float ou small (1 octet, 256 valeurs)
  • Filtrer / Décaler les informations moins prioritaires
  • Prédiction

Stratégie : Prédiction côté client

Anticiper côté client le résultat d'un calcul non reçu.
Anticiper côté client le résultat d'un input non envoyé.
Maintenir les états passés côté serveur pour le réécrire en rejouant les inputs a posteriori

Extrapolation

  • dérivée d'ordre 1 pour des mouvements très variables
    Positiont1 = Positiont0 + vt0 × (t1 - t0)  
  • dérivée d'ordre 2 pour des mouvements stables (ex: véhicule)
    Positiont1 = Positiont0 + vt0 × (t1 - t0) + 0.5 × at0 × (t1 - t0)²  
  • Avec v vitesse et a acceleration

Convergence

Pour réconcilier les erreurs de prédiction du client, interpoler entre la position erronée vers la position réelle.
Eviter la téléportation.

Stratégie : Pas à pas déterministe

  • Envoyer les inputs uniquement et pas l'état du jeu
  • Partir du même état
  • Simuler l'univers en simultané sur tous les clients
  • ++ Permet de simuler des mondes physiques de milliers ou millions d'objets avec la même bande passante.
  • -- Nécessite que tous les inputs arrivent et dans l'ordre
  • -- Tout le monde attends le joueur ayant le plus de latence
  • -- Déterminisme

Déterminisme

Stratégie : interpolation de snapshots

  • Simuler uniquement côté serveur
  • Envoyer des poses clés (snapshots) du monde périodiquement
  • Reconstruire une approximation côté client

Stratégie : Synchronisation des états

  • Simuler côté serveur et côté client
  • Envoyer aux clients des poses clés (snapshots) partielles du monde périodiquement
  • Envoyer aux clients les inputs pour affiner la simulation
  • Simuler une approximation côté client qu'on réajuste au fur et à mesure
Ressources :