Application de lApproche Ractive:

1
Application de lApproche Réactive

• Simulation de mondes virtuels

Christian BRUNETTE Christian.Brunette_at_sophia.inria
.fr
Travaux soutenus par France Télécom-RD
2
Plan du cours

• Comportements et simulations
• Systèmes parallèles distribués
• Cohérence
• Jeux on-line massivement multi-joueurs (Projet
  PING).

3
Simulations virtuelles

• Simulation
• système constitué dentités autonomes exécutées
  en parallèle.
• ? programmation parallèle ?
• Réponse classique non, trop inefficace
• Réponse possible
• oui, programmation réactive !

4
Méthode classique

• Programmation objet pour représenter les
  différentes entités du monde simulé.
• Structuration en arbre
• Une notion dinstant décomposée en 3 phases
• Gestion des interactions extérieures Game Logic
  (réseau, interactions utilisateur,...)
• Calculs par nécessité des évolutions du système
  par remonté le long dun arbre dobjets.
• Affichage et son rendering

5
Exemple Quake

• while(1)
• // find time spent rendering last frame
• newtime Sys_FloatTime()
• time newtime - oldtime
• ...
• // decide the simulation time
• if (!Host_FilterTime (time))
• return
• Sys_SendKeyEvents()IN_Commands()
• ...
• Host_ServerFrame()// SV_Physics() et
  SV_RunThink()
• // update video
• SCR_UpdateScreen()
• ...
• // update audio
• CDAudio_Update()
• --------------------------------------------------
  -----------------
• // treat each object in turn

6
Entité réactive

• Un objet réactif dans une simulation est décrit
  par
• une structure de données (état),
• des opérations de traitements (manipulateurs),
• un comportement (ordonnancement et contrôle de
  tâches).

7
Simulations des interactions physiques

• Conserver un rendu réaliste des interactions
  physiques tout en conservant une programmation
  modulaire.

8
Simulations physiques

• Le pendule simple
• Résolution numérique étapes successives de
  calculs (Runge Kutta)
• Jr.Loop(
• Jr.Seq(Jr.Atom(new RKStep()),
• Jr.Seq(Jr.Generate(angle, new Position()),
• Jr.Stop())))

9
Composition parallèles des interactions

• Dynamicité et modularité des systèmes simulés

10
Démos

• Programmation de robots évoluant dans des arènes
  Fight Club.
• Mélange de comportements physiques avec des
  comportements à événements discrets (interactions
  avec lutilisateur).

11
Simulations distribuées

• Mondes virtuels distribués
• être multi-utilisateurs
• augmenter le nombre de ressources de calculs
• persistance

12
Monde virtuel
13
Vues partielles
Vue partielle du monde
14
Vues distribuées
Vue locale
réplica
Vue locale
réplica
Monde virtuel
réplica
Vue locale
Réplica maître/esclave
15
Approches centralisées

• Un serveur centralisé réalise lensemble des
  calculs de la simulation.
• Les clients envoient au serveur les événements
  produits par les actions du joueur.
• Les clients reçoivent régulièrement des
  informations du serveur et font peu voire pas
  dextrapolations.

16
Solution centralisée

• Avantages
• assure la cohérence de la simulation
• simple à mettre en oeuvre
• sécurité.
• Inconvénients
• passage à léchelle dun grand nombre de joueurs
  difficile (Charge serveur et réseau)
• pannes
• réactivité en cas de délais réseau.

17
Quake

• Nouvelle Frame étape de simulation
• Arborescence dobjets activés par nécessité à
  chaque étape (méthode think).

Action du joueur
client
Serveur
Résultat de la simulation

• Deux flux de retour
• Un flux prioritaire
• Un flux optionnel

client
18
Approche décentralisée

• Mise à profit du max de ressources de calcul
  chaque client participe aux calculs de la
  simulation.
• Chaque simulation locale calcule lévolution des
  réplicas maîtres dont elle a la charge.

19
Objet de liaison (binding object)
20
Solution décentralisée

• Avantages
• chaque objet de liaison peut optimiser les routes
  sur le réseau
• charge de calcul répartie en fonction du nombre
  de participants
• meilleure réactivité du système
• tolérance aux pannes.
• Inconvénients
• problème de cohérence de la simulation globale
• sécurité.

