Projet tuteuré N3 MMORPG

Transcription

1 Clément BAERT Alexis BEAUREPAIRE Nathan DAMIE Laurent LAPLACE Valentine MAILLART Emmanuel PERRIN Projet tuteuré N3 MMORPG Tuteur : Jean CARLE Département Informatique Année

2 1

3 Remerciements Nous remercions tout particulièrement Monsieur Jean CARLE, notre tuteur, pour son aide, son suivi régulier, ainsi que ses précieux conseils qui nous ont permis d'avancer tout au long de notre projet. Nous souhaitons également remercier Monsieur Jérôme HENNEBERT pour l'aide qu'il nous a apporté sur la rédaction de notre rapport et sur la préparation de notre soutenance. Nous voudrions aussi adresser nos remerciements à Monsieur Thomas SOETE pour toute l'aide qu'il nous a apporté pour la conception du jeu et le temps passé à nous expliquer les modèles de fonctionnement de grands MMORPG. 2

4 Résumé/Abstract Notre projet est un MMORPG, jeu de rôle en ligne massivement multi-joueur. Nous nous sommes attelés à essayer de comprendre le fonctionnement général de ce type de jeu, et plus précisément quelles étaient les techniques permettant la gestion du flux important de données, transitant dans le jeu. En effet, de nombreuses informations sont nécessaires au bon fonctionnement du jeu ; de l'inscription d'un nouveau membre, à la gestion des combats et de l'inventaire ; et celles-ci doivent être mises à jour de manière régulière pour conserver la cohérence du jeu. Nous avons donc dû créer une architecture client-serveur, permettant l'envoi d'informations au travers d'internet : des joueurs (clients) au serveur de jeu (et inversement). Le jeu se basant sur un univers persistant, nous avons dû intégrer une base de données pour stocker les informations transitant sur le réseau et les mettre à jour si nécessaire. Our project is an MMORPG, Massively Multi-player Online Role-Playing Game. We started to tackle the understanding of the general operation of this kind of game, and more precisely the techniques to manage the significant data stream passing through the game. Indeed, a lot of information is necessary for the proper functioning of the game ; new members registration, battle management, inventories ; and must be updated regularly to maintain the consistency of the game. Also we had to create a client-server architecture, for sending information via the Internet : from the players (clients) to the game server (and vice versa). The game is based on a persistent universe, then we built a database to store information across the network and update if necessary. 3

5 Table des matières Remerciements...2 Résumé/Abstract...3 Introduction...5 I. Les moyens d'organisation et l'analyse des besoins techniques d'un MMORPG...6 A) Les moyens d'organisation dans l'équipe...6 B) Conception du MMORPG...7 II. Le réseau, une nécessité pour communiquer...10 A) Choix des caractéristiques techniques...10 B) Réalisation d'un chat non graphique...10 C) La gestion des données sur le serveur...11 III. La base de données, un moyen efficace pour stocker les données du jeu...13 A) Modélisation et mise en place de la base de données...13 B) La connexion entre le programme et la base de données...14 C) La partie site web...15 IV. L'interface graphique ou comment la machine communique avec le joueur...17 A) Conception et choix de la bibliothèque graphique...17 B) Réalisation...18 Conclusion...20 Annexe 1 : Schéma global du fonctionnement du jeu...21 Annexe 2 : Schéma du réseau...23 Annexe 3 : Modèle Conceptuel de Données...24 Annexe 4 : Site Web (1/2)...25 Annexe 5 : Site Web (2/2)...26 Annexe 6 : Planche de sprites du jeu Ragnarok Online...27 Annexe 7 : Écran de connexion de Ninja Online...28 Annexe 8 : Écran de sélection de personnage...29 Annexe 9 : Image du jeu une fois connecté...30 Glossaire...31 Liens du projet...34 Bibliographie

6 Introduction Poussés par notre curiosité et notre intérêt pour le sujet, nous avons choisi, pour notre projet, de créer un jeu que l'on a nommé Ninja Online. Ninja Online est un jeu de rôle en ligne massivement multi-joueur (plus communément appelé MMORPG, abréviation en anglais de Massive Multiplayer Online Role-Playing Game). Un MMORPG se définit par ces trois critères principaux : l'univers n'est accessible que par un réseau l'univers est persistant, c'est-à-dire qu'il existe tout le temps, que des joueurs y soient connectés ou non l'univers est accessible à un grand nombre de joueurs simultanément Les MMORPG sont nombreux, le plus célèbre étant World of Warcraft de Blizzard, mais il existent aussi d'autres jeux tels que Dofus ou le tout récent mais déjà reconnu Aion de la firme NCsoft. L'histoire de Ninja Online, se déroule dans un Japon médiévale/fantastique où ninjas, samouraïs, maitres Kung Fu ou autres moines Shaolin, se battent pour le contrôle du territoire, et de ses trésors. Souhaitant poursuivre le développement du jeu après le projet, nous avons placé le jeu sous la licence libre GNU General Public License (GNU GPL), la licence la plus utilisée dans le monde du libre. Cela permet à d'autres personnes qui le souhaitent de participer au développement, améliorer les graphismes du jeu ou juste permettre à d'autres personnes souhaitant se lancer dans un projet similaire d'avoir une base sur laquelle se reposer. Le principe général de fonctionnement d'un MMORPG est l'accès de plusieurs clients[1] à un serveur distant, le monde persistant. Toutes les données échangées entre ces deux entités distinctes se font à travers le réseau. On a donc un problème qui se présente à nous : Quelles techniques, dans un jeu vidéo en ligne du type MMORPG, permettent de gérer efficacement les flux de données nécessaires à un monde persistant? Pour répondre à cette question nous verrons donc dans un premier temps comment mettre en place une organisation efficace au sein de l'équipe de développement et nous analyserons les besoins du projet. Nous verrons par la suite qu'un MMORPG est basé sur une structure de réseau et donc qu'une grande partie du projet repose sur ce principe. Puis nous exposerons les raisons qui nous ont poussées à nous poser la question du stockage des données du jeu dans une base de données. Et enfin nous finirons par voir la nécessité d'une interface graphique pour le joueur, pour lui permettre de communiquer avec le serveur via le client. [1] Programme tournant sur la machine du joueur 5

