Encadré par : Michel SIMATIC

Réalisé Par : Nizar BEN AYADA Ahmed GHZAIEL Encadré par : Michel SIMATIC

I. PRESENTATION DU PROJET II. PRESENTATION DU MIDDLEWARE GASP 1- PRESENTATION GENERALE : 2- NECESSITE DES INTERGICIELS DANS LE MONDE MOBILE : 3- ARCHITECTURE DE GASP : 4- MODELES D EVENEMENTS : III. PRESENTATION DU JEU FORMULE 1 IV. DEVELOPPEMENT DU JEU 1- ENVIRONNEMENT DE DEVELOPPEMENT : 2- ETAPES POUR LE DEVELOPPEMENT DU JEU : a. Création du circuit b. Lancement du jeu c. Déroulement du jeu d. Intégration du jeu dans GASP V. CONCLUSION VI. ANNEXES Rapport du projet de fin d études 2

Ce projet se déroule dans le cadre du projet de fin d études de l option ASR. L'objectif de ce projet est de développer un jeu multi-joueurs dans un environnement JAVA micro - édition, en se basant pour l'aspect multi joueurs sur l'intergiciel GASP développé par l'int en collaboration avec le CNAM. Le jeu développé est un jeu de course de voitures de Formule1. Les règles du jeu s'inspirent des règles d un jeu de plateau de Formule1, édité par la société Micro Company en 1966. Ce jeu est l'un des premiers jeux de plateau qui se sont basés sur des lancées de dés, non pas pour se déplacer, mais pour décider le déroulement des événements de la course. Ce projet permettra à un joueur muni d'un téléphone mobile de jouer contre d'autres joueurs, via le réseau GPRS/3G. Ainsi, le jeu développé permettra à des utilisateurs du réseau GPRS/3G de se connecter et de s'authentifier sur un serveur GASP. L'un des joueurs devra créer une salle de jeu, dont il sera le propriétaire. Il pourra choisir le nombre minimum et maximum de joueurs. Ensuite, les autres joueurs, connectés sur le serveur GASP pourront rejoindre ce jeu. Le propriétaire du jeu pourra lancer le jeu à n'importe quel moment. Chaque joueur ne peut gérer que la vitesse de sa voiture pendant la course. Les différentes règles du jeu, qui seront explicités plus tard, interviennent après pour appliquer les dégradations au niveau des pneus et des freins. Tout au long de ce rapport, nous présenterons l'intergiciel GASP, le jeu de Plateforme Formule1et le jeu de Formule 1 développé pour téléphone mobile. Rapport du projet de fin d études 3

1) PRESENTATION GENERALE : GASP est une plateforme open source développée en java, conforme à la spécification OMA (Open Mobile Alliance). Elle offre des services de mise en réseau pour des jeux de téléphone mobile en gérant les sessions et la communication entre les terminaux mobiles. Elle est définie pour MIDP et DOJA J2ME profiles. 2) NECESSITE DES INTERGICIELS DANS LE MONDE MOBILE : Dans le monde du mobile, le développement des jeux multi-joueurs présente plusieurs contraintes. En effet, la capacité limitée des terminaux mobiles impose beaucoup de limites devant les développeurs. Par exemple, les exécutables des jeux ne doivent pas dépasser les 200Kb, et l échange des messages entre les joueurs a un coût important pour le joueur. Puis les protocoles utilisés se limitent à http. Pour surpasser ces problèmes, les développeurs des jeux sur mobile se sont intéressés aux intergiciels, qui gèrent l aspect réseau pour les jeux à multi-joueurs, et dont les fonctionnalités sont développées surtout du côté du serveur web, mais aussi côté terminal mobile. Les concepteurs de ces intergiciels pour mobiles visent à créer des standards comme CORBA ou SOAP. 3) ARCHITECTURE DE GASP : Ci-dessous le modèle de données de GASP : Rapport du projet de fin d études 4

Le modèle de données de GASP est une implémentation des spécifications des services de jeux de l OMA (Open Mobile Alliance). Les différents composants de cette implémentation sont : Platform[class]: La classe racine représentant la plateforme. MasterApplicationInstance[class]: La classe qui gère les sessions d un jeu ApplicationInstance[class]: Gère la session d un jeu ActorSession[class]: Représente le fait qu un joueur est connecté à une session du jeu. Cette classe stock tous les événements du jeu adressés pour un joueur. Session[class]: Représente le fait qu un joueur est connecté à une plateforme GASP. Actor[DB->class]: Contient les informations sur l utilisateur d un jeu (nom d utilisateur, mot de passe ) Application[DB]: Un jeu accueillie par la plateforme. User[DB]: Un utilisateur capable de se connecter à la plateforme Rights[DB]: Les droits d un utilisateur pour être connecté à un jeu. Cette spécification permet à GASP d offrir les services suivants : - Les services jeux : Une salle de jeu permettant aux joueurs de la rejoindre et jouer ensemble La gestion du jeu La gestion des comptes - Services système : Gestion des sessions Historique d usage de la plateforme Contrôle d accès Authentification Rapport du projet de fin d études 5

