documentation technique - epitech france...documentation [legendary heroes]technique 1 description...

Documentation Technique [Legendary Heroes]

Documentation Technique TD8 Legendary Heroes

La documentation technique a pour but de permettre à un développeur non familier avec le projet

Legendary Heroes de comprendre les aspects techniques et prendre en main le code existant. Ce

document contient des diagrammes expliquant le fonctionnement du projet, de descriptions des

modules ainsi que le recensement des différents problèmes rencontrés au cours du développement.


1

Description du document

Titre Documentation technique Legendary Heroes

Date 20/03/2013

Auteurs Login Mail Xu Long Long xu_l [email protected]

Weiwen Yu yu_w [email protected]

Philippe Tian tian_p [email protected]

Franck Ibrahima ibrahi_f [email protected]

Jean Thai thai_j [email protected]

Paul Morel morel_e [email protected]

Tableau des révisions

Date Version Auteur(s) Section(s) Commentaires 20/03/2013 1.0 yu_w, tian_p, ibrahi_f,

morel_e, thai_j, xu_l Toutes Création du

document

31/05/2013 1.1 Ibrahi_f IV.1.A Mise à jour des technologies partie client jeu

31/07/2013 1.2 thai_j VI.11.1, VI.11.2, VI.11.3, 15

Déploiement sites sur serveur web. Mise à jour des méthodes implémentées.

24/10/2013 1.3 thai_j VI.13 Mise à jour de la structure base de données

2014/01/10 1.4 Yu_w Correction et ajout mineur


2

Table des matières

Description du document ........................................................................................................................ 1

Tableau des révisions .............................................................................................................................. 1

I. Introduction au projet ..................................................................................................................... 5

II. Architecture, buts et contraintes .................................................................................................... 6

1. Objectifs spécifiques ayant un impact sur l’architecture ............................................................ 6

2. Contraintes fonctionnelles .......................................................................................................... 6

3. Contraintes non fonctionnelles ................................................................................................... 6

III. Vue Déploiement ......................................................................................................................... 7

IV. Partie jeu ..................................................................................................................................... 8

1. Introduction ................................................................................................................................. 8

A. La partie client ......................................................................................................................... 8

V. Partie serveur ................................................................................................................................ 12

1. Technologie utilisées ................................................................................................................. 12

2. Implémentation ......................................................................................................................... 12

a. Démarrage du serveur ........................................................................................................... 12

b. Interface ................................................................................................................................ 12

c. Réseau ................................................................................................................................... 13

d. Protocole ............................................................................................................................... 13

e. Matchmaking ......................................................................................................................... 16

f. Session de jeu ........................................................................................................................ 16

g. Base de données........................................................................................................................ 20

Diagramme base de données Legendary Heroes .............................................................................. 21

VI. Sites internet ............................................................................................................................. 22

2. Introduction de la partie site internet ....................................................................................... 22

3. Diagrammes cas d’utilisation .................................................................................................... 22

4. Technologies utilisées................................................................................................................ 24


3

5. Frameworks utilisés ................................................................................................................... 24

6. Environnement de développement .......................................................................................... 24

7. Implémentation ......................................................................................................................... 25

8. Arborescence du domaine ........................................................................................................ 27

9. Configuration des sous-domaines ............................................................................................. 27

10. Les Bundles ............................................................................................................................ 28

11. Les contrôleurs ...................................................................................................................... 29

11.1. FFFGamesHeaderBundle : HeaderController ................................................................ 29

11.2. FFFGamesWebsiteBundle : PortalController ................................................................. 30

11.3. FFFGamesLegendaryHeroesBundle : WebsiteController .............................................. 30

12. Structure template ................................................................................................................ 31

13. Base de données.................................................................................................................... 33

13.1. Table « user » ................................................................................................................ 33

13.2. Table « friends » ............................................................................................................ 34

13.3. Table « messages » ........................................................................................................ 34

13.4. Table « temporary_registration » ................................................................................. 34

13.5. Table « admin » ............................................................................................................. 34

13.6. Table « chat_rooms » .................................................................................................... 34

13.7. Table « game_website » ................................................................................................ 35

13.8. Table « news » ............................................................................................................... 35

13.9. Table « pass_retrieval » ................................................................................................. 35

13.10. Table « profile » ............................................................................................................. 35

14. Modules ................................................................................................................................. 36

14.1. Site Portail 3FGames ..................................................................................................... 36

14.1.1. Connexion ...................................................................................................................... 36

a. Informations .......................................................................................................................... 36

b. Diagramme d’activité ............................................................................................................ 36

c. Diagramme de séquence ....................................................................................................... 37

14.1.2. Création de compte ....................................................................................................... 38

a. Informations .......................................................................................................................... 38



14.2. Site Legendary Heroes ....................................................................................................... 40


4

14.2.1. Lancement du jeu .......................................................................................................... 40

a. Informations .......................................................................................................................... 40



15. Déploiement sites internet .................................................................................................... 42

15.1. Debian............................................................................................................................ 42

15.2. Windows ........................................................................................................................ 42

VII. Annexes ................................................................................................................................. 43

5. Release Note.......................................................................................................................... 43

6. Bug Log .................................................................................................................................. 43


5

I. Introduction au projet

L’Epitech Innovative Project (ou EIP) correspond au projet de fin d’étude à l’Epitech. Les

étudiants doivent ainsi concevoir et réaliser un projet informatique sur deux ans qui validera la

réalisation technique mais aussi les qualités de gestion, d’organisation et de communication à la fin

de leurs études. En plus de l’aspect technique d’un projet informatique, les étudiants doivent rendre

