Documentation Technique

Transcription

1 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.

2 Description du document Titre Documentation technique Legendary Heroes Date 20/03/2013 Auteurs Login Mail Xu Long Long xu_l Weiwen Yu yu_w Philippe Tian tian_p Franck Ibrahima ibrahi_f Jean Thai thai_j Paul Morel morel_e Tableau des révisions Date Version Auteur(s) Section(s) Commentaires 20/03/ yu_w, tian_p, ibrahi_f, morel_e, thai_j, xu_l Toutes Création du document 31/05/ Ibrahi_f IV.1.A Mise à jour des technologies partie client jeu 31/07/ 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/ thai_j VI.13 Mise à jour de la structure base de données 2014/01/ Yu_w Correction et ajout mineur 1

3 Table des matières Description du document... 1 Tableau des révisions... 1 I. Introduction au projet... 5 II. Architecture, buts et contraintes Objectifs spécifiques ayant un impact sur l architecture Contraintes fonctionnelles Contraintes non fonctionnelles... 6 III. Vue Déploiement... 7 IV. Partie jeu Introduction... 8 A. La partie client... 8 V. Partie serveur Technologie utilisées Implémentation a. Démarrage du serveur b. Interface c. Réseau d. Protocole e. Matchmaking f. Session de jeu g. Base de données Diagramme base de données Legendary Heroes VI. Sites internet Introduction de la partie site internet Diagrammes cas d utilisation Technologies utilisées

4 5. Frameworks utilisés Environnement de développement Implémentation Arborescence du domaine Configuration des sous-domaines Les Bundles Les contrôleurs FFFGamesHeaderBundle : HeaderController FFFGamesWebsiteBundle : PortalController FFFGamesLegendaryHeroesBundle : WebsiteController Structure template Base de données Table «user» Table «friends» Table «messages» Table «temporary_registration» Table «admin» Table «chat_rooms» Table «game_website» Table «news» Table «pass_retrieval» Table «profile» Modules Site Portail 3FGames Connexion a. Informations b. Diagramme d activité c. Diagramme de séquence Création de compte a. Informations b. Diagramme d activité c. Diagramme de séquence Site Legendary Heroes

5 Lancement du jeu a. Informations b. Diagramme d activité c. Diagramme de séquence Déploiement sites internet Debian Windows VII. Annexes Release Note Bug Log

6 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 1 er 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. 5

7 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 6

8 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, , 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. 7

9 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 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. 8

10 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. 9

11 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. 10

12 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. 11

13 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. 12

14 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. 13

15 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 14

16 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. 15

17 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. 16

18 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. }; 17

19 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 }; 18

20 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 }; 19

21 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 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. 20

22 Diagramme base de données Legendary Heroes 21

23 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 22

24 Diagramme cas d utilisation site portail 23

25 4. Technologies utilisées Technologie xhtml/css PHP JavaScript Commentaires Langage de formatage classique permettant de créer des pages internet. 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 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 Symfony2 JQuery Commentaires 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 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. 24

26 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. 25

27 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). 26

28 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 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. 27

29 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 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. 28

30 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 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. 29

31 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. Méthode Statut Commentaires 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 . creditspageaction() Prévu Génère la page de crédits du portail 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. Méthode Statut Commentaires 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. 30

32 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. 31

33 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> <!-- Inclusion du titre de la page --> {% block title %}{% endblock %} </title> <!-- Inclusion des feuilles de style --> {% block stylesheets %}{% endblock %} </head> <body> <!-- Inclusion des scripts JavaScript --> {% block javascripts %} {% endblock %} <!-- Appel du contrôleur afin de générer l en-tête --> {% render(controller('fffgamesheaderbundle:header:getheader')) %} <div id="page-content"> <div class="content"> <!-- Inclusion du contenu de la page --> {% block page_content %} {% endblock %} </div> </div> <!-- Inclusion du pied de page --> {% include 'FFFGamesWebsiteBundle:Portal:footer.html.twig' %} </body> </html> Pour plus d informations sur les templates Symfony2, veuillez consulter la documentation. 32

34 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 Table «user» Colonne id username salt password is_active Commentaires Identifiant unique permettant de différencier chaque entrée. Est une clé primaire. Nom d utilisateur. Chaîne de caractères permettant de chiffrer le mot de passe. Mot de passe utilisateur chiffré en MD-512. Adresse de l utilisateur. Indique si l utilisateur est actuellement en ligne. 33