V(ery)MMORPG/FicheSuivi

=Présentation=

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

 * Première réunion(03/02/14) : V(ery)MMORPG/CompteRenduN1
 * Deuxième réunion (11/02/14) : V(ery)MMORPG/CompteRenduN2

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.

Semaine du 03/02/14 au 09/02/14

 * Etude du cout d'un tel projet et du gain espéré (UE MPI)
 * Etude des risques présent sur ce projet (UE MPI)
 * Premier rendez-vous avec Jacques Léger (cf Compte rendu)
 * Recherche du langage à utiliser :
 * Ozéliminé après comparaison de ces performances avec celle de Java
 * Java, compatible PC et android mais ni Iphone ni Windows Phone
 * SCALA très interessant mais non choisis pour des questions de faciliter et de connaissance du lanagage
 * C++ adpatable sur tous les systèmes mais intégration compliqué
 * Dart, limite l'implémentation du jeu à des technologies web. Mais accessible sur toutes les plateformes.
 * Modélisation de l'architecture de manière théorique

Semaine du 10/02/14 au 16/02/14

 * Mise en place de la couche bas niveau sous le modèle NIO
 * Script et simulation de l'architecture

=Etat du projet=

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
 * Simulation d'un tel réseau en le simplifiant dans une architecture type "ruche"