7 Un projet de cette envergure nécessite une organisation des ressources bien définie, et donc une analyse des besoins pour bien répartir ces ressources dans les différentes tâches à exécuter. I. Les moyens d'organisation et l'analyse des besoins techniques d'un MMORPG Pour une bonne organisation au sein de l'équipe, optimiser l'ensemble des communications paraît plus que nécessaire, on doit donc pouvoir partager facilement nos idées, nos programmes et aussi la charge de travail entre les différents membres du groupe. A) Les moyens d'organisation dans l'équipe 1) La synchronisation des données a. Forum L'un des premiers moyens qui a permis les échanges entre les membres du projet a été la mise en place d'un forum[1]. Nous pouvons par ce moyen de communication rassembler nos idées et discuter des choix à prendre tout en gardant une trace écrite, ce qui nous assure une bonne compréhension de ce qui a été dit par chacun des membres de l'équipe de développement. Une question importante est apparue lors du commencement de la programmation : comment partager efficacement nos codes au sein de l'équipe? b. Outil de gestion de version (versionning) Subversion[2] (abrégé en SVN), répond à ce besoin en permettant à un groupe de développeurs de créer un projet en ligne dans une forge[3], afin que ceux-ci puissent s'échanger leurs travaux facilement. Il est donc possible de mettre rapidement et simplement les codes sources en ligne, mais aussi les récupérer sur n'importe quelle machine connectée à Internet. Après un essai de la forge Sourceforge, qui nous a déplu à cause du nombre de important de problèmes qui s'accumulaient (lenteur, impossibilité d'y mettre des images lourdes, ou les librairies nécessaires au projet), notre choix s'est orienté vers CodingTeam.net, forge française, plus rapide car moins saturée et qui nous permet une plus grande liberté. [1] Forum : voir lien dans les liens du projet. Subversion : gestionnaire de forge. [3] Forge : système de gestion de développement collaboratif de logiciel [2] 6

8 2) Partage du travail La charge de travail étant importante, il est nécessaire de se partager et répartir les tâches entre les différents membres du projet. Comme on peut le voir sur l'illustration 1, nous avons découpé le travail en deux parties, une partie réseau (pour rappel le jeu est en ligne, il faut donc pouvoir communiquer au travers de réseaux, Internet notamment), et une partie base de données/web, qui nous permettra de stocker les données du monde et de ses joueurs. Ressources (6 personnes au total) L'équipe base de données, ayant terminé l'implémentation de la base de données, s'est ensuite occupée de la mise en relation des données stockées avec le programme et de l'inscription de nouveaux joueurs pour le jeu. L'équipe réseau, elle, s'est par la suite occupée de la partie affichage/graphique du jeu, puis a relié affichage et réseau. Ensuite, elle a été divisé en deux, une partie qui s'est occupée des personnages et des monstres, et une autre qui s'est occupée de la gestion des coordonnées de chaque objet dans le monde et les déplacements. Réseau (mise en place) Interface graphique Connexion Réseau / Interface graphique Personnages Monstres Gestion des coordonnées de chaque objet dans le monde Base de données Connexion Base de données (mise en place) Programme / Base de données (création de comptes et personnages) Illustration 1 : schéma de répartition des tâches dans l'équipe Temps B) Conception du MMORPG La conception, on l'a vu en cours d'analyse, représente environ 30% de la vie d'un projet, elle est donc essentielle si l'on souhaite créer une application rapidement et efficacement, et mener à terme le projet. 1) Vue globale du fonctionnement d'un MMORPG Comme on peut le voir sur le schéma en annexe 1, le MMORPG se compose de deux programmes différents : le client[1] et le serveur[2]. Il peut y avoir plusieurs clients qui se connectent simultanément au serveur mais il n'y a qu'un seul programme serveur lancé qui centralise les données pour que les clients puissent communiquer entre eux. [1] [2] Client et serveur : voir glossaire. 7