21
Diablo

• Chaque joueur simule une partie du monde.
• Synchronisation par nécessité (manipulation
  dobjets,...)
• Le donjon existe tant quil reste un joueur.
• Pas dévolution en dehors de la zone dintérêt du
  joueur.
• Très nombreuses incohérences entre simulations.

22
Notion de cohérence

• Différents types de cohérence
• cohérence spatiale
• cohérence temporelle
• cohérence comportementale
• Les différents types sont  dépendants  les uns
  des autres.

23
Cohérence spatiale
erreur
maître
esclave
erreur
réalité
Simulation S
distance d incohérence(S) S d(o,S(o)) incohérenc
e(S)t S d(ot ,S(ot ))
24
Cohérence temporelle

• Image partielle de la réalité.
• Exemple vision centrée sur un objet

Nécessité dun mécanisme de peuplement création
et destruction dynamique de réplicas
25
Maîtres distribués

• Simulations distribuées à travers le réseau
• Pas de notion de temps commun
• Maîtres gérés par les simulations réparties

réseau
Problème central comment maximiser la cohérence
des simulations entre elles, tout en minimisant
le trafic réseau
26
Anticipation

• 3 sources de non-déterminisme
• actions externes sur les maîtres
• délais de transmission
• charge des simulations
• Mécanismes danticipation (dead-reckoning)
  définissent le comportement des réplicas esclaves
  entre deux synchronisations.

27
Collision

• Pour minimiser la charge des simulations
• comportements dégradés des réplicas
• collisions traitées uniquement par les maîtres
• Complexité générale des collisions N(N-1)/2
  O(N2)
• Chaque simulation N-1 O(N). Complexité
  totale plus grande, mais parallélisme

Il y a des possibilités dincohérences
28
Dead-Reckoning

• Tenir compte de la différence de vitesse entre
  les simulations
• Rattrapage progressif des écarts
• Décision statistique

29
Architecture

• Plate-forme fournit différents services
• population des simulations
• diffusion dinformations
• persistance des données
• transfert de mastership.
• évolution

30
Démo

• Petit jeu de robot sur architecture distribuée.
• Chaque simulation est centrée sur son joueur.
• Les bombes que lon crée sont gérées par le
  serveur.

31
PING

• Platform for Interactive Networked Games
• Objectifs fournir une architecture software
  permettant le déploiement de Mondes Virtuels
  Massivement Multi-joueurs.
• Partenaire France Telecom RD, ENST, Imag,
  Lancaster University, Reading University, SICS,
  Kalisto.
• http//www.pingproject.com

32
PING caractéristiques

• Middleware orienté objets (ORB).
• Protocoles de communication efficaces et
  adaptables
• Services de gestion dobjets de haut niveau
  (persistance, réplication, cohérence)
• Système de partitionnement efficace compatible
  avec la notion de monde virtuel continu (Aura).
• Utilisation de lApproche Réactive dans la
  description des comportements des objets de
  simulation.
• Introduction de notions de programmation au
  niveau du gameplay (Icobjs).

33
Comportements réactifs

• Comportement des objets définis dans lApproche
  Réactive
• ordonnancement des traitements de données
• contrôle dexécution
• synchronisation naturelle avec les comportements
  des autres entités
• communication entre entité par événements
  diffusés instantanément.
• Comportements des réplicas
• le comportement de lentité autonome devient le
  comportement du réplica maître.
• Les comportements des réplicas esclaves sont des
  versions dégénérées du comportement du maître.
  Ces comportements permettent dimplémenter des
  stratégies danticipation dead-reckoning.

34
Extension du gameplay

• Introduction de la programmation au niveau
  applicatif programmer son avatar.

Problèmes sécurité comportement des réplicas
35
Conclusion

• Simulations distribuées de mondes virtuels
• pas de simulation centrale.
• charge de calcul répartie distribution des
  maîtres.
• comportements dégradés des réplicas.
• méthodes dextrapolations dead-reckoning
  (minimise la charge réseau)
• persistance avec évolution (simulation dédiée)
• Papier A Reactive Behavior Framework for
• Dynamic Virtual Worlds, Conf. Web3D 2001.