V(ery)MMORPG/CompteRenduN1

Présentation du projet

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

Chaque clients, joueurs, 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, voir des équipes qui se forment.

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

Echange entre les clients

Afin de commencer le travail nous partirons sur un jeu en 2 dimensions (x,y). Les clients devront connaitre leur positions et leur vitesse ainsi que celle de leur voisins. Ces données seront données de la manière suivante :

• Position 2 réels, représentant les coordonnées du joueur
• Un vecteur représenter par 2 réels.

Nous devrons donc faire circuler sur le réseau des paquets de 32*4 bits soit 128 bits, hors en-tête.

Idée d'architecture

Idée proposée par M. Léger

• Nous partons sur une architecture paire à paire. Cependant, nous voulons aussi que notre jeu soit utilisable sur mobile, nous serons donc obligés d'adapter l'architecture en fonction. Il nous faudra faire en sorte que les ordinateurs des joueurs PC servent de serveur aux mobiles qui ne prennent pas en charges le paire à paire. Il est aussi envisageable d'avoir des serveurs, mais dans ce cas, il faudra optimiser les performances pour minimiser leur nombre.
• L'application n'est pas forcément en temps réel absolue. Il nous faut seulement avoir l'allure de la course, la réalité et la précisison du temps réel absolu ne sont pas obligatoire.

Idée proposé par les étudiants

• Il a été relevé qu'il faut essayer de voir si il faut une approche centralisée ou distribuée. Dans le cas d'une approche centralisée on peut se permettre de voir la course du peloton de tête une fois que nous sommes mort.
• Nous avons émis la possibilité de partager le jeu en plusieurs zones, sous l'exemple des cellules GSM. Cela nous permettrait de ne connaitre que les clients qui sont présent dans notre zone de jeu. Le nombre de clients à gérer simultanément serait donc diminuer. Chaque zone aurait donc les possibilitées et besoins suivants :
  • Multicast avec toutes les personnes de la zone. Il serait utiliser afin de prevenir l'ensembles des joueurs de la zone lors d'un changement de vitesse d'un des leurs.
  • Unicast
• Il est aussi important que les serveurs qui gèrent les cluster communiquent entre eux afin de fournir un broadcast qui permetrait nottament de notifier de la fin de la partie et du gagnant à chacun des joueurs.
• L'architecture clustering proposé peut se presenter de la manière suivante :

Architecture cluster

Les ronds noir représentent les zones les ronds colorés la cible, Le rond bleu est la zone tampon où l'on pénètre et où l'on avance selon notre vitesse d'entrée dans cette zone. Le rond rose est le but final à atteindre. La partie bleue nous permet d'avoir un temps pour informer tout le monde de la fin de la partie et du gagnant.

Inspiration

• Virtual Regata : jeu de course nautique en ligne Site officiel de Virtual Regata
• Extinction : jeu flash de mini-partie où il faut suivre un leader afin de sortir du labirynthe. Travail d'équipe. Site officiel d'Extinction

Organisation

• Toujours utiliser le préfixe [Projet : Jeu] dans nos échanges de mail
• Le projet ne seras pas Open-Source
• Faire des réunions hebdomadaire avec compte rendu à la clé

Partage du travail pour les jours à venir

• Essayer de faire une modélisation de notre architecture afin de pouvoir trouver des paramètres optimaux (nombre de cluster par exemple) par simulation (Marion)
• Redefinissions des besoins du serveur et du clients dans leur interactions voir début d'implémentation d'un dialogue multicast (Rémi)

Prochaine réunion

==> Mardi 11 février à 11h30 en salle AIR