9 a. Le client Le client est contrôlé par le joueur, c'est lui qui décide des actions que doit effectuer le client. Il est donc en attente d'instructions de la part du joueur. Dans le client, on pourra retrouver une partie interface graphique, qui écoute les actions que veut effectuer le joueur et affiche les données qui proviennent du serveur. On a aussi une partie réseau du côté du client qui permet d'envoyer au serveur les actions que veut produire le joueur sur l'environnement et qui reçoit du serveur des données à afficher, comme par exemple où se situent les personnages des autres joueurs qui se trouve à côté de notre personnage. b. Le serveur Son rôle est de diffuser les actions effectuées par chaque joueur. Le serveur valide les actions de chaque joueur, effectue des calculs sur ces données, puis transmet les évolutions du jeu aux autres joueurs. On retrouve du côté serveur une partie réseau qui collecte les messages qui parviennent au serveur et diffuse aux bons clients les messages qui leurs sont destinés. Les messages reçu sont traités par la partie calcul. Cette partie garde en mémoire vive toutes les données du programme et récupère ou stock des données dans la base de données selon les besoins. Toutes les données du jeu sont stockées dans une base de données, on a donc une partie du programme qui permet l'accès à la base de données et ainsi récupérer les informations qui nous intéressent ou faire une sauvegarde des données à garder une fois le programme coupé. 2) La machine serveur Pour la mise en place du serveur, il nous a fallu une machine accessible par Internet pour que chaque client puisse s'y connecter (ainsi que chaque développeur de l'équipe, par SSH[1]) et qui fera tourner le programme serveur et la base de données. 3) Le langage de programmation Pour une gestion optimale du temps qui nous est imparti pour le projet, nous nous sommes rapidement mis d'accord sur le fait que le Java serait utilisé comme langage de programmation pour le jeu, notamment parce que c'est celui que nous avons le plus approfondi en DUT. Nous nous sommes donc consacré entièrement à la conception, la réalisation de notre projet et l'utilisation de nouvelles bibliothèques en Java (comme celle du réseau par exemple) plutôt qu'à l'apprentissage d'un nouveau langage. [1] SSH (Secure Shell) : protocole de communication sécurisé permettant notamment d'exécuter des commandes Unix sur une machine distante. 8

10 Ce langage permet aussi une grande portabilité du jeu car sa machine virtuelle[1] fonctionne sur de très nombreuses plateformes tel que Linux, Mac OS et Windows, mais aussi les téléphone mobiles et bien d'autres. Mais cette qualité en fait aussi sa faiblesse, la machine virtuelle ainsi que la gestion de la mémoire en «garbage collector[2]» sont très gourmands en ressources et pourrait rendre le jeu plutôt lent sur certaines machines limitées en ressources. L'analyse nous a permis de mieux cerner les besoins du projet et cette étape d'organisation de l'équipe de développement permet aussi un gain de temps considérable pour la suite du projet. [1] [2] Machine virtuelle : logiciel ou interpréteur qui isole l'application utilisée par l'utilisateur de l'architecture de l'ordinateur. Garbage collector : gestion de la mémoire en «ramasse-miette». 9

11 Un MMORPG fonctionne sur le principe d'une connexion entre un serveur (le monde) et plusieurs clients (les joueurs), le tout communiquant par le biais d'un réseau. Il a donc fallu nous renseigner sur ce que Java proposait comme solution pour le réseau. II. Le réseau, une nécessité pour communiquer La bibliothèque Java.net nous fournit tout le nécessaire pour la création d'un réseau entre le serveur et les clients. A) Choix des caractéristiques techniques Il nous a fallu choisir entre différents protocoles de connexion (UDP[1] ou TCP[2]), et choisir un port valide afin que les messages entre le serveur et les clients puissent transiter sans soucis de conflits avec d'autres logiciels. D'une part on a le protocole TCP, qui fonctionne en mode connecté. Il prévient le récepteur qu'il va envoyer des données en établissant au préalable une connexion et pendant l'envoi le récepteur envoie des accusés de réception après s'être assuré de la validité des données. Ce protocole est donc considéré comme fiable mais relativement lent. D'autre part on a le protocole UDP, qui fonctionne en mode non connecté, il envoie des données sur le réseau sans prévenir le récepteur, et le récepteur ne confirme pas la réception, on a donc aucun moyen de savoir si le récepteur a bien reçu les données envoyées sur le réseau. Ce protocole est considéré comme rapide mais non fiable. Il devient donc judicieux de choisir le protocole UDP lorsqu'on envisage la connexion de milliers de clients. Cependant, n'en étant qu'à la phase de développement, et n'ayant pas le potentiel marketing d'un jeu commercial, le protocole TCP nous a semblé un choix correct. Le choix du port à écouter pour le serveur doit se faire dans une fourchette supérieur à En-dessous de 1024, les ports sont réservés au système et ne sont donc pas exploitables par une application tierce tel que la notre. On a donc choisi le port 4242 en prenant garde à ce qu'il ne soit pas déjà utilisé par une application couramment installé sur les ordinateurs. B) Réalisation d'un chat non graphique Dans un premier temps, l'équipe réseau a essentiellement travaillé sur l'élaboration d'un logiciel de chat[3] entre deux ordinateurs uniquement, afin de comprendre le fonctionnement et l'échange de flux réseau entre deux machines. La commande nc du terminal Linux a été un outil fort utile pour tester chacune des parties client et serveur du chat. [1] [2] [3] UDP et TCP : protocoles réseau. Chat : anglicisme désignant un logiciel de messagerie instantanée. 10

12 Puis le chat a évolué de telle façon à ce que le serveur puisse gérer les messages entre plusieurs clients, redirigeant les messages aux bons clients permettant à plusieurs clients de dialoguer entre eux. Ce chat nous a servi de squelette pour toute la partie transition des messages sur le réseau de notre programme. On ne s'en sert plus seulement pour les messages de chat entre les joueurs, mais aussi pour les messages qui transportent les informations sur les actions du client sur le monde. Exemple de message envoyé sur le réseau par le client au serveur : 1;Toto;mot_de_passe_de_toto Ici, 1 est le numéro du type du message, un message commençant par 1 est un message du type «demande de connexion au serveur». Toto est le nom de compte du joueur tentant de se connecter au jeu et mot_de_passe_de_toto est le mot de passe entré par l'utilisateur pour le compte Toto. Chaque champs est séparé par un point-virgule, permettant la décomposition et le traitement du message par le serveur. On peut voir sur l'annexe 2 que le serveur écoute sur le port 4242 (grâce à un socket d'écoute) dans l'attente d'une connexion d'un client. Lorsque qu'un client fait la demande au serveur pour se connecter (à l'aide d'un socket d'échange), une connexion bidirectionnelle est crée et on peut donc s'envoyer et recevoir des messages comme s'il s'agissait simplement d'écrire ou lire dans un fichier. C'est le principe du mode connecté du protocole TCP. [1] C) La gestion des données sur le serveur 1) Stockage en mémoire et calcul sur les données reçues Étant donné que l'on a mis en place une base de données distribuée pour tous les clients, on a choisi de faire les traitements proche du stockage, donc sur le serveur. Cela accroit la sécurité des données et permet de gérer au mieux les données envoyées sur le réseau. Pour effectuer ces traitements toutes les données nécessaires doivent être en mémoire vive dans le programme serveur. Nous avons donc créé une structure pour garder le monde en mémoire, un tableau à deux dimensions. Chaque case du tableau regroupe un ensemble de coordonnées du monde. Ainsi chaque case contient une liste de personnages dont les coordonnées se trouvent dans ce bloc de coordonnées, de même pour les monstres. Dès qu'un personnage se connecte, on récupère ses coordonnées de la base de données et on le place dans la bonne case. [1] Socket (prise ou connecteur réseau) : interface logicielle avec les services du système d'exploitation, grâce à laquelle un développeur exploitera facilement et de manière uniforme les services d'un protocole réseau. 11