le projet commercialisable via l’élaboration d’un business plan ainsi que de la publicité du projet.

Dans le cadre de l’EIP, notre équipe réalise le projet Legendary Heroes. Ce projet consiste à la

réalisation d’un portail de jeu en ligne, communautaire, le thème familial. Il permet aux personnes

désirant passer du temps en groupe, en famille ou simplement se divertir, de se regrouper et/ou

rejoindre une communauté de joueur. Plusieurs jeux vont être proposés aux joueurs, étant axé sur le

thème familial, ces jeux seront comparables à des jeux de cartes ou jeux de société.

Le projet Legendary Heroes se divise actuellement en deux parties distinctes :

- Le portail de la communauté 3FGames: Le portail est un site internet permettant aux

joueurs de s’inscrire et être guidé vers les jeux en ligne disponibles. D’autres

fonctionnalités telles que la gestion de compte, l’ajout d’amis et la messagerie vont être

développées.

- Le jeu Legendary Heroes : Legendary Heroes est un jeu de carte en ligne et sera le 1er jeu

disponible sur le portail 3FGames.

Chacun des jeux en ligne posséderont leurs propres sites internet leurs permettant de se

différencier et produira un environnement plus distinctif et immersif pour l’utilisateur sur chaque jeu.


6

II. Architecture, buts et contraintes

1. Objectifs spécifiques ayant un impact sur l’architecture Les objectifs spécifiques ayant un impact sur l’architecture :

- le projet doit être utilisable sur plusieurs types de base de données

- le projet doit être utilisable sur plusieurs types de système d’exploitation

- le projet doit pouvoir accueillir un grand nombre d’utilisateur simultanément

- le site doit être stable et fiable

2. Contraintes fonctionnelles Les contraintes fonctionnelles qui ont un impact sur l’architecture :

- possibilité que plusieurs utilisateurs se connectent sur le site portail

- possibilité que plusieurs utilisateurs se connectent dans un jeu

- consultation du site par un et plusieurs utilisateurs

- l’utilisateur doit pouvoir jouer à un jeu via le navigateur

- l’utilisateur doit pouvoir quitter une session de jeu à n’importe quel moment

- l’utilisateur doit pouvoir jouer même avec une vitesse de connexion réduit

3. Contraintes non fonctionnelles Les contraintes non fonctionnelles qui ont un impact sur l’architecture :

- accès au site web et jeux sur différents systèmes d’exploitation

- accès au site web et jeux sur différents navigateur

- le jeu doit pouvoir jouer de la musique

- l’utilisateur doit pouvoir modifier ses informations personnelles

- l’utilisateur doit pouvoir communiquer avec d’autres joueurs lors des sessions de

jeux

- l’utilisateur doit pouvoir envoyer et recevoir des messages privés

- le site doit présenter un très bon design

- le site doit être rapide à charger


7

III. Vue Déploiement

L’utilisateur (Poste Client), à partir de son navigateur internet doit se connecter soit depuis le

site portail ou depuis un site de jeu. La base de données est séparée en deux parties, la base de

données portail contenant les informations générales du compte utilisateur (mot de passe, email,

etc.) et la base de données jeu contenant les composants du jeu (objets, cartes, etc.) ainsi que les

informations du joueur par rapport au jeu concerné (classement, exploits, etc.).

Le navigateur internet doit avoir un lecteur Flash installé au préalable afin d’exécuter le jeu

contenu dans le site jeu. L’exécutable communique avec un serveur de jeu qui s’assure de la

communication et la synchronisation entre tous les joueurs. Le serveur de jeu a la possibilité

d’interroger les bases de données afin de récupérer les informations concernant les joueurs.


8

IV. Partie jeu

1. Introduction

Le jeu est séparé en deux parties distinctes :

- Une partie client, qui utilise la technologie Flash - Une partie serveur, qui est codé avec le langage de programmation C++

A. La partie client

La partie client utilise Aswing pour créer du contenu 2d. Aswing est un API surtout destiné au

développement de l'interface graphique de jeu. API très complet, permettant de développer des jeux

les plus simples aux jeux flash les plus complexes. L'utilisation de cette API permet d'utiliser la carte

graphiqe afin d'accélérer la vitesse et la puissance du client de jeu.

De plus, nous utilisons Robotlegs, un api qui permet de développer notre application client

sous l'architecture MVC. Le choix de robotlegs est sans équivoque un choix judicieux puisque il

permet de mieux structurer le code, de bien différencier les différentes parties du programme et de

les intégrer rapidement et assez facilement. Pour plus d'informations sur cette technologie, vous

pouvez jeter un coup d'œil sur le site officiel http://www.robotlegs.org/

L’image ci-dessous montre l’organisation de code source dans la partie client :

On a le package par défaut, qui contient une classe qui est le point d’entrée de progamme, cette classe sera appelée automatiquement au lancement par Flash Player.

http://www.robotlegs.org/


9

Le package assets contient tous les sources externes nécessaires pour le jeu, comme les images, les sons, les sprites...

Puis on a un package LegendaryHeros qui contient tous les codes sources du jeu, qui est divisé en plusieurs sous packages.

Le client est lancé au moment où l'utilisateur ouvre la page de jeu sur notre site portail. Dès le lancement du client, LegendaryHeroes est instancié et est exécuté automatiquement.

Cette classe permet d’instancier la classe GameStartMenu, qui est une classe fille de Sprite et qui permet d'afficher dans ce cas-là, notre menu du jeu.


10