Supervision de la plateforme 4) MODELES D EVENEMENTS : Pour son fonctionnement, GASP met en œuvre un ensemble d évènements explicités par le schéma ci-dessous. Ces événements permettent d assurer le déroulement du jeu en mettant à jour les informations du jeu suite aux différentes actions faites par les joueurs. Les événements qui se présentent dans GASP sont : JoinEvent: représente le fait qu un joueur rejoint une session du jeu StartEvent: Le début du jeu DataEvent: Est utilisée pour transmettre les données Durant une session du jeu entre les joueurs(les clients), et le serveur. EndEvent: La fin du jeu QuitEvent: Un joueur quitte une session du jeu. Rapport du projet de fin d études 6

Formule 1 est différent de tous les autres jeux par le fait qu on n utilise pas les dés pour déplacer les voitures mais seulement pour déterminer les pénalités. La longueur de la course est fixée par les joueurs mais elle ne doit pas être inférieure à 3 tours pour avoir son plein intérêt tactique. Une case de la piste correspond à 30 km/h au compteur, de sorte qu un joueur dont le compteur indique 150 km/h se déplace de 5 cases. Un conducteur peut modifier sa vitesse d un coup à l autre mais il ne peut jamais accélérer de plus de 90 km/h en un seul coup. S il ralentit, il doit supporter la pénalité indiquée sur le «Tableau de Réduction de Vitesse». Au début de la course il est normalement efficace d accélérer jusqu à 90 km/h dès le premier coup et de progresser ainsi de 3 cases. Dès lors on peut, au coup suivant, si on le désire, monter jusqu à 180 km/h et progresser de 6 cases. Il y a lieu de choisir sa vitesse en raison du prochain virage et du risque que l on accepte d y courir. La vitesse indiquée sur la bande rouge de chaque virage est la «vitesse de sécurité» et une voiture qui prend le virage à cette vitesse n encourt aucune pénalité. Cependant il est possible de prendre un virage à une vitesse supérieure de 30 ou même de 60 km/h à la vitesse de sécurité. Si un joueur décide d agir ainsi, il doit jeter les deux dés pour déterminer quelle pénalité il a éventuellement encourue. Celle-ci est indiquée sur le «tableau des pénalités» qui figure au centre de la piste. Un conducteur a plus de chances d être pénalisé, s il franchit la bande rouge en dépassant de 60 km/h la vitesse de sécurité qu en la dépassant seulement de 30 km/h. Si sa vitesse excède de 90 km/h la vitesse de sécurité, il sort automatiquement de la piste. Rapport du projet de fin d études 7

1) ENVIRONNEMENT DE DEVELOPPEMENT : Le développement du jeu est effectué sous JAVA 2 édition micro (J2ME), qui est la version compact du langage populaire de SUN, java. Les raisons du choix de JAVA sont diverses. En effet, Java est la technologie prédominante pour le développement pour les téléphones mobiles. Les estimations pour 2007 affirment que 450 millions de téléphones seront vendus avec le support de JAVA, ce qui représente 75% du marché du mobile. De plus, JAVA est une plateforme libre, ce qui permet de développer un code et le déployer sur un grand nombre de mobiles. Cependant, les différences entre mobiles font que dans certains cas il faut porter quelques changements sur le code afin de faire le portage entre deux mobiles. Toutefois, la majorité du code reste inchangée. J2ME consiste en une suite d outils de développement et d APIs, conçus pour le développement d applications pour les téléphones mobiles. J2ME inclut aussi la «K Virtual machine», qui permet l exécution du bytecode JAVA dans chaque téléphone. En se basant sur le bytecode générique au lieu du code natif d applications. Ainsi, J2ME a l avantage de permettre le développement d un code qui peut être facilement porté sur différents téléphones. En effet, les téléphones sont caractérisés par des différences au niveau de la taille d écran par exemple, ou les capacités graphiques. Pour faciliter le développement de programmes JAVA sur terminaux mobiles, SUN offre le logiciel pour le développement J2ME Wireless ToolKit. Ce logiciel contient un ensemble d outils : Le bytecode «verifier» : Il permet de vérifier les classes avant d être packagées «J2ME emulator» : Il permet de tester le logiciel développé sur le PC «Ktoolbar» : Un environnement visuel de développement, qui permet de compiler, packager et tester le logiciel développé «Provisionning server» : Il permet de tester le téléchargement et l installation du logiciel développé sur le mobile. 2) ETAPES POUR LE DEVELOPPEMENT DU JEU : a. Création du circuit : Le circuit est un ensemble d images élémentaires rassemblées et collées les unes aux autres. Rapport du projet de fin d études 8