13 S'il bouge, on vérifie qu'il n'a pas changé de bloc de coordonnées et on prévient les autres joueurs dans le bloc et ceux alentours pour qu'ils puissent afficher correctement le déplacement du personnage à l'écran. Cette notion est importante car elle nous permet de ne prévenir du déplacement que les clients concernés, on n'envoie donc que les données nécessaires sur le réseau. S'il se déconnecte, on le retire de la structure et l'on met à jour ses données dans la base de données. 2) Les personnages et les monstres Le personnage est l'avatar du joueur. Il regroupe un ensemble de données (coordonnées, niveau, points de vie, de compétences...) qui transitent entre le client et le serveur et qui sont sauvegardées très régulièrement dans la base de données. Le déplacement du joueur est géré par le client via le clavier et est interprété par le serveur, ses déplacements sont sauvegardés par intervalle régulier dans la base de donnée afin de garder la position à laquelle le client s'est précédemment arrêté de jouer. Afin d'alimenter notre jeu, qui rappelons-le est un jeu de rôle, donc basé sur une histoire et des monstres à combattre, nous avons voulu introduire cette notion de monstre. Un monstre ou plus communément appelé mob[1] est un élément non joueur qui fait parti intégrante d'un jeu, il est contrôlé par une intelligence artificielle au niveau du serveur pour effectuer ses déplacements et ses attaques. Si le joueur est le héros du jeu, le monstre en est la cible. Pour le moment, le mob se déplace aléatoirement grâce à la fonction random[2] utilisée par le serveur. Nous allons modifier ce mode simple de contrôle pour un mode plus élaboré utilisant le pathfinding[3]. Cela consiste à trouver comment se déplacer dans un environnement entre un point de départ et un point d'arrivée en prenant en compte différentes contraintes. Ses contraintes étant d'éviter les obstacles sur sa route, ou les endroits inaccessibles. Le but de cette fonctionnalité est de pouvoir bien intégrer le mode combat en rendant le mob plus intelligent, lui permettant de prévoir le déplacement du joueur. Le mob nécessite une infrastructure de contrôle, il faut définir le nombre maximum de monstres par type et par zone et le nombre maximum de l'ensemble des monstres pour la zone par exemple. Le réseau est la pièce maîtresse du MMORPG, mais il doit fonctionner en collaboration avec les différentes parties du projet tel que la partie graphique ou encore base de données pour obtenir un jeu complet. [1] Mob : abréviation du terme "mobile", le mob est le terme employé pour désigner les créatures contrôlées par l'ordinateur que le joueur doit affronter. [2] Random : fonction Java qui permet d'obtenir des nombres aléatoirement. [3] Pathfinding : problème de l'intelligence artificielle qui se rattache plus généralement au domaine de la planification et de la recherche de solution. 12

14 Nous venons de voir que dans un MMORPG, de nombreuses informations transitent sur le réseau. Aussi, un grand nombre de ces données doit être stocké (et mis a jour de manière régulière) pour assurer le bon déroulement du jeu (par exemple : les joueurs, les coordonnées des différents personnages sur la carte, les objets, la description des différentes composantes du jeu etc...). Pour stocker ces informations (et y faire appel), nous avons eu recours à une base de données. Cette troisième partie traitera donc de la mise en place de la base de données, et de son intégration dans le projet. Nous aborderons aussi la partie web du projet qui permet notamment la gestion des comptes joueurs. III. La base de données, un moyen efficace pour stocker les données du jeu. A) Modélisation et mise en place de la base de données 1) Modélisation de la base de données Avant de nous lancer dans le projet (et donc dans la création de la base de données), nous avons cherché à modéliser le jeu, au travers des informations qui nous semblaient essentielles et pertinentes à conserver. Comme nous l'avons compris au fur et à mesure du projet, cette étape préparatoire qu'est la modélisation demande une réflexion très longue et très poussée sur ce que l'on désire créer (le jeu «fini») et sur comment travailler pour y parvenir. Aussi, elle doit être faite de manière conjointe, pour éviter les incohérences lors de la phase de réalisation du projet qui suit cette préparation. Pour cela, nous avons tout d'abord listé toutes les données nécessaires à notre jeu (les données à stocker) : ce qui nous a permis de créer le dictionnaire des données. Puis, nous avons réfléchi aux interactions entre ces différentes informations, et avons modélisé le jeu avec la méthode Merise[1] grâce à un Modèle Conceptuel des Données[2] (MCD), refait plusieurs fois pour coller au mieux au jeu tel que nous le pensons (voir le MCD en annexe 3). Et enfin, grâce au Modèle Logique de Données[3] (MLD), nous avons pu créer (générées par le logiciel AnalyseSI à partir du MLD) les tables SQL[4] nécessaires au jeu. [1] Merise : Méthodologie de conduite des projets de développement des systèmes d information basée sur le modèle entité-relation. [2] [3] MCD et MLD : graphes des représentations des données bases sur le modèle Merise. [4] SQL : langage de requêtes utilise par les SGBD (base de données). 13