Lorsqu’un utilisateur identifié lance le jeu, le site portail envoie au client Flash le ID de l’utilisateur, cet ID sera reçu par la classe WebsiteCommnicator, qui s’occupe de la communication entre le site web et le client.

Le message envoyé par le siteweb est capté par l’event ExternalInterface.addCallback, qui va appeler à son tour la fonction SendToJavascript, dans la SendToJavascript, un event est créé pour alerter la classe principale GameScreen pour lui passer l'ID du client, la classe GameScreen va, dans ce cas, essayer de communiquer avec le serveur de jeu pour récupérer les information du joueur qui correspond à cette ID, et ensuite le menu de jeu est affiché.

Pour la communication entre le client et le serveur de jeu, on utilise le protocle TCP/IP, la donnée à envoyer est sous format XML, la communication entre le serveur est assurée par le package Network dans le LegendaryHeroes Package.


11

La classe Connection dans le package Network instancie Flash.Net.Socket pour la communication en TCP/IP.

Les données entre le serveur sont sous format XML, ces données sont créées et traitées par les fonctions dans le package XMLManager.

La classe DataCreator dans le package XMLManager s’occupe de créer les différents types de donnée XML à envoyer. Par exemple la création de donnée XML pour le requête au serveur sur les informations de joueur dans la base de donnée de jeu, ou les informations sur les logiques de jeu.

Pour traiter les données XML envoyées par le serveur, la classe DataProcess dans le package XMLManager s’occupe de de-sérialiser et de traiter ces informations afin de créer des events pour signaler à des fonctions qui s’occupent de faire l’affichage visuelle au joueur.


12

V. Partie serveur

Le serveur a deux fonctionnalités : permettre aux joueurs de jouer et l'administration des parties via une interface en ligne de commandes.

1. Technologie utilisées

Le serveur est programmé avec le langage de programmation C++.

Nous utilisons la bibliothèque Boost::Asio pour la gestion du réseau.

Pour des raisons de performance le serveur est multi threadé grace à Boost::Thread.

Les requêtes en base de données sont exécutées avec la bibliothèque MySQL Connector/C++.

En parallèle du serveur de jeu un serveur de base de données MySQL est déployé sur la même

machine.

Toutes ces technologies sont portables. Ainsi même si le projet est actuellement configuré pour Visual Studio 2010 il est facile de le porter sur les systèmes UNIX et MAC.

2. Implémentation

a. Démarrage du serveur

Lors de l’exécution du binaire de serveur la classe Server est instancié et sa routine de lancement est appelée.

Routine de lancement du serveur : void Server::run(void)

{

// Start the client listening routine in background

startAccept();

running = true;

// Start console in background

boost::thread thread(boost::bind(&Server::console, this));

// Run io network service

while (running)

io.run_one();

}

b. Interface

Il est possible d’interagir avec le serveur en local en envoyant des commandes sur son entrée standard. Le serveur répond actuellement à de simples commandes telles que quit.

Le but est d'ajouter des commandes affichant les statistiques des clients connectés et des parties en cours.


13

c. Réseau

Au démarrage le serveur écoute sur le port 4242 avec un socket TCP.

Lancement du serveur (main.cpp)

Server server(io);

server.listenOnPort(4242);

server.run();

Chaque nouveau client est associé à une instance de la classe RemoteClient. class RemoteClient

{

public:

// Initialise a Client handler for the given network service

RemoteClient(boost::asio::io_service & io);

// Retrieve low level socket

boost::asio::ip::tcp::socket & getSocket(void);

// Start the request hanling process

void start(void);

// Set a new callback to be called when a packet is received

void setPacketReceivedCallback(PacketReceivedCallback callback);

// Send data to the remote client

void sendPacket(const RemoteClient::Packet & packet);

};

Cette classe est responsable des opérations réseau asynchrone liés à ce client.

À la connexion d'un joueur l'instance RemoteClient est gérée par la classe Server. void Server::handleAccept(RemoteClient * client)

{

// Add the new client to the connected clients list.

addClient(client);

// Start new client networking routine

client->start();

// Restart the listener for more incoming clients.

startAccept();

}

Le client est alors placé dans un lobby géré par la classe Server en attendant de le lié à une session de jeu.

d. Protocole

Les clients communiquent avec le serveur avec par protocole XML.

Le protocole XML est parsé par un système générique convertissant les données xml en liste de std::string.


14

Le protocole est défini par des instances de la classe XmlFormat initialisé comme tel dans la classe RemoteClient : // protocol is the action list of the protocol

// XmlFormat is a parse tree of the xml of the request

protocol["Connection_result"] =

XmlFormat("LegendaryHeroes").attribute("type_info").child(

XmlFormat("Connection_result").attribute("result"));

Pour étendre le protocole il faut donc ajouter une entrée dans la variable RemoteClient ::protocol en définissant le format de la requête avec XmlFormat.

Actuellement le protocole est découpé en deux parties : Les échanges dans le lobby et les échanges dans une partie.

Liste des requêtes réseaux avant d'entrer dans une partie (lobby) :

Connection : Connexion au serveur de jeu

Connection_result : Réponse du serveur

JoinQueue : Jouer, entre dans la file d’attente

JoinQueueResult : Réponse du serveur

CancelQueue : Quitte la file d'attente

ListFriend : Récupère la liste d'ami

ListFriendResult : Réponse du serveur

ListCards : Obtenir la liste des cartes possédées

ListCards : Réponse du serveur

SubmitDeck : Mettre à jour le nouveau deck

SubmitDeck : Réponse du serveur

Reconnect : Requête client de reconnexion

Reconnect : Réponse du serveur

Disconnect : Déconnexion du client


15