Ci-dessous un exemple de circuit : Ce circuit est une combinaison des images élémentaires suivantes : Notre circuit est donc obtenu à partir des images élémentaires grâce à la matrice suivante : 1 2 2 2 3 6 7 7 7 6 6 7 1 2 5 4 2 5 7 7 La création des circuits est clairement une tâche laborieuse. C est pour cela qu on a utilisé un logiciel libre qui s appelle Mappy. Rapport du projet de fin d études 9

Ce logiciel est disponible en téléchargement à l adresse : http://www.tilemap.co.uk/mappy.php Pour pouvoir créer des circuits à l aide de ce logiciel, il faut tout d abord charger les images élémentaires qui vont constituer le circuit, puis dessiner le circuit en plaçant les éléments du circuit dans leurs places. Mappy permet alors de générer la matrice du circuit. Tel qu on l a conçu, notre programme contient une classe Circuit, qui contient les matrices circuits qu on a créé ainsi que d autres données propres à chaque circuit. Pour obtenir un circuit, nous superposons 3 calques : - Un claque représentant l arrière plan. La voiture ne pourra pas survoler ce calque. (Figure 1) - Un calque représentant la route. (Figure 2) - Un calque permettant de détecter les virages. (Figure 3) Figure 1 : le calque contenant l arrière plan Rapport du projet de fin d études 10

Figure 2 : la route, c'est-à-dire la zone accessible par la voiture Figure 3 : calque permettant de détecter les virages Rapport du projet de fin d études 11

Ces trois calques sont superposés pour former le circuit qui s affiche sur l écran. La division en trois calques du circuit permet la gestion des événements dans le jeu. En effet, cela permettra à la voiture de repérer la route et les virages. Algorithme choisi pour permettre de suivre automatiquement la route : La voiture est par défaut sur le calque représentant la route. Elle continue sa route tout droite et vérifie si elle entre en contact avec le calque représentant l arrière plan. Le cas échéant, elle applique l algorithme suivant : - Si la voiture arrive à un virage : Elle teste un changement de direction de 45 vers la droite. - Si elle arrive encore dans le virage : Elle teste un changement de direction de 45 vers la gauche. - Si elle arrive encore dans le virage : Elle teste un changement de direction de 90 vers la droite - Si elle arrive encore dans le virage : Elle teste un changement de direction de 90 vers la gauche Le calque représentant les virages servira quant au déclenchement du processus de vérification de dépassement de vitesse. Ci dessous, notre classe circuit, avec la déclaration des trois calques entourés en rouge. Rapport du projet de fin d études 12

b. Lancement du jeu : La classe Formule1 est la classe principale de notre jeu. Elle hérite de la classe MIDlet et implémente CommandListener. Cette classe gère les éléments du menu qui permettent de choisir le circuit et de lancer le jeu. Elle permet aussi de gérer le lancement du jeu (la méthode startapp( )), la fin (la méthode destroyapp( )), et la mise en pause (la méthode pauseapp( )). c. Déroulement du jeu : Après le lancement du jeu (méthode startapp() de la classe Formule1), une partie du circuit, centrée sur le point de départ est affichée sur l écran avec la voiture. De plus, et en permanence, les indicateurs d usure des freins et des pneus sont affichés en haut à droite. Quant à la vitesse et la position de la voiture dans le circuit, elles sont affichées en haut à gauche. Le nombre de tours effectués est affiché au milieu de l écran. Ci-dessous un aperçu de l écran du jeu : Rapport du projet de fin d études 13

Le déroulement du jeu est géré par la classe FCanvas. Cette dernière hérite de la classe GameCanvas pour pouvoir gérer les types graphiques, et implémente l interface Runnable pour pouvoir utiliser un thread qui permettra de rafraîchir l affichage chaque xx ms. Dans notre cas, nous avons choisi de faire un rafraichissement de l affichage chaque 5 ms. Cette valeur doit éventuellement être modifiée pour mieux s adapter à chaque type de téléphone mobile. L appui sur le bouton UP, augmente la vitesse de la voiture 30 unités, jusqu à atteindre la vitesse maximale de 210 Km/h. De même, l appui sur le bouton DOWN permet la décélération qui d effectue par tranche de 30 unités. Le joueur n a pas à gérer la direction. A chaque virage, l algorithme évoqué précédemment est appliqué. Pour pouvoir gérer l affichage graphique de la voiture suite à un changement de direction, nous avons utilisé la technique suivante : En effet, on fournit une suite d images représentant la voiture dans toutes les directions possibles. A chaque changement de direction, on charge l image suivante ou précédente, selon la direction choisie. Ci-dessous l ensemble d images que peuvent être chargées : Dans le cas d usure totale des pneus, la vitesse se bloque à 60km/h. Rapport du projet de fin d études 14