15 Pour réaliser cette modélisation, nous avons utilisé Acsi (logiciel utilisé au semestre 2) puis AnalyseSI qui, gratuit et libre lui aussi, est plus simple, et efficace. En effet, AnalyseSI permet notamment la saisie des données directement lors de la création des entités, et génère le script SQL de la création des tables d'après le MLD, avantage lors de la création d'une base qui commence à être complexe. 2) Implémentation de la base de données Pour implémenter la base de données, nous avons choisi le système de gestion de base de données[1] (SGBD) MySQL : assez simple tout en étant puissant pour notre projet. De plus, certains d'entre nous connaissaient déjà un peu cet SGBD. La base est stockée sur un serveur personnel, on peut y accéder soit par SSH[2] en mode textuel, soit par navigateur web, en mode graphique (grâce à PhpMyAdmin[3]). 3) Difficultés rencontrées L'un des problèmes principaux que nous avons rencontré avec MySQL est la gestion des clés secondaires, que nous avons décidé d'ignorer pour le moment. En effet, même si ce problème est important, surtout si nous continuons de développer le jeu et que celui-ci attire des joueurs, il n'est pas crucial pour l'instant, et nous avons décidé de continuer sans, et de tester les données directement dans le code, pour ne pas perdre de temps. Nous avons aussi rencontré quelques soucis avec le réseau sécurisé de l'université, qui nous a empêché pendant quelques temps d'utiliser notre base de données. 4) Optimisations Pour notre code, nous avons pris la décision d'ouvrir et de fermer l'accès à la base de données le moins souvent possible. En effet, l'ouverture de la base, et la récupération des données nécessaires (par exemple au démarrage du serveur ou à la connexion d'un client) coûte cher en ressources et en temps. Il nous semble donc judicieux de limiter ces accès. B) La connexion entre le programme et la base de données 1) Technologies utilisées Notre projet étant codé en Java, il nous fallait un moyen pour pouvoir accéder à la base par Java et récupérer (ou modifier) les données qui nous étaient nécessaires. Pour cela, nous nous sommes tournés vers JDBC[4] (Java DataBase Connectivity), qui est une [1] SGBD : logiciel servant à la manipulation des bases de données. SSH : protocole de communication securisé. [3] PhpMyAdmin : interface graphique pour le SGBD Mysql. [4] JDBC : API fournie avec Java permettant de se connecter à des bases de données [2] 14

16 API[1] fournie avec Java permettant de se connecter à des bases de données, et qui nous permet en plus de changer de SGBD librement, au besoin. L'API JDBC (la bibliothèque de classes JDBC), se charge de trois étapes indispensables à la connexion à une base de données : la création d'une connexion à la base (qui se fait grâce à un pilote spécifique, ici celui pour MySQL). l'envoi d'instructions (requêtes) SQL. l'exploitation des résultats provenant de la base. Nous utilisons aussi le paquetage SQL, lui aussi présent dans Java qui contient tous les objets et méthodes relatifs aux bases de données. 2) Réalisation Nous avons notamment implémenté une classe Database qui nous sert à nous connecter ou nous déconnecter d'une base de données. Cette classe est réutilisée à chaque utilisation de la base. Nous avons aussi créé une classe pour gérer la connexion d'un joueur au travers de l'écran de connexion : cette classe permet de vérifier que le joueur est bien membre (possède un compte de jeu) et que ses identifiants (pseudonyme et mot de passe) sont corrects. Pour cela nous avons utilisé l'accès à la base de données, et une classe de chiffrement (que nous avons créé), nous permettant de comparer le mot de passe fourni, au mot de passe crypte stocké dans la base (le cryptage utilise un hachage md5). Mais aussi, diverses classes permettant de récupérer des informations en volumes plus ou moins importants (récupérer les coordonnées des personnages, récupérer tous les joueurs connectés...) et d'effectuer leurs mises a jour. C) La partie site web Nous avions déjà notre forum de développement et notre serveur personnel pour pouvoir y stocker la base de données et le programme serveur du jeu. Mais nous nous sommes très vite demandé comment nos futurs joueurs s'inscriraient à notre jeu. En effet, la plupart des jeux, dont le nôtre, nécessite un compte de jeu, et ce compte doit être créé avant de pouvoir jouer. Nous avions alors deux possibilités : Demander au joueur de télécharger notre jeu, et de s'inscrire en utilisant un écran java. Créer un site internet, et demander au joueur de remplir un formulaire permettant son inscription [1] API (Application Programming Interface) : ensemble de fonctions, procédures ou classes mises à disposition des programmes informatiques par une bibliothèque logicielle. 15

17 La première méthode nous paraissait trop contraignante pour le joueur et trop lourde à produire en si peu de temps. La deuxième nous offrait de réels opportunités en terme de communication et d'accessibilité au jeu : toute l'information est au même endroit, le joueur n'a pas à chercher. Nous avons donc décidé de créer un site web (voir aperçu en annexe 4 et 5) codé en langage php (pour pouvoir gérer l'accès à la base et être dynamique). Ce site permet, entre autres, de : Présenter le jeu et son univers Son histoire, quelques images, ses règles, pourquoi ce jeu... S'inscrire au jeu Pour l'inscription de nouveaux joueurs, nous avons créé un formulaire, qui ajoute les nouveaux comptes dans la base après vérification des données puis confirmation par . Télécharger le jeu Les sources seront disponibles sur le site, elles sont pour l'instant disponibles sur le dépôt SVN. Installer le jeu Grâce aux explications fournis par la documentation en ligne sur le site, ou sur le forum joueurs (différent du forum développeurs), prévu a cet effet. Se connecter Pour consulter son compte, voir ses personnages... Créer ses personnages Nous avons décidé que la création des personnages se ferait sur le site. Des qu'un joueur se connecte, il peut voir ses personnages et en créer de nouveaux (pas plus de 6). La modélisation de notre projet et la base de données nous ont donc permis une meilleure approche pour aborder la gestion du flux de données nécessaires au jeu, et notamment pour le stockage, la réutilisation et la mise à jour de ces dernières de manière efficace et rapide. 16