Liste des requêtes réseaux au cours d'une partie :

PreStart : Envois des infos de jeu des joueurs au début de la partie

ChoosePerso : Le serveur propose des rôles au client

ChoosePerso : Le client choisi un rôle

ChosenPerso : Le serveur informe chaque client de du rôle de chacun

PickCards : Le serveur envoie le résultat d'une pioche

BeginTurn : Le serveur informe tout le monde quel joueur commence à jouer

EndTurn : Le joueur informe la fin de son tour

PlayCard : Le joueur joue une carte

PlayCard : Le serveur informe chaque client qu'une carte a été jouée

AffectedPlayCard : Un joueur joue une carte en contre

AffectedPlayCard : Le serveur informe chaque client qu'une carte est jouée en contre

PlayerLeft : Un joueur se déconnecte

PlayerLeft : Le serveur informe chaque client de la déconnexion d'un joueur

PlayerDead : Le serveur informe tous les clients de la mort d'un joueur

GameEnd : Le serveur informe tous les clients que la partie est terminée

RecoTO : Le serveur informe tous les clients qu'un client s'est reconnecté ou qu'il a été éjecté (timeout)

SendTxt : Un joueur envoie un message sur le chat

SendTxt : Le serveur transmet le message à tous les clients

La classe Server parse et exécute les requêtes XML reçues concernant les joueurs qui ne sont pas dans une partie.


16

e. Matchmaking

Quand un joueur fait une requête pour lancer une partie le serveur tente de réunir des joueurs selon leur niveau pour commencer une partie. Pour déterminer le niveau des joueurs le serveur récupère le grade des joueurs stocké dans la BDD MySQL. Le matchmaking est également basé sur le temps d'attente afin de ne pas laisser un joueur d'un niveau différent attendre trop longtemps.

Lorsqu'une partie est créée le serveur instancie la classe GamePart. Cette classe représente la durée de vie d'une partie. Elle stocke tous les RemoteClient des joueurs participant. La classe GamePart notifie chacun de ses RemoteClient qu'elle gère à présent leurs requêtes réseau.

f. Session de jeu

La session de jeu correspond au jeu en cours, et possède donc une boucle de jeu gérant les différents mécanismes de LegendaryHeroes, tel que:

- la distribution des cartes de rôle et de personnage - le positionnement sur la table de jeu - la distribution des cartes de jeu (la pioche de jeu et le tas de défausse) - la gestion du tour par tour et des timers - la gestion réseau des envoie et réception de paquets traduit en action de jeu grâce à

la classe Client

La classe qui représente la session de jeu est GamePart.


17

1. Classe représentant la session de jeu

class GamePart

{

public:

GamePart(); //constructeur par défaut, non utilisé

GamePart(list<Client>, int gamesize); //constructeur prenant la liste

des clients et la taille de la game

~GamePart(); //destructeur

void GamePart::setClientdata(list<Client>); //fonction qui stocke les

infos de clients dans le vecteur groupe de l'objet.

void GamePart::ChoosePerso(Protocole proto); //Fonction protocole pour

sauvegarder le choix du perso

void GamePart::EndTurn(Protocole proto); //Fonction protocole prenant

en compte la fin de tour d'un joueur

void GamePart::PlayCard(Protocole proto); //Fonction protocole d'un

joueur jouant une carte

void GamePart::AffectedPlayCard(Protocole proto); //Fonction protocole

d'un joueur jouant une carte en contre

void GamePart::PlayerLeft(Protocole); //Fonction protocole annonçant la

déconnexion d'un joueur

void GamePart::SendTxt(Protocole); //Fonction protocole envoie d'un

message sur le chatbox en jeu

void GamePart::parsingGame(Protocole proto); //Parseur de Fonction

protocole et traitement par une map de méthodes.

void GamePart::initialize(); //Initialisation du ptr sur méthode.

bool GamePart::IsMyTurn(int); //Fonction renvoyant si le tour actuel

est bien le tour du joueur en paramètre

void GamePart::launchboucle(); //Lancement de la boucle de jeu

void GamePart::setClientRole(); //Attribution des rôles des joueurs par

un algo de hasard simuler.

protected:

std::vector<Joueur> groupe; //Vector contenant les infos des clients du

groupe de jeu

int gamesize; //taille de la partie actuelle

int touractuel; //numéro du tour du joueur actuel.

};


18

2. Classe représentant le joueur et le client

enum Role // les différents rôles jouable dans LegendaryHeroes.

{

AUCUN,

EMPEREUR,

FIDELE,

REBELLE,

TRAITRE,

REINE

};

class Joueur

{

public:

Joueur(); //constructeur par défaut

~Joueur(); //destructeur par défaut

int Joueur::getAttack(); //getter du nombre d'attaque disponible(0-1 ou

infini)

int Joueur::getCharacterid(); //getter de l'id de la carte personnage

choisi

Role Joueur::getRole(); //getter du rôle

int Joueur::getNbcards(); //getter du nb de carte dans la main

void Joueur::setAttack(int ); //setter du nb d'attaque

void Joueur::setCharacterid(int ); //setter de l'id personnage

void Joueur::setRole(Role); //setter du rôle

int id; //id du joueur

int playerspot; //position du joueur sur la table de jeu

int Joueur::getRange(); //getter de la portée d'attaque

void Joueur::setRange(int); //setter de la portée d'attaque

protected:

std::string pseudo; //pseudo du joueur

int attack; //nombre d'attaques disponibles

int characterid; //id du personnage

Role role; //rôle joué

std::list<int> *hands; //liste contenant les cartes de la main

int range; //portée d'attaque du joueur

