V(ery)MMORPG/FicheSuivi

From air
Revision as of 07:30, 27 March 2014 by Donsez (talk | contribs) (→‎Références)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Présentation

Equipe

Encadrant/Client

  • Jacques Léger(jacques.leger@yahoo.com)
  • Didier Donsez(didier.donsez@imag.fr)

Etudiants

  • Marion Dalle(marion.dalle@e.ujf-grenoble.fr) <-- Cheffe de projet
  • Rémi Piotaix(remi.piotaix@e.ujf-grenoble.fr)

Projet

Ce projet a pour but de créer un moteur de jeu permettant à plus de 100.000.000 joueurs de jouer simultanément à un jeu de course. Les parties seront relativement courtes, une dizaine de minutes tout au plus. Et ne seront organisées que quelques fois par an (environ une fois par mois).

Chaque client, joueur, doit avoir une idée précise de son voisinage, car il est évident qu'à cette échelle, nous ne pouvons voir tous les joueurs. Ils devront aussi avoir une idée de leur classement et de l'état de la course par rapport à eux (où ils sont sur la carte globale de la course et la densité des autres joueurs en chaque lieu). Dans l'idéal, il pourra y avoir une interraction entre les joueurs, voire des équipes qui se forment.

Le jeu recevra un décor préalablement créé et qu'il chargera. Ce décor sera dans l'idéal en 3 dimensions.

Déroulement du projet

Comptes rendus des réunions avec M. Léger

Brainstroming

Brainstorming #1 (03/02/14)

  • Leader gère les cluster. C'est soit un serveur soit un client avec une bonne connection et une bonne machine (ex : ordinateur fixe avec connection par fibre)
  • Manager Serveur chef des leaders.
  • Election de leader Quand on se connecte pour jouer le serveur regarde notre eligibilité. Si nous sommes éligibles il nous envoie en priorité sur un cluster sans "leader-client". Si nous arrivons dans un cluster où le leader est le serveur et que nous sommes éligible, nous devenons leader. Si nous arrivons sur un cluster avec "leader-client", il nous envoie la liste des remplçants ; dans le cas où nous sommes éligible il nous rajoute à la liste et la multicast sur tout le cluster. Cela se fait de la même manière en cours de partie quand un client change de cluster. Un cluster sans client eligible est mener par le serveur.
Schéma de communication
Types de communication
Variables uiles
Diagramme de classe
Schéma temporel de la connexion












Planning du projet

Planning
Date de début Date de fin Tâche Ressource
1 28/01/2014 03/02/2014 Choix et mise en place du projet Toutes
2 03/02/2014 10/02/2014 Organisation du projet Toutes
3 05/02/2014 10/02/2014 Choix du langage Toutes
4 11/02/2014 17/02/2014 Mise en place de la couche bas niveau Rémi Piotaix
5 11/02/2014 24/02/2014 Modélisation et simulation de l'architecture Marion Dalle
6 18/02/2014 25/02/2014 Création d'extension de l'engine Rémi Piotaix
7 25/02/2014 27/02/2014 Lecture des résultats de simulation Marion Dalle
8 26/02/2014 12/03/2014 Elaboration des échanges Rémi Piotaix
9 27/02/2014 21/03/2014 Elaboration du démonstrateur Marion Dalle
10 13/03/2014 20/03/2014 Initialisation des joueurs Rémi Piotaix
11 20/03/2014 25/03/2014 Mise en commun démonstrateur et engine Toutes
12 22/03/2014 27/03/2014 Préparation des rendus Toutes

Etat du projet

Architecture

Superposition des clusters sur notre map

Modélisation théorique

  • Cluster rond qui permettent une implémentation aisée :
    • Un point centrale qui seras donné par deux réels réprésentant ses coordonnées.
    • Une longueur qui représente le rayon du cercle et qui est donné par un réél
  • Un joueur peut être pris dans plusieurs clusters. Il est au minimum dans un cluster et au maximum dans quatres si on implémente une architecture en cluster circulaire de taille égale, où de plus en plus petit en allant vers l'objectif.
  • Si les joueurs peuvent aller en arrière, en représentant les zones sous formes de graphe orienté comme un arbre les joueurs peuvent aller sur :
    • Leur voisin direct gauche et droit
    • Leur fils gauche, droit et centre
    • Leur père gauche droit et centre
Liens entre les zones
  • Simulation d'un tel réseau en le simplifiant dans une architecture type "ruche"
Architecture simplifiée pour simulation
    • Si trop d'obstacle surcharge des clusters de bord
      • Pas plus de 10% de déplacement en arrière
      • Si surcharge d'un cluster mettre 2 leaders dessus et séparer les clients du cluster en deux
    • La taille de la map doit être très grande pour tenir 10 minutes
      • Prévoir la taille de la map en fonction de la vitesse moyenne Vm (en unité de distance par minute)
      • La taille de la ligne droite entre départ et arrivées doit être égale Vm * 8
      • Le taille totale de tous les obstacles ne peut pas être supérieur à 10% de la taille de la map.

Implémentation

code non open source

Démonstrateur

D'après les résultats de la simulation, nous ne pouvons avoir plus de 10% de la taille d'un cluster de rempli par des obstacles. Si nous dépassons cette proportion, trop de joueurs devront redescendre et nous auront une surcharge des clusters. Pour simplifier l'implémentation de notre démonstrateur nous utiliserons uniquement des obstacles rectangulaires. On pourra y voir les autres joueurs en temps réel. Le jeu n'aura pas réellement de fin, mais nous auront un classement effectifs des joueur en fonction de leur distance avec le point centrale du cercle. Nous pourrons donc constater que tous les jours ont bien le même "podium", ce qui prouvera le concenssus entre les joueurs.

Le jeu se déroulera de la manière suivante :

  • Obstacle de tailles fixe mais placé de manière aléatoire
  • Placement initiale du joueur aléatoire
  • Le joueur peut augmenter sa vitesse avec les flèches du clavier
  • Si un joueur rencontre un obstacle il reste "sonner" un temps proportionnel à sa vitesse

Références

Retrieved from "https://air.imag.fr/index.php?title=V(ery)MMORPG/FicheSuivi&oldid=16487"