18 L'interface graphique permet la communication entre l'utilisateur et le client, donc indirectement le serveur. Elle représente aussi le jeu pour l'utilisateur lambda, c'est donc une partie qu'il a fallu travailler pour la rendre attrayante et opérationnelle. IV. L'interface graphique ou comment la machine communique avec le joueur Il est important de préciser que la partie graphique se fait entièrement dans le client, aucune image n'est affichée sur le serveur ou ne transite sur le réseau. A) Conception et choix de la bibliothèque graphique 1) Conception Pour la conception, le modèle MVC[1] (que l'on a vu en cours de POO) peut sembler au 1er abord une bonne option étant donné que l'on sépare l'affichage du reste du programme. L'un des grands avantages du MVC tient au fait qu'il gère l'utilisation de différentes vues pour l'application et aucun traitement n'est effectué dans la vue, on a donc une architecture plus claire et chaque partie est plus facile à maintenir indépendamment. Toutefois, pour réaliser un jeu, ce paradigme n'est pas vraiment adapté, il est plutôt réservé aux applications ayant plusieurs vues, ce qui n'est pas le cas dans un jeu. De plus, c'est un mauvais choix pour les performances du jeu. En effet, la vue est ici rendue au moins 30 fois par seconde, donc passer les données à travers toutes les couches est trop lent. On traite chaque objet à chaque frame, on multiplierait donc cette boucle par le nombre de couches. On a donc certains objets étalés sur la vue et le modèle. 2) Choix de l'api Pour respecter les délais, nous avons choisi un affichage en mode 2D plutôt que 3D qui serait un peu long à réaliser dans les temps. Nous avons donc utilisé la librairie graphique Slick qui gère très bien la 2D. Cette bibliothèque est très similaire à Ucigame (utilisée lors de la nuit de la programmation l'année précédente) mais plus complète que cette dernière. Slick utilise aussi l'accélération graphique grâce à OpenGL, ce qui permet d'utiliser la carte graphique pour le rendu et rend donc le jeu plus fluide. On a, par exemple, grâce à OpenGL, le double buffering[2] activé ce qui permet d'éviter le scintillement d'écran. [1] MVC (Model-View-Controller) : paradigme qui divise l'interface Homme Machine en un modèle, une vue et un contrôleur. [2] Double buffering : technique permettant d'utiliser deux écrans que l'on redessine et permute à tour de rôle pour éviter l'effet scintillement d'un jeu où l'écran est rapidement rafraichi. 17

19 Un des points noirs de Slick est qu'il requiert le JRE [1] de Sun, celui d'openjdk pose quelques soucis de rendu graphique. Il y a donc nécessité pour le joueur d'installer le JRE de Sun pour pouvoir jouer. B) Réalisation 1) Les collisions Lors de la réalisation graphique, il a fallu trouver un moyen de réaliser les collisions entre les éléments du décors et le personnage du joueur (voir des personnages non joueurs par la suite, et qui possèderont une Intelligence Artificielle) pour éviter que ceux-ci ne puissent passer au travers des murs et des objets. Deux options s'offraient à nous : gérer les collisions avec les coordonnées et le serveur qui contient la liste des coordonnées disponibles, ou bien gérer la collision avec des procédés graphiques, c'est à dire que toutes les collisions sont gérées par le client qui connait les positions accessibles ou non. Cette deuxième solution nous offre l'avantage d'un jeu qui paraît plus fluide car on ne sature pas le réseau avec l'envoi de toutes les coordonnées ni le serveur avec les calculs des coordonnées accessibles ou non et elle est utilisée dans le MMORPG World of Warcraft. Mais elle possède néanmoins des faiblesses au niveau sécurité. En effet un joueur pourrait, par exemple, modifier son client pour tricher et passer au travers des murs (ce qu'il était justement possible de faire dans World of Warcraft). On a donc décidé d'utiliser les deux méthodes, on utilise donc le réseau pour vérifier les coordonnées (qui sont dans tous les cas envoyés au serveur) mais le client reste fluide grâce au test des coordonnées en local grâce aux méthodes graphiques de test de collision. 2) Animation d'un personnage Pour réaliser l'animation d'un personnage, il faut faire succéder une multitude d'images, par exemple, pour marcher, il faut afficher l'un après l'autre toutes les étapes du pas. On a donc utilisé des planches de sprites[2], c'est une image avec plusieurs images de tailles égales contenu dedans, tel que l'exemple dans l'annexe 6. Le graphisme du personnage n'est pas encore personnalisable (graphisme par défaut) mais il est prévu par la suite que l'on puisse choisir des détails comme la coiffure et la couleur de cheveux par exemple. 3) Langue d'affichage Il a été décidé très rapidement après avoir commencé la partie graphique que pour tout ce qui était textuel à afficher à l'écran de l'utilisateur, chaque phrase serait lu à partir d'un simple fichier texte, ce qui permet une traduction simple du jeu. Si quelqu'un décidait de le traduire dans sa langue, il aurait juste à traduire le fichier, non pas à traduire tous les [1] [2] JRE (Java Runtime Environment) : machine virtuelle Java Sprite : élément graphique qui peut se déplacer sur l'écran. 18