std::vector<int> *equipped; //cartes équipées au joueur

};


19

3. Classe représentant une carte de jeu (différent de la carte de rôle et la carte

personnage)

enum actif //représente les caractéristiques actif d'une carte de jeu

{

NOT = 0,

BANGATK,

VOL,

DETRUIT,

PRISON,

SOIN

};

enum reactif //représente les caractéristiques de contre d'une carte de jeu

{

NONE = 0,

BANGDEF,

RATE,

LASTCHANCE

};

class Carte

{

public:

bool _multi; //multi pour savoir si la carte est jouable sur un joueur

adverse ou non

bool _solo; //solo pour savoir si utilisable sur soi même

int _portee; // portée -1 = infini 0 = dépend de la portée du joueur et

1+ = portée fixe de la carte

};


20

g. Base de données

Le serveur Legendary Heroes dispose d'une connexion à une base de données MYSQL. De

nombreuses informations seront stockées dans la base de données notamment la liste des joueurs

qui se sont inscrits au jeu, les statistiques des joueurs, les logs, les parties jouées.

Toutes ces données seront essentielles au bon fonctionnement du jeu, mais surtout, elle

permettra aux joueurs d'accéder à de nombreuses informations concernant par exemple son

historique de jeu ou bien d'avoir accès à la boutique du jeu, mais également de voir le profil des

autres joueurs.

Détails techniques :

Pour pouvoir communiquer avec la base de donnée, le serveur de jeu doit instancié une

classe nommée Database, une fois instancié et donc connecté au serveur MySQL, il pourra lancer des

requêtes grâce à la fonction Resquest(const std::string &) prenant en paramètre la requête à

effectuer. Par exemple "Database->Request("SELECT email FROMPlayer WHERE 1")".

De plus la classe Database dispose de requête prédéfini vers la base de données afin de

simplifier la lisibilité du code et mais surtout de mieux gérer les informations lorsqu'il y'a des

données à récuperer.

Voici des exemples de fonctions prédéfinis:

- static void GetProfil(Database *, Player *) => fonction qui récupère les

informations du joueur concerné.

- static void SetPlayerInGame(Database *, const Player *) => fonction qui

va indiquer que le joueur est en pleine partie de jeu.

- static void CreateReport(Database *, const Report *) => fonction qui va

permmettre de créer un report lorsque joueur rencontre un problème dans le jeu

par exemple.

- static void SetPlayerOnline(Database *, const Player *) => fonction qui

va connecter le joueur en ligne

- static void CreateRoom(Database *, const Room *) => fonction qui va

permettre d'indiquer qu'une room de jeu viens tout juste d'être crée.

Afin d'améliorer les performances du serveur face aux nombreuses requêtes, s'il y'a plusieurs

requêtes en même temps, la classe Database est threadé, les requêtes sont stockées dans une file

d'attente jusqu'à qu'elle soit traité et si la requête demande à ce que des valeurs soient retournées,

un signal est automatiquement envoyé au thread ou à la classe afin de récupérer les données.


21

Diagramme base de données Legendary Heroes


22

VI. Sites internet

2. Introduction de la partie site internet Les sites internet sont les portes d’entrées menant les utilisateurs aux jeux disponibles. Deux

catégories de sites internet sont apercevables dans le projet :

- Site Portail 3FGames : Le site portail est un site gérant l’inscription de l’utilisateur au

sein de la communauté. L’utilisateur aura la possibilité de gérer son compte à partir

de ce site, accéder aux jeux disponibles depuis une liste de sélection mais aussi de

consulter l’actualité des jeux qui sont centralisée sur ce portail. Le site portail ne

contient aucun jeu en soi et ne redirige que l’utilisateur vers les sites jeux depuis une

liste de sélection.

- Sites jeu : Chaque jeu possède un site propre à eux où une présentation et les règles

de jeu y sont expliquées. C’est à partir de ce site que le joueur pourra accéder au jeu.

Tous les sites possèdent un module utilisateur correspondant à un en-tête qui comporte les

fonctionnalités principales de l’utilisateur (connexion, sélection du jeu, consultation des messages).

3. Diagrammes cas d’utilisation Diagramme cas d’utilisation site jeu


23

Diagramme cas d’utilisation site portail


24

4. Technologies utilisées

Technologie Commentaires xHTML/CSS Langage de formatage classique permettant de créer des pages internet.

PHP PHP permet de rajouter la composante dynamique des pages internet, il permet l’élaboration de pages internet intelligente pouvant récupérer et traiter des données demandé à l’utilisateur. D’autres technologies son équivalent à PHP tel que Java J2EE et C# .Net mais le manque de portabilité de ce dernier et les nombreux failles de Java nous fait préférer utiliser PHP pour ce projet pour le moment.

JavaScript JavaScript nous permet d’animer les pages internet afin de les rendre agréable à utiliser pour l’utilisateur (par exemple une animation au passage de la souris ou des chargements de pages dynamique).

5. Frameworks utilisés

Framework Commentaires Symfony2 Le framework Symfony2 impose une norme de développement MVC

structurant le code afin de faciliter la maintenance de celui-ci. PHP étant un langage relativement libre de notation, il est donc impératif d’utiliser ce framework qui impose un style de programmation objet du même niveau que J2EE ou C# .Net

JQuery JQuery est un framework de JavaScript simplifiant l’utilisation de ce dernier. Il rajoute des fonctionnalités permettant l’utilisation d’AJAX qui permet le chargement de contenu au sein d’une même page.

6. Environnement de développement

Nous utilisons la suite de logiciel WAMP pour Windows et LAMP pour Linux. Cette suite de