d. Intégration du jeu dans GASP : Le jeu déployé dans GASP a la structure suivante : Le package sur lequel on a travaillé est app2.client.game. Les autres classes étant fournies et standards pour une classe de jeux. (Sauf NewPlayer et CustomTypes qui sont traités et générés grâce au Moods generator, à partir d un fichier xml selon un modèle, contenant les variables échangées entre les différents joueurs.) On a donc suivi le modèle suivant : Rapport du projet de fin d études 15

Dans la classe GameCanvas du package app2.client.game, on a intégré les éléments graphiques du jeu de Formule1 que nous avons développé, et qui se trouve dans la classe FCanvas. Les classes Actor (Actor, HeroeActor et MultiplayerActor), intègrent les caractéristiques de notre acteur qui est la voiture de course. La classe communication, et qui est présenté par NetworkCom dans le package du jeu, c est la classe qui gère l échange de message avec le serveur de jeu (et avec les autres joueurs). Accéder à un jeu multi-joueur sur une plateforme GASP : 1. Authentification : A la première étape, le joueur doit entrer son nom d utilisateur/mot de passe pour être connecté à la plateforme GASP. Si l opération d authentification est réussie, le joueur reçoit un identificateur de session et un identificateur de joueur, comme présenté ci-après : Rapport du projet de fin d études 16

2. Création de la salle de jeu : Un des joueurs connectés crée une salle de jeu, dont il sera le propriétaire, et donc c est lui qui commencera et arrêtera le jeu. Ce joueur devra donc préciser les propriétés de la salle de jeu : - nombre minimal de joueurs - nombre maximal de joueurs - etc Les autres joueurs trouveront donc le jeu crée et pourront le rejoindre comme démontré ciaprès : Rapport du projet de fin d études 17

Après, le joueur propriétaire de la salle lance le jeu, ce qui permettra de lancer le jeu chez tous les joueurs de la même salle. 3. Pendant le jeu : Chaque joueur joue sur son portable et peut apercevoir ses adversaires. Il pourra quitter le jeu et la plateforme à n importe quel moment. Si le créateur de la salle quitte le jeu, tous les autres joueurs le quitte automatiquement. Rapport du projet de fin d études 18

Tout au long de ce document, nous avons décrit les étapes de développement de notre application, ainsi que les outils utilisés au cours de ce processus. Nous avons aussi décrit l intergiciel que nous avons utilisé, ainsi que le déploiement de l application dans cet intergiciel. Aussi, nous avons évoqué l environnement de développement et la technologie utilisée et ses avantages. Ce projet nous a permit de découvrir une nouvelle cible su marché du développement, qui est les mobiles, et qui n était pas jusqu au là connu pour nous. Nous avons donc pu travailler sur une technologie différente, que nous apprécions. Cette expérience nous a permit de consolider les connaissances que nous avons acquiert dans l option ASR en développant une application réseau, et qui se base sur un intergiciel. Rapport du projet de fin d études 19

ANNEXE 1 : Règles du jeu Total Tableau des pénalités du jeu Formule 1 Mode d'obtention Dépassement de la vitesse limite Dépassement de la vitesse limite de de 30 km/h 60 km/h 2 1.1 RAS Idem 3 1.2 ou 2.1 Sortie de piste Idem 4 1.3 ou 3.1 Usure des pneus=+1 Idem 2.2 RAS RAS 5 1.4, 2.3, 3.2 ou 4.1 Usure des pneus=+1 Idem 6 1.5, 2.4, 4.2 ou 5.1 RAS Usure des pneus = +2 si usure<4. Si usure>=4, sortie de piste automatique 3.3 RAS RAS 1.6, 2.5, 3.4, 4.3, 5.2 ou 7 6.1 Usure des freins = +1 Idem 8 2.6, 3.5, 5.3 ou 6.2 Usure des pneus=+1 Idem 4.4 RAS RAS 9 3.6, 4.5, 5.4 ou 6.3 Usure des freins = +1, usure des pneus=+1 Idem 10 4.6 ou 6.4 RAS Usure des pneus = +2 si usure<4. Si usure>=4, sortie de piste automatique 5.5 RAS RAS 11 5.6 ou 6.5 Sortie de piste Idem 12 6.6 RAS Idem Rapport du projet de fin d études 20