20 affichages dans le code source du jeu. Le faire dès le début du jeu est une petite perte de temps rapidement compensée par le temps qu'il aurait fallu si l'on avait décidé de le faire une fois le jeu bien abouti. Actuellement les traductions disponibles sont anglais et français. Au final, nous avons créé un écran de connexion où le joueur devra rentrer ses identifiants pour se connecter (voir annexe 7). Puis l'on accède à l'écran de sélection de personnages (voir annexe 8). Une fois le personnage choisi on arrive sur le monde (voir annexe 9). Chaque donnée est affichée selon ce qui est reçu du serveur. 19

21 Conclusion Choisir ce projet nous a permis d'en apprendre beaucoup sur la création et la gestion d'un réseau et la gestion des flux de données entre les clients et le serveur, de l'interface graphique d'un jeu et d'une base de données. Nous avons aussi appris à nous organiser en équipe et répartir les tâches. On a pu aussi noter les difficultés bien réelles à communiquer et faire correspondre le travail de chacun avec ceux des autres. Nous avons aussi noté qu'une conception plus poussée nous aurait permis un gain de temps notable et un programme mieux organisé au niveau des classes, donc plus facilement compréhensible pour un programmeur rejoignant le projet par la suite ou tout simplement pour les autres membres du projet déjà présents. Nous retiendrons donc de ce projet que la rédaction du cahier des charges et la réalisation d'un schéma UML sont des étapes très importantes dans la vie d'un projet. 20

22 Annexe 1 : Schéma global du fonctionnement du jeu Client envoie les données à afficher display Partie graphique. S'occupe d'afficher au joueur toutes les informations nécessaires (son personnage, ceux des autres joueurs, le décors...) et analyse les actions qu'il souhaite produire à l'aide des touches du clavier ou la souris. network envoie les actions effectuées par le joueur Partie réseau du côté client. S'occupe d'envoyer au serveur les messages du client. Internet Serveur calculation, map, mobs, players Partie calcul. S'occupe de garder en mémoire vive toutes les données du serveur (joueurs, monstres, map) et effectue des calculs dessus pour ensuite envoyer aux clients uniquement les informations dont ils ont besoin (par ex, les différents personnages et monstres qui l'entourent). network diffusion des messages Base de données MySQL communication avec la base de données database Partie base de données. S'occupe de la liaison entre la base de données et le programme. Partie réseau du côté serveur. S'occupe de redistribuer aux clients les messages qui leurs sont destinés. accès à la base de données 21 La base de données. S'occupe de stocker toutes les données (pour pouvoir couper le programme serveur sans perdre toutes les informations sur les personnages des joueurs par ex).

23 Légende : Base de données Partie en Java Connexion Internet Flux de données interne 22

24 Annexe 2 : Schéma du réseau Machine 1 Machine 2 Client Serveur Port n x Port n 4242 Réseau (ex : Internet) Légende : Port de la machine Connexion crée entre les 2 machines Socket d'échange Écoute le port Socket d'écoute de port 23

25 Annexe 3 : Modèle Conceptuel de Données MCD détaillé de toute les données comprises dans notre jeu (il manque tout de même les «monstres»). On voit que malgré la «petite» taille de notre jeu, le nombre d'informations utiles est très important. 24

26 Annexe 4 : Site Web (1/2) Page d'accueil : descriptif rapide du jeu, et nouveautés. Accès à la connexion, inscription ou documentation. 25

27 Annexe 5 : Site Web (2/2) Gestion des personnages (nécessite d'être connecté) : affichage des personnages déjà créés (possible suppression) et formulaire de création (choix du nom et de la classe). 26

28 Annexe 6 : Planche de sprites du jeu Ragnarok Online 27

29 Annexe 7 : Écran de connexion de Ninja Online 28

30 Annexe 8 : Écran de sélection de personnage 29

31 Annexe 9 : Image du jeu une fois connecté 30

32 Glossaire API (Application Programming Interface) III. B) 1) Une interface de programmation est un ensemble de fonctions, procédures ou classes mises à disposition des programmes informatiques par une bibliothèque logicielle, un système d'exploitation ou un service. Chat (ou messagerie instantanée) II. B) Anglicisme désignant un logiciel de messagerie instantanée. Permet l'échange instantané de messages textuels entre plusieurs ordinateurs connectés au même réseau informatique. Client I. B) 1) a. Un client est composé d'un ordinateur et d'un logiciel qui envoient des demandes à un serveur. Dans le cas du MMORPG, il s'agit du logiciel manipulé par la personne qui joue. Double buffering IV. A) 2) Technique permettant d'utiliser deux écrans que l'on redessine et permute à tour de rôle pour éviter l'effet scintillement d'un jeu où l'écran est rapidement rafraichi. Forge I. A) 1) b. Système de gestion de développement collaboratif de logiciel. JDBC (Java DataBase Connectivity) III. B) 1) La technologie JDBC est une API fournie avec Java permettant de se connecter à des bases de données et constituée d'un ensemble de classes permettant de développer des applications capables de se connecter à des serveurs de bases de données (SGBD), et profitant des avantages de Java en termes de portabilité du code et d'indépendance du SGBD. Machine virtuelle I. B) 3) Logiciel ou interpréteur qui isole l'application utilisée par l'utilisateur des spécificités de l'ordinateur, c est-à-dire de celles de son architecture ou de son système d'exploitation. MERISE (Méthode d'étude et de Réalisation Informatique pour les Systèmes d'entreprise) III. A) 1) Méthodologie de conduite des projets de développement des systèmes d information basée sur le modèle entité-relation et développée vers Ce modèle est aussi présent dans les systèmes relationnels. MCD (Modèle Conceptuel des Données) III. A) 1) Graphe basé sur un dictionnaire de données (ensemble de données décrites) utilisé par la méthode Merise. Le MCD établit une représentation des données et définit les dépendances fonctionnelles entre elles. MLD (Modèle Logique des Données) III. A) 1) Graphe reprenant le MCD et transformant ses entités en tables. 31