logiciel comporte les applications suivantes :

- Apache : Serveur internet permettant de traiter les requêtes des clients, le serveur

héberge les pages internet.

- MySQL : Base de données contenant les informations et données nécessaires au

fonctionnement du projet.

- PHP : Le module PHP intégré au serveur Apache lui permet d’interpréter le code PHP

des pages internet.


25

7. Implémentation

Architecture MVC

C’est un pattern architectural qui sépare les données (le modèle), l’interface homme-machine (la vue) et la logique de contrôle (le contrôleur). Lorsqu’un utilisateur consulte un site basé sur cet architecture, le navigateur envoie les requêtes de l’utilisateur au site à travers le protocole http, de côté site, la couche contrôleur filtre les commandes par une série de traitement logiques, si la requête passe le filtrage, la couche modèle s’engage à interagir avec la base de donnée sur le serveur distant, et elle renvoie à la couche contrôleur des données correspondante à la requête, la couche contrôleur transmit ensuite ces données à la couche vue qui génère une page web au utilisateur.

Les trois couches :

- Le modèle: Il représente les données de l’application. Il définit aussi l’interaction avec la base de données et le traitement de ces données.

- La vue: Elle représente l’interface utilisateur. Elle n’effectue aucun traitement en

générale et se contente d’afficher les données que lui fournit le modèle à travers le contrôleur. Il peut y avoir plusieurs vues qui présentent les données d’un même modèle.

- Le contrôleur: Il génère l’interface entre le modèle et le client. Il va interpréter la

requête de ce dernier pour lui envoyer la vue correspondante. Son rôle est donc de

récupérer les informations, de les traiter en fonction des paramètres demandés par

la vue, puis de renvoyer à la vue les données à afficher. Il effectue la synchronisation

entre le modèle et les vues.


26

Voici un schéma de l’architecture MVC :

Avantages / Inconvénients L’architecture MVC apporte de réels avantages :

Une conception claire et efficace grâce à la séparation des données de la vue et du contrôleur

Un gain de temps de maintenance et d’évolution du site

Une plus grande souplesse pour organiser le développement du site entre différents développeurs (indépendance des données, de l’affichage et des actions).

Les inconvénients

L’inconvénient majeur du modèle MVC n’est visible que dans la réalisation de petits projets, de

site internet de faible envergure. Car la séparation des différentes couches nécessite la création de

plus de fichiers (3 fois plus exactement).


27

8. Arborescence du domaine

Schéma d’arborescence du domaine

9. Configuration des sous-domaines

Afin d’obtenir les sous-domaines pour chaque site jeu (par exemple legendaryheroes.3fgames.fr)

il faut modifier le fichier de configuration httpd.conf du serveur Apache.

NameVirtualHost *

<VirtualHost *>

ServerName legendaryheroes.3fgames.fr

DocumentRoot /www/3fgames/

</VirtualHost>

<VirtualHost *>

ServerName www.3fgames.fr

DocumentRoot /www/3fgames/

</VirtualHost>

Cette configuration permet la prise en compte du sous-domaine depuis le serveur Apache. En

plus de la configuration côté serveur web, nous devons aussi modifier les routes à Symfony2 afin de

rediriger les requêtes vers les bons contrôleurs dans les fichiers routing.yml.


28

fff_games_legendary_heroes_website_homepage:

path: /

host: legendaryheroes.3fgames.fr

defaults: { _controller:

FFFGamesLegendaryHeroesWebsiteBundle:Website:index }

fff_games_legendary_heroes_website_index:

path: /index

host: legendaryheroes.3fgames.fr

defaults: { _controller:

FFFGamesLegendaryHeroesWebsiteBundle:Website:index }

Dans cet exemple, la ligne spécifiant host permet au moteur de routes Symfony de rediriger

la requête vers le contrôleur du site de jeu lorsque le navigateur accède au domaine

legendaryheroes.3fgames.fr. Dans le cas où l’utilisateur accède au domaine principal

www.3fgames.fr, le moteur de route redirigera la requête vers le contrôleur du site portail.

Pour plus d’informations sur les routes Symfony2, veuillez consulter la documentation.

10. Les Bundles

Les Bundles sont des composants de Symfony. Ils permettent de regrouper une partie du site

internet facilitant son utilisation au sein de plusieurs pages internet. Dans le framework Symfony,

tout code appartient à un bundle, ainsi un bundle peut être un composant réutilisable ou le site

internet en lui-même.

Le project Legendary Heroes se découpe actuellement en trois bundles différents :

- Barre d’utilisateur 3FGames : la barre d’utilisateur en en-tête de chaque site

permettant aux joueurs d’accéder rapidement aux fonctionnalités de bases. Il est

codé dans le bundle « FFFGamesHeaderBundle », tous les sites doivent inclure ce

bundle afin d’obtenir l’en-tête 3FGames.

- Site portail 3FGames : Tout le site portail 3FGames regroupé dans un bundle nommé

« FFFGamesWebsiteBundle ».

- Site jeu Legendary Heroes : De même que pour le site 3FGames, Legendary Heroes

est codé dans un bundle nommé « FFFGamesLegendaryHeroesWebsiteBundle ».

Pour plus d’informations sur les bundles Symfony2, veuillez consulter la documentation.

http://symfony.com/doc/current/book/routing.html

http://symfony.com/doc/current/book/page_creation.html


29

11. Les contrôleurs

Les contrôleurs sont les parties gérants les requêtes du navigateur client lors d’un chargement de

page. Le projet se compose actuellement des contrôleurs suivants :

Diagramme contrôleurs

Pour plus d’informations sur les contrôleurs Symfony2, veuillez consulter la documentation.

11.1. FFFGamesHeaderBundle : HeaderController

Répertoire : /src/FFFGames/HeaderBundle/HeaderController.php

Ce contrôleur génère, affiche et gère l’en-tête 3FGames sur chaque début de page.

Méthode Statut Commentaires

getHeaderAction() Implémenté Appelée depuis un template, permet de générer l’affiche de l’en-tête.

userLoginAction() Implémenté Gère la connexion de l’utilisateur. Elle récupère les informations d’authentification et vérifie la correspondance des données. Elle créer les données de sessions.

userLogoutAction() Implémenté Gère la déconnexion de l’utilisateur. Elle détruit les données de sessions.

addFriendAction() Implémenté Code gérant l’ajout d’un ami à la liste de contact de l’utilisateur en base de données.

deleteFriendAction() Implémenté Code gérant la suppression d’un ami à la liste de contact de l’utilisateur en base de données.

openMailboxAction() Implémenté Chargement et affichage de la page de messagerie.

sendMessageAction() En cours Gère l’envoie d’un message vers un ami de l’utilisateur.

readMessageAction() En cours Chargement d’un message de la page de messagerie.

deleteMessageAction() En cours Suppression d’un message de la boite de messagerie.

editProfilePageAction() Implémenté Affichage de la page d’édition du profile utilisateur.

editProfileAction() Implémenté Sauvegarde les modifications du profile utilisateur.

http://symfony.com/doc/current/book/controller.html


30

11.2. FFFGamesWebsiteBundle : PortalController

Répertoire : /src/FFFGames/WebsiteBundle/Controller/PortalController.php

Ce contrôleur contient le site portail 3FGames, toutes les pages sont gérées par ce contrôleur qui

s’occupe de les générer.


indexAction() Implémenté Génère la page d’index du portail.

registerPageAction() Implémenté Génère la page d’inscription.

registerAction() Implémenté Gère l’inscription de l’utilisateur au portail 3FGames. Le contrôleur vérifie les informations renseignées par l’utilisateur et le sauvegarde en base de données temporairement.

confirmRegistrationAction() Implémenté Gère la finalisation de l’inscription de l’utilisateur après une confirmation de l’utilisateur à partir d’un message email.

creditsPageAction() Prévu Génère la page de crédits du portail.

11.3. FFFGamesLegendaryHeroesBundle : WebsiteController

Répertoire : /src/FFFGames/ LegendaryHeroesWebsiteBundle/Controller/WebsiteController.php

Ce contrôleur contient le site de jeu Legendary Heroes, toutes les pages sont gérées par ce

contrôleur qui s’occupe de les générer.


indexAction() Implémenté Génère la page d’index du site Legendary Heroes.

rulesPageAction() Implémenté Génère la page des règles du jeu.

creditsPageAction() Prévu Génère la page de crédits du site.

scorePageAction() Prévu Génère la page de classement utilisateur pour le jeu.


31

12. Structure template

Le moteur de templates Twig est utilisé afin de mettre en place la vue du modèle MVC dans le

framework Symfony2. Voici la composition classique d’une page template de tous les sites.

Aperçu séparation structurelle d’une page

Les pages internet sont composés de trois parties distinctes :

1. L’en-tête de la page, la même pour toutes les pages, est généré par le contrôleur

« HeaderBundle : HeaderController ».

2. Le contenu de la page qui est géré par les contrôleurs dédiés à chaque page du site.

3. Le pied de page, la même pour toutes les pages, est une inclusion d’un fichier

template.

32

Le code suivant est le code template utilisé pour reproduire la même disposition.

<!DOCTYPE html> <html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>



{% block title %}{% endblock %}

</title>



{% block stylesheets %}{% endblock %}

</head>

<body>



{% block javascripts %}

{% endblock %}



{% render(controller('FFFGamesHeaderBundle:Header:getHeader')) %}

<div id="page-content">

<div class="content">



{% block page_content %}

{% endblock %}

</div>

</div>



{% include 'FFFGamesWebsiteBundle:Portal:footer.html.twig' %}

</body>

</html>

Pour plus d’informations sur les templates Symfony2, veuillez consulter la documentation.

http://symfony.com/doc/current/book/templating.html


33

13. Base de données

Diagramme base de données du site 3FGames

Le site portail 3FGames possède une base de données des comptes utilisateurs ainsi que les

autres fonctionnalités tels que la base de données des amis, la messagerie et le système d’inscription

en deux étapes. D’autres bases de données existent et correspondent aux données du jeu tel que les

objets du jeu, succès du joueur, etc. Tous données de jeu liant à un joueur possède un identifiant

permettant de le retrouver parmi la base de données utilisateur de 3FGames.

13.1. Table « user »

Colonne Commentaires

id Identifiant unique permettant de différencier chaque entrée. Est une clé primaire.

username Nom d’utilisateur.

salt Chaîne de caractères permettant de chiffrer le mot de passe.

password Mot de passe utilisateur chiffré en MD-512.

email Adresse email de l’utilisateur.

is_active Indique si l’utilisateur est actuellement en ligne.


34

13.2. Table « friends »


id_source Identifiant de l’ami. Est une clé unique.

id_source Identifiant indiquant l’utilisateur source

id_target Identifiant indiquant l’ami de l’utilisateur source

13.3. Table « messages »


id Identifiant du message. Est une clé unique.

source Identifiant de l’expéditeur.

target Identifiant du destinataire.

date Date et heure de l’envoi du message.

content Contenu du message.