33 MMORPG (Massive Multiplayer Online Role-Playing Game) Introduction Type de jeu vidéo associant le jeu de rôle et le jeux en ligne massivement multijoueur, permettant à un grand nombre de personnes d'interagir simultanément dans un monde virtuel qui est aussi un monde persistant, c'est-à-dire qu'il continue à évoluer lorsque le joueur n'est pas connecté. Mob II. C) 2) Abréviation du terme "mobile", le mob est le terme employé pour désigner les créatures contrôlées par l'ordinateur que le joueur doit affronter. MVC (Model-View-Controller) IV. A) 1) Le MVC est un paradigme qui divise l'interface Homme Machine en un modèle (modèle de données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements, synchronisation), chacun ayant un rôle précis dans l'interface. MySQL III. A) 2) Système de gestion de base de données (SGBD). Selon le type d'application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, autant par le grand public que par des professionnels. Outils de gestion de version (versionning) I. A) 1) b. Ils permettent la synchronisation facile des codes sources des équipes de développement. Ils sont quasiment indispensables quand il s'agit de travailler en équipe dispersé à travers le monde. Pathfinding II. C) 2) La recherche de chemin, couramment appelée pathfinding, est un problème de l'intelligence artificielle qui se rattache plus généralement au domaine de la planification et de la recherche de solution. PhpMyAdmin III. A) 2) PhpMyAdmin (PMA) est une interface de gestion pour système de gestion de base de données MySQL réalisée en PHP et distribuée sous licence GNU GPL. SGBD (Système de Gestion de Base de Données) III. A) 2) Ensemble de logiciels qui sert à la manipulation des bases de données. Il sert à effectuer des opérations ordinaires telles que consulter, modifier, construire, organiser, transformer, copier, sauvegarder ou restaurer des bases de données. Serveur I. B) 1) b. Le serveur attend les messages du ou des clients. Dès qu'un message lui parvient, il le traite et envoie une réponse. Dans le cas du MMORPG, les clients restent connectés à lui, ainsi celui-ci peut aussi envoyer des messages à un client sans que le client en fasse la demande si jamais un autre client a fait une action que d'autres clients doivent savoir. Sprite IV. B) 2) Un sprite est dans le jeu vidéo un élément graphique qui peut se déplacer sur l'écran. 32

34 Socket (prise ou connecteur réseau) II. B) Interface logicielle avec les services du système d'exploitation, grâce à laquelle un développeur exploitera facilement et de manière uniforme les services d'un protocole réseau. SQL (Structured query language) III. A) 1) Langage structuré de requêtes, pseudo-langage informatique (de type requête) standard et normalisé, destiné à interroger ou à manipuler une base de données relationnelle avec : un langage de définition de données un langage de manipulation de données : la partie la plus courante et la plus visible de SQL, un langage de contrôle de données SSH I. B) 2) Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite toutes les trames sont chiffrées. Il devient donc impossible d'utiliser un sniffer pour voir ce que fait l'utilisateur. Le protocole SSH a été conçu avec l'objectif de remplacer les différents programmes rlogin, telnet et rsh. Il permet notamment d'exécuter des commandes Unix sur une machine distante. TCP (Transmission Control Protocol) II. A) Protocole de transport fiable, en mode connecté. UDP (User Datagram Protocol) II. A) Protocole réseau permettant la transmission de données de manière très simple entre deux entités. C'est l'un des principaux protocoles de télécommunication utilisés par Internet. Il est non fiable et en mode non connecté. 33

35 Liens du projet Site et forums Forum pour l'équipe de développement, Site et forum pour les joueurs et testeurs, Subversion Dépôt SVN du projet, Page du projet sur la forge SVN, 34

36 Bibliographie Bases du projet Forge SVN, Commandes SVN, Licence GNU GPL, Java API Java, Réseau Traduction du livre Thinking in Java, Explications sur le concept de socket, Base de données Le SGBD MySQL, Introduction à JDBC, FAQ JDBC, Interface graphique Bibliothèque graphique Slick, 35

37 Notre projet est un MMORPG, jeu de rôle en ligne massivement multi-joueur. Nous nous sommes attelés à essayer de comprendre le fonctionnement général de ce type de jeu, et plus précisément quelles étaient les techniques permettant la gestion du flux important de données, transitant dans le jeu. En effet, de nombreuses informations sont nécessaires au bon fonctionnement du jeu ; de l'inscription d'un nouveau membre, à la gestion des combats et de l'inventaire ; et celles-ci doivent être mises à jour de manière régulière pour conserver la cohérence du jeu. Nous avons donc dû créer une architecture client-serveur, permettant l'envoi d'informations au travers d'internet : des joueurs (clients) au serveur de jeu (et inversement). Le jeu se basant sur un univers persistant, nous avons dû intégrer une base de données pour stocker les informations transitant sur le réseau et les mettre à jour si nécessaire. Our project is an MMORPG, Massively Multi-player Online Role-Playing Game. We started to tackle the understanding of the general operation of this kind of game, and more precisely the techniques to manage the significant data stream passing through the game. Indeed, a lot of information is necessary for the proper functioning of the game ; new members registration, battle management, inventories ; and must be updated regularly to maintain the consistency of the game. Also we had to create a client-server architecture, for sending information via the Internet : from the players (clients) to the game server (and vice versa). The game is based on a persistent universe, then we built a database to store information across the network and update if necessary.