13.4. Table « temporary_registration »


id Identifiant de l’entrée. Est une clé unique

username Nom d’utilisateur.

salt Chaîne de caractères permettant de chiffrer le mot de passe.

password Mot de passe de l’utilisateur chiffré en MD-512.

email Adresse email de l’utilisateur.

confirmation_link Lien de confirmation envoyé en email à l’utilisateur.

13.5. Table « admin »



user_id Identifiant de l’utilisateur admin

13.6. Table « chat_rooms »



users Utilisateurs de la salle de chat sous la forme `USERID1:READ_FLAG1;USERID2:READ_FLAG2` avec READ_FLAG soit 0 ou 1, 0 correspondant à un message non lu par l’utilisateur correspondant et 1 à un message lu.


35

13.7. Table « game_website »

Cette table permet de renseigner tous les sites de jeu sur le portail 3FGames. Il sert

notamment à classer les news selon le jeu correspondant au news afin de fournir une interface

globalisée permettant la gestion d’actualités.



name Nom du site.

url Url du site.

13.8. Table « news »



id_website Identifiant du site concerné (id de la table game_website).

Id_author Identifiant de l’auteur du news.

Id_editor Identifiant de l’éditeur du news s’il y a eu modification.

title Titre de l’actualité

date Date de rédaction de l’actualité

edit_date Date d’édition d’une actualité si modification.

content Contenu de l’actualité

13.9. Table « pass_retrieval »

Cette table recense la liste de demande de mot de passe oublié par les utilisateurs.


Id Identifiant de l’entrée. Est une clé unique

account_id Identifiant du compte demandeur

retrieval_link Token permettant la remise à zéro du mot de passe.

13.10. Table « profile »


Id Identifiant de l’utilisateur (correspondant à l’identifiant de la table user).

sex Sexe de l’utilisateur (M ou F).

birthday Date d’anniversaire de l’utilisateur.

exp Expérience de l’utilisateur dans le site portail.

img Url de l’image avatar.

msg Message personnel de l’utilisateur.


36

14. Modules

14.1. Site Portail 3FGames

14.1.1. Connexion

a. Informations

Le module de connexion du site portail 3FGames est géré par :

Bundle : HeaderBundle

Contrôleur : HeaderController

Méthode : userLoginAction

Chemin du fichier : /src/FFFGames/HeaderBundle/Controller/HeaderController.php

b. Diagramme d’activité

Diagramme d’activité authentification d’un utilisateur


37

c. Diagramme de séquence

Diagramme de séquence authentification d’un utilisateur


38

14.1.2. Création de compte

a. Informations

Le module de création de compte est géré par :

Bundle : WebsiteBundle

Contrôleur : PortalController

Méthode : registerPageAction, registerAction

Chemin du fichier : /src/FFFGames/WebsiteBundle/Controller/PortalController.php


Diagramme d’activité création d’un compte


39


Diagramme de séquence création d’un compte


40

14.2. Site Legendary Heroes

14.2.1. Lancement du jeu

a. Informations

Le module de lancement du jeu est géré par :

Bundle : LegendaryHeroesWebsiteBundle

Contrôleur : WebsiteController

Méthode : indexAction

Chemin du fichier : /src/FFFGames/ LegendaryHeroesWebsiteBundle /Controller/

WebsiteController.php


Diagramme d’activité lancement du jeu


41


Diagramme de séquence lancement du jeu


42

15. Déploiement sites internet

Voici les instructions afin de déployer les sites internet sur un serveur web. Chaque partie

traitera d’un système d’opération spécifique.

15.1. Debian

1. Installez le paquet Subversion avec la commande : apt-get install subversion.

2. Récupérez depuis le dépôt SVN EIP Epitech le répertoire trunk/website/deploy

avec la commande : svn co

https://labeip.epitech.eu/svn/2014/legendaryheroes/trunk/website/deploy

3. Accédez au répertoire deploy et éxecutez le script script.sh.

4. Une fois que le script termine son exécution, le serveur est prêt et le site est

déployé.

15.2. Windows

1. Installez Tortoise SVN et WAMP Server.

2. Récupérez depuis le dépôt SVN EIP Epitech le répertoire trunk/website/3FGames.

3. Récupérez depuis le dépôt SVN EIP Epitech le répertoire trunk/website/deploy.

4. Copiez le répertoire 3FGames dans le dossier localhost de WAMP Server.

5. Activez le module rewrite d’Apache.

6. Ouvrez le fichier httpd.conf depuis WAMP Server.

7. Modifiez le DocumentRoot vers le répertoire 3FGames du dossier locale WAMP

Server.

8. Recherchez la ligne « Require local » et remplacez par Require all granted.

9. Redémarrez le serveur WAMP.

10. Accédez au PHPMyAdmin depuis WAMP.

11. Importez le fichier SQL fffgames.sql du dossier deploy.

https://labeip.epitech.eu/svn/2014/legendaryheroes/trunk/website/deploy


43

VII. Annexes

5. Release Note

Version Date Commentaires

0.1.0 30/11/2012 Publication de la base du site 3FGames.

0.1.1 27/12/2012 Publication de la base du site Legendary Heroes.

0.2.0 01/03/2013 Intégration du client flash au site Legendary Heroes.

0.2.5 18/03/2013 Passage de Symfony2.1 à Symfony2.2.

6. Bug Log

Date Problème Résolution

18/03/2013 Problème de gestion des sous-domaines entre les sites 3FGames et Legendary Heroes.

Passage à la version Symfony2.2

documentation technique - epitech france...documentation [legendary heroes]technique 1 description...

Documents