FOXRACER -...

Foxracer IMAC 3

- 1 -

FOXRACER

- IMAC 3 – Programmation

temps réel

Foxracer IMAC 3

- 2 -

Partie A : Généralités (p6) I. Description du jeu (p7)

1. Principe 2. Compatibilité

1. Organisation du projet (p8) 1. Organisation des groupes 2. Les outils utilisés (CVS, Doxygen) 3. Coordination des groupes 4. Prototypes et produit final

Partie B : IHM (p15) I. Le choix du système de fenêtre (p16)

1. Le système de fenêtre 2. L'interface utilisateur 3. Le Head Up Display (HUD)

2. Réalisation de l’IHM (p19)

1. Création graphique 2. Classe et héritage 3. Chargement des XML 4. Utilisation de paraGUI 5. Les différentes interfaces 6. Difficultés rencontrées

Partie C : Réseau (P30) I. Introduction (p31)

1. Tests de faisabilité 2. Technologies utilisées 3. SocketSet

2. Transmission des données avant le jeu (p32) 1. Quelles données transmettre ? 2. Comment transmettre ces données ?

Foxracer IMAC 3

- 3 -

3. Transmission des données au cours du jeu (p33) 1. Quelles données transmettre ? 2. Comment transmettre ces données ? 3. Les défauts du système utilisé... 4. ...et une solution pour les compenser

4. Fonctionnement détaillé (p34)

5. Problèmes rencontrés (p35)

6. Les parties privées et publiques (p35)

7. Quelques idées non implémentées dans cette version (p35)

1. Le chat 2. Le serveur d’échange de modèles 3. Le transfert de serveur

Partie D : Véhicules (p37) I. Conception Générale (p38)

2. Conception d'un véhicule (p39) 1. Réglages possibles 2. Fonctionnement interne (XML) 3. Avantages et inconvénients

3. Gestion des événements (p41)

4. Dynamique du véhicule (p41) 1. Simulation de la gravité 2. Poussée du véhicule 3. Freinage et marche arrière 4. Le contrôle du volant 5. Simulation des suspensions

Foxracer IMAC 3

- 4 -

6. Tenue de route 7. Saut du véhicule 8. Acceleration, vitesse, position 9. Collisions véhicules

5. Affichage du Véhicule (p54) 1. Style graphique 2. Modélisation et exports 3. Chargement et affichage des MD3 4. Les ombres

6. Les bonus et malus (p64)

7. Résultats et bilan (p65) 1. Les chefs : 2. Répartition du travail 3. Interactions avec les autres groupes 4. Les réunions

Partie E : Environnement (p66) I. Présentation (p66)

2. Création des cartes et modèles (p66) 1. XML du monde 2. Les textures 3. Les modèles

3. Chargement et affichage du monde (p70) 1. Économie des transferts vers la carte graphique 2. Économie de la mémoire 3. Effet cartoon 4. Les objets physiques

4. La gestion des types de terrains (p74)

Foxracer IMAC 3

- 5 -

5. La détection des collisions (p75)

1. Le principe 2. Les boîtes englobantes 3. Son intégration dans le programme

5. La gestion des checkpoints (p77) 6. Le système de particule (p77) 7. L’éditeur de cartes (p78)

1. Conception 2. Interface QT 3. Fonctionnalités de l’interface 4. Outils et filtres 5. Affichage du terrain en tps réel 6. Ambiance soleil, mer, brouillard. 7. Positionnement des objets sur la carte 8. Exportation des cartes créées

Partie F : commun (p90) I. Son (p91)

1. Enregistrement et mixage 2. Intégration et gestion du son dans Foxracer

2. Constantes de précompilation (p92)

3. Émulation de RTImage (p92)

4. Support des manettes de jeu (p93)

Partie G : Bilan

Foxracer IMAC 3

- 6 -

Foxracer IMAC 3

- 7 -

Partie A : Généralités

Foxracer IMAC 3

- 8 -

I. Description du jeu 1. Principe

Le jeu Foxracer, troisième de la série Foxenstein, fait revivre vos voitures favorites dans une course sans merci à la victoire finale. Jouable au clavier ou avec une manette de jeu, tout seul ou en réseau, vous ne pourrez bientôt plus passer une soirée sans jouer à Foxracer™ ! 2. Compatibilité

Le jeu a été au départ conçu pour système d’exploitation Linux, ce dernier étant installé sur les ordinateurs des salles de travail de l’université, libre et gratuit. De plus, notre client considérant les autres systèmes inutiles, il était donc primordial de réaliser un jeu parfaitement compatible avec ce système, ce qui a été fait, la plupart d’entre nous travaillant à l’université ou sous Ubuntu. Cependant, plusieurs initiatives sont nées pour faire fonctionner le projet avec d’autres systèmes d’exploitation. La raison principale de ces initiatives était de pouvoir faire fonctionner Foxracer sur nos machines personnelles, de pouvoir le montrer autour de nous, et non pas comme ce fut le cas lors de nos précédentes réalisations, de devoir abandonner le projet à l’université une fois celui-ci fini, faute de compatibilité. Le premier portage a donc été réalisé sur le système Mac OS X, très proche de Linux car reposant sur des bases Unix communes. Le développement sur Mac a donc été conjoint à celui sur Linux, tout ceci s’effectuant de manière quasiment transparente. Les seules difficultés ont été quelques problèmes à la compilation dus à la version 4 du compilateur g++ présente sur Mac (contre la version 3.3 à l’université, plus « tolérante »), ainsi que les librairies à ajouter, notamment paraGUI pour l’IHM ou encore la gestion de PostgreSQL. Dans l’ensemble, le portage a donc été assez facile et permet un fonctionnement similaire sous Mac OS X de Foxracer. Pour le portage sous Windows, il a été jugé préférable d'utiliser une compilation reprenant le compilateur g++, MinGW et des bibliothèques en .a, au lieu d'utiliser Microsoft Visual Studio, trop éloigné de la programmation Linux. Dans un premier temps, Dev-C++ a donc été utilisé. Il a été possible de rassembler toutes les bibliothèques (ce qui fut assez long, vu que les devpaks n'existaient pas toujours), et de compiler correctement, mais le programme n'arrivait pas à s'initialiser pour une raison mystérieuse (probablement un problème de dll défaillante ou à une mauvaise version).Ensuite, la même compilation a été refaite avec CodeBlocks, qui utilise aussi g++. Cette fois-ci, après quelques autres déboires, l'exécution marchait. Seul problème : la fonction IMG_Load de SDL_image ne marchait pas pour une raison inconnue, obligeant à créer un module de chargement de fichiers tga (heureusement, à ce niveau-là du projet, il n'y avait quasiment plus que des tga chargés dans le jeu).L'exécution se fait avec un fichier .bat (script windows) qui récupère les dll (bibliothèques dynamiques) du dossier win32 avant de lancer le programme.

Foxracer IMAC 3

- 9 -

6. Organisation du projet 1. Organisation des groupes

Puisque nous étions 34 étudiants à participer au projet Foxracer, nous avons dû nous répartir en 3 groupes chargés des 3 parties essentielles du jeu : IHM/Réseau, Environnement et Véhicules. La répartition s’est d’abord faite par choix, puis certains membres des groupes Environnement et Véhicules, trop nombreux, ont accepté de rejoindre le groupe IHM/Réseau, pour former les équipes suivantes : IHM/Réseau : François, Bérangère, Anne-Laure, Stéphanie, Lucie, Damien, Caroline, Jonathan, Lynda, Julie, Jana Environnement : Alexis G., Alexis M., Arnaud, Marie, Clément, Flavien, Sereivann, Émilie, Nadia, Catherine, Floriane, Nicolas Véhicules : Thomas P., Olivier, Audrey, Antoine, Laurent, Tharani, Claire, Sandra, Maya, Séverine, Thomas B.

Afin d’optimiser le fonctionnement de ces groupes, de faciliter la communication entre eux et l’organisation de réunions, différents chefs de modules ont été désignés dans chaque groupe. Dans le groupe Véhicules, Laurent et Olivier ont fait office de co-chefs de module. Dans le groupe Environnement, Nadia a été désignée chef de module et Alexis responsable communication. Dans le groupe IHM/Réseau, Anne-Laure a été choisie comme chef de module, et Jonathan expert consultant Jeux Vidéos et plus spécifiquement IHM. Enfin, Damien a eu la responsabilité de chef de projet pour l’ensemble du jeu et pour aider à la coordination entre les groupes. 2. Les outils utilisés (CVS, Doxygen)

a. Utilisation d'un serveur de version, CVS

Sollicitant l'ensemble de la promotion, Foxracer était un projet d'envergure, devant

être développé par prototypes successifs. Nous avions ainsi besoin d'un outil permettant aux différents modules d'êtres développés simultanément et partagés facilement : un serveur de version. Cet outil offre trois intérêts principaux :

le partage des données du “projet” sur un réseau local ou Internet les modifications simultanées de mêmes fichiers du “projet” par plusieurs utilisateurs la sauvegarde de toutes les modifications du “projet” avec la possibilité de revenir à

une version antérieure

Foxracer IMAC 3

- 10 -

L'outil fonctionne le principe client / serveur classique : le serveur fournit l'espace central de stockage des données (un « dépôt »), sous forme d'arborescence, accessible en lecture et écriture au clients, selon un système de droits d'accès (dans notre cas, avec une authentification SSH). Le serveur employé était le logiciel libre CVS, Concurrent Versions System. Le partage de fichier trouve ses limites dans les accès concurrents, modifications de mêmes fichiers simultanément. La solution “copy-modify-merge” de CVS consiste à empêcher les utilisateurs d'envoyer leurs modifications sans partir de la dernière version du projet. Dans ce cas de « conflit », l'utilisateur doit manuellement fusionner les 2 versions (éventuellement, avec des logiciel de fusion graphique, éditeurs de textes permettant de comparer et éditer plusieurs fichiers). Les principales commandes du logiciel sont :

« cvs checkout », pour récupérer la totalité d'un projet « cvs update », pour récupérer les dernières mises à jour « cvs commit », pour envoyer les modifications au serveur

En pratique, le système est fluide et permet un réel travail en parallèle, presque sans attente, les conflits devant rester rares ; même si le facteur critique reste la communication entre utilisateurs, facilitée par les commentaires de code – voir chapitre sur Doxygen et les Coding Conventions – et le respect du travail des autres.

b. Doxygen

Doxygen est un logiciel libre qui permet de générer de la documentation à partir du code source d’un programme. Le développeur doit inclure dans son code des commentaires dans une syntaxe particulière reconnue par Doxygen.

Doxygen peut extraire des informations telles que les noms, les descriptions des classes de leurs membres et de leurs méthodes, l’auteur de la classe, et la version… Le choix de Doxygen documentation s’est imposé du fait de sa simplicité d’utilisation et de sa compatibilité avec plusieurs langages. En effet, Doxygen est destiné, entre autres, aux programmes écrits en C++, Java, Objective-C,PHP, C#, IDL. Il suffit donc, dans un premier temps, de générer un fichier de configuration facilement paramétrable, ensuite de générer la documentation en indiquant le fichier de configuration. Nous avons imposé une convention de commentaires afin que la documentation soit cohérente.

3. Coordination des groupes

Puisque nous étions une équipe assez nombreuse, il était impossible de pouvoir tous communiquer entre nous sur les avancements du projet, de la même façon qu’il était impossible de programmer sur la même version du code en même temps. Le schéma suivant a donc été mis en place au sein de l’équipe de Foxracer :

Foxracer IMAC 3

- 11 -

Ainsi, le chef de projet n’avait en principe que 6 interlocuteurs directs, qui eux-mêmes communiquaient les informations à leur groupe. Ainsi, cela facilitait la propagation de l’information. De la même façon, hormis quelques cas exceptionnels comme la gestion des collisions, qui nécessitait l’implication de plusieurs membres des groupes véhicules et environnement, les chefs de groupe pouvaient communiquer entre eux de problèmes liés à plusieurs modules, sans impliquer nécessairement plus de 20 personnes dans une réunion. De la même façon, pour l’intégration, le code était déjà centralisé par les chefs de modules, qui le regroupaient et le transmettaient à la ou les personnes responsables de l’intégration. 4. Prototypes et produit final Avant d’arriver à la version finale de Foxracer, nous avions choisi de réaliser 3 prototypes du jeu étalés dans le temps et dont voici les principales caractéristiques :

Foxracer IMAC 3

- 12 -

a. Prototype 1 Vendredi 3 novembre

Ce premier prototype a nécessité une véritable intégration. En effet, personne n’utilisait encore CVS et il a fallu réunir une voiture basique sans forces appliquées, un environnement autonome et un prototype d’application utilisant la librairie SDL. Le résultat donna une voiture simple évoluant dans un monde basique, avec une heightmap et donc des collines, des creux,… Il n’y avait pas encore de HUD et la gestion du clavier était plus que basique. Cependant, les bases étaient posées pour l’évolution du projet, et l’ensemble de celui-ci fut placé sur CVS.

Par la suite, les prototypes ont plus fait l’objet d’une deadline que d’une réelle intégration : en effet, l’utilisation de CVS a grandement facilité cette tâche, et chaque jour ou presque à partir du 19 novembre, le projet présentait des avancements visibles. Enfin, la voiture voyait un certain nombre de forces lui être appliquées. Ainsi, si le jeu n’apparaissait pas fondamentalement changé, beaucoup de travail avait déjà été effectué en arrière-plan.

b. Prototype 2 Mercredi 22 novembre

À cette date correspondait la fin des recherches et le début de la véritable intégration du travail de chacun. Ainsi, l’IHM s’est focalisée sur l’utilisation de paraGUI, et les interfaces étaient déjà préparées graphiquement. Le réseau était déjà testé et amélioré séparément à l’application. L’interface In-game apparaissait dans le jeu. La détection des collisions se précisait, et l’environnement finissait la préparation d’une carte, conjointement au développement de l’éditeur de terrains.

Foxracer IMAC 3

- 13 -

c. Prototype 3 Samedi 2 décembre

L’objectif du prototype 3 était de réunir tout, ou au moins un maximum d’éléments du produit final. L’ensemble des modèles de voitures était à peu près finalisé, il ne restait que différents réglages à effectuer sur celles-ci. La nouvelle carte du monde fut quand à elle ajoutée, avec d’autres objets également, ainsi que quelques sons déjà enregistrés. Le réseau, était intégré lui aussi à ce prototype 3, et bien qu’il reste encore quelques réglages pour que toute la synchronisation se fasse bien, l’essentiel était fait.

d. Version finale

La différence entre le prototype 3 et la version finale, même si elle s’est beaucoup ressentie graphiquement, n’a été que l’ajout de différents éléments et d’améliorations précises sur le jeu, comme l’ajout de nouveaux modèles, de fonctionnalités sur l’interface et l’interface In-game, de retouches diverses.

Foxracer IMAC 3

- 14 -

Tout cela pour obtenir, au final, un jeu fonctionnel. Cette version finale pourrait être qualifiée de version alpha. Il reste encore beaucoup de tests à faire pour obtenir une version réellement exploitable par une masse d’utilisateurs, mais le résultat obtenu est d’ores et déjà très satisfaisant…

Foxracer IMAC 3

- 15 -

Partie B : IHM

Foxracer IMAC 3

- 16 -

I. Le choix du système de fenêtre et de la GUI 1. Le système de fenêtre Précisons tout d'abord qu'un très grand nombre de solutions sont disponibles pour mettre en place des systèmes de fenêtres et/ou d'interface graphiques utilisateur. Un certains nombre étaient d'ailleurs suggérées à la fin de l'énoncé du projet. sans les tester toutes, nous avons cependant choisi la librairie SDL - Simple DirectMedia Layer, car elle répondait à plusieurs critères essentiels :

un objectif de jeu vidéo : la SDL est avant tout employée pour réaliser des jeux, et présente toutes les fonctionnalités qui y sont reliées, ni plus ni moins (gestion des évènements, affichage OpenGL, chargement d'images)

l'interopérabilité : les étudiants devant pouvoir travailler sous leur système d'exploitation personnel, le support multi-platforme et multi-OS de la SDL est un atout important

la simplicité : la SDL, très utilisée, est également facile d'accès et bien documentée la licence « open source » : les étudiants IMAC comme leurs enseignants plébiscitent le

logiciel libre ; et la licence GNU GPL de la SDL autorise son utilisation légale et gratuite. Les solutions telles que QT, Glut ou GTK ne rentraient pas dans ces critères principalement car inappropriées au contexte de jeu vidéo ou trop complexes par rapport à la SDL et les besoins réels du projet. 2. L'interface utilisateur A la différence du système de fenêtre, le choix d'une librairie pour l'interface utilisateur ne fut pas évident et il fallu tester de nombreuses solutions différentes. Nous avons d'abord essayé l'interface CEGUI, performante et indépendante du système de fenêtre, mais pouvant s'appuyer sur celui-ci comme la SDL ou Allegro. Ses inconvénients étaient sa gestion interne des évènements d'entrée/sortie, peu élégante à concilier avec celle de la SDL dont nous avions besoin, mais aussi, ses composants moins orientés jeux vidéo que d'autres librairies. La SDLGUI, censée bien intégrée à la SDL, s'est avérée à l'inverse trop limitée et, surtout, trop peu documentée : la documentation n'était pas à jour par rapport au code et certaines fonctionnalités comme le chargement police de caractère ne semblaient pas utilisables. Plusieurs autres librairies que nous aurions souhaité essayer, ne purent pas être compiler sur les machines de l'Université (GuiChan, libuta : librairies manquantes, versions incomplètes, etc.). La librairie ParaGUI s'imposa finalement comme une solution appropriée : orientée jeux vidéo et entièrement basée sur la SDL, elle présentait les composants dont nous avions besoin (champs de saisie de texte, listes, boutons), était bien documentée et simple d'utilisation – même si nous n'avons pas tiré parti de son architecture de « slot » pour les évènements complexes, préférant les gérer directement.

Foxracer IMAC 3

- 17 -

3. Le Head Up Display (HUD)

Une des dernières versions du jeu sous Windows

Pour la réalisation du HUD, il s'est d'abord posé la question de savoir s'il était

préférable d'utiliser les fonctionnalités de Paragui (ou toute autre bibliothèque de GUI que nous aurions utilisé pour le menu principal), ou bien SDL. Pour des raisons d'indépendance du GUI par rapport au jeu lui-même, SDL a été envisagé.

Mais l'affichage en SDL n'a pas marché pour une raison inconnue (en réalité, c'est tout

l'affichage en 2D sans accélération graphique qui ne marchait pas, puisque glDrawPixels ne marchait pas non plus). Il a donc fallu faire l'affichage directement en OpenGL, en chargeant des textures en mémoire graphique. Cette solution prend plus de temps à charger à l'initialisation, mais est plus optimisé ensuite. C'est ce qui a donc provoqué l'apparition de classes singletons :

FoxDisplay : o Chargement de fichiers images sous forme de surfaces SDL ou de textures. o Utilise SDL, SDL_image et OpenGL. o FoxDisplay définit une petite structure nommé "Texture", permettant de manipuler

des textures avec facilité. o FoxDisplay dirige aussi l'émulation de RTImage.

FoxFont :

o chargement des fonts et du texte sous forme de surfaces SDL ou de textures. o Utilise SDL, SDL_ttf et FoxDisplay.

Foxracer IMAC 3

- 18 -

IhmDisplay : o affichage des textures, en 2D au moyen d'OpenGL, avec éventuellement

redimensionnement et rotation.

Le tout est utilisé par IhmHud, qui n'a plus qu'à charger tout un paquet de "Texture" avec FoxDisplay et FoxFont et de l'afficher avec IhmDisplay. Les paramètres (vitesse, position, etc.) sont passés en paramètres de la méthode draw, appelée dans FoxGame. Par la suite, comme il n'existait pas encore de module gérant une course donnée, le singleton FoxSession a été rajouté. Ce dernier travaille en parallèle avec IhmHud et le réseau, et définit l'état de la course (attente des joueurs, course commencée, etc.).

Foxracer IMAC 3

- 19 -

8. Réalisation de l’IHM 1. Création graphique

a. Point de départ Le travail des graphistes était d’élaborer la charte graphique du jeu, et d’imaginer les

différentes interfaces que le joueur va avoir l’occasion de côtoyer tout au long de la sélection des différentes caractéristiques de sa partie. A la suite de la première réunion entre chefs de projets, il a été décidé que le jeu serait une course de voitures, et que celui-ci aurait une ambiance plutôt cartoon et humoristique.

Partant de cette idée, nous avons commencé nos recherches en nous inspirant à la fois des

jeux de courses de voiture déjà existant sur console ou sur PC, mais également des différents éléments composant l’univers de la Formule 1 en général. Suite à ces recherches, nous avons établis différents mots clefs dont nous voulions nous servir pour commencer la charte graphique. Nous avons ensuite cherché des graphismes qui pourraient correspondre aux mots précédemment définis.

Course, départ, arrivée Marquage aux sols, macadam Renard, personnage Vitesse, flou, voiture Médaille, coupe, podium Circuits, feux et panneaux de circulation Voiture, route, public Drapeaux, public, panneaux de sponsorisation

b. Les couleurs En ce qui concerne les couleurs, nous voulions avoir des teintes chaudes et gaies, c’est

pourquoi nous avons choisis de privilégier le rouge, l’orange et le jaune. Et pour garder l’esprit de la course de voiture, nous avons aussi choisit le gris de l’asphalte et le blanc des différents marquages au sol

Foxracer IMAC 3

- 20 -

c. Les polices Pour les polices, nous avons cherché un caractère exprimant la rapidité et la vitesse

tout en gardant à l’esprit que l’on devait aussi rester dans un style cartoon et fou. La police de titre a été facilement trouvée et conservée tout au long des différentes évolutions du graphisme de l’interface. Elle respecte en effet l’impression de vitesse et l’on peut de plus composer le texte de façon à avoir une boule de poussière à la fin du texte montrant clairement l’impression de vitesse.

Sous l’écoute des critiques des différents participants au projet, nous avons entrepris une

toute autre interface, en faisant attention à ce qu’elle soit plus colorée, plus en rapport avec la course, et en lui donnant un côté plus cartoon. Nous avons essayé alors d’ajouter plus d’images en relations avec les mots clés que nous avions établis, pour animer un peu plus l’interface. Pour renforcer l’esprit jeu et de le rapprocher de l’univers informatique, nous avons par ailleurs choisit de représenter la foule en délire amassées sur le bord de la course dans un style pixel et coloré et de faire tenir à certains personnage les différents drapeaux qui permettent d’accéder aux menus secondaires.

Nous avons également rajouté des éléments pour une meilleure compréhension du déplacement dans les menus et boutons. Par exemple nous avons placé un bouton de validation qui représente un drapeau qui bouge lorsqu’on le survole ou encore un bouton de retour (ou quitter dans l’exemple) qui représente la banderole d’arrivée. Celle-ci est vide, mais lorsqu’on survole le bouton, la voiture se place en dessous comme montré dans l’exemple ci-dessous.

- Premier jet de l’interface d’accueil de Foxracer -

Foxracer IMAC 3

- 21 -

Nous avons fait de sorte à pouvoir changer facilement la police, la couleur de celle-ci ainsi que le fond, afin de pouvoir faire des modifications à tout moment, de la même manière qu’une feuille de style. Ce qui a facilité les nombreux changements qui ont pu avoir lieu au cours du projet.

L’interface a eu de meilleurs retours. Néanmoins, il semblait que celle-ci paraissait encore un peu sévère par rapport à l’image que l’on se fait d’une interface de type cartoon. De plus, Au cours d’une réunion avec les membres de l’équipe d’Ihm, nous nous sommes rendu comptes qu’entre les interfaces et l’allure du jeu qui prenait petit à petit forme, nous n’avions pas assez de liaison et rappels. Il manquait une unité entre les interfaces et le jeu.

Nous avons donc retravaillé cette interface en l’adoucissant et en lui donnant finalement

une teinte plus verte, rappelant le vert dominant autour du circuit du jeu. Nous avons également placé le public sur de l’herbe. Mais surtout nous avons repris les petites voitures de courses qui figurent dans le jeu et nous les avons mises en scène dans notre interface. De plus les polices des menus ont été changées afin de mieux correspondre aux polices présentes dans le jeu en lui-même.

Julie il faut ici l’interface de bienvenue de fox racer il y a encore quelques jours !

- Deuxième jet de l’interface d’accueil de Foxracer -

Foxracer IMAC 3

- 22 -

Nous avons également fait de sorte à ce que la couleur du texte change au survol de celui-ci, et dans le cas des sous-menus, la voiture de oui-oui se place à côté du texte sélectionné.

SLa collaboration entre les graphistes s’est toujours bien déroulée. Nous avons fait un travail d’équipe, tout en tenant compte des critiques extérieures qui amènent un point de vue objectif à notre travail. Nous sommes satisfaits d’avoir abouti ce travail tout en réjouissant nos collègues du résultat final. Foxracer est un jeu à part entière qui a une unité graphique complète.

2. Classe et héritage Paragui est, comme beaucoup d'APIS, basée sur des héritages : il faut créer des classes héritées de classes de Paragui pour pouvoir avoir ce qu'on veut. De cette manière nous avons créé une classe IhmWidget héritée de PG_Widget, et une classe IhmLineEdit héritée de PG_LineEdit par exemple. Chaque écran du menu principal est une classe qui hérite de IhmWidget, et qui redéfinit la méthode manageEvents. Cette méthode gère les évènements claviers, en utilisant SDL. Tous les écrans du menu principal sont gérés directement dans la classe FoxGame, qui les initialise et leur envoie les évènements.

- Interface d’accueil finale de Foxracer -

Foxracer IMAC 3

- 23 -

3. Chargement des XML

Voici un une partie du fichier XML qui nous a permis de récupérer les noms et le nombre de roues des voitures à afficher : Pour parcourir le fichier XML, on a utilisé un analyseur syntaxique proche du SAX (Simple API for XML) basé sur un mode événementiel qui permet de parcourir le fichier XML selon les événements que nous lui indiquons et de traiter seulement ce qui est nécessaire. <vehicles> <carosseries>  <carossery id="0"

name="Dragster" modelName="vehicle02/carodrag.md3" textureName="vehicle02/carodrag.tga" textureShadow="shadows/shadowcool.tga" textureParticule="smoke.tga" aero="0.31" surface="480" weight="2000" length="3.0" width="1.5" heightBack="0.09" heightFront="0.4" coefBody="0.5" yAdjust="0.012" zAdjust="1.0">

 <wheel id="0"

modelName="vehicle02/roueardrag.md3" textureName="vehicle02/rouedrag.tga" weight="20" type="aft" coefWheel="0.5" />

<wheel id="1" modelName="vehicle04/rouearflam.md3" textureName="vehicle04/roueflam.tga" weight="20" type="aft" coefWheel="0.5" />

</carossery> …

On récupère à partir du fichier tous les noms et ids de voitures, correspondant aux balises « carossery », et on fait de même avec leurs roues contenues entre les balises « wheel ». On affiche les noms des voitures et autant de roues, différenciées par leur couleur, qu’une voiture possède et le joueur peut choisir la voiture qu’il va utiliser durant le jeu. Un visuel permet au joueur de voir l’allure de la voiture choisie et la couleur de ses roues.

Lors du choix du type de voiture et de la couleur des roues, les choix sont envoyés à

l’interface suivante c’est à dire celle qui propose de choisir son moteur, ses freins,... A la validation de celle-ci, toutes les caractéristiques de la voiture (type, couleur et force des roues, moteur, suspensions, freins) sont envoyés au serveur qui se charge alors de créer le véhicule et de l’ajouter au monde. Au démarrage du jeu, la voiture se trouve alors sur la ligne de départ avec toutes les caractéristiques choisies par le joueur.

Foxracer IMAC 3

- 24 -

4. Utilisation de paraGUI

ParaGUI nous a donc servi à créer nos différentes interfaces du jeu à savoir celles qui permettent le choix du monde et des diverses caractéristiques du véhicule, l’identification et la connexion du joueur au jeu. ParaGUI nous a permis de rajouter différents éléments graphiques sur chacune de ces interfaces.

a. Les interfaces Les interfaces sont en fait des fenêtres créées à l’aide de la classe PG_Widget de ParaGUI. PG_Widget offre plusieurs méthodes permettant diverses actions sur la fenêtre créée tels que l’ajout d’éléments graphiques, la gestion des événements clavier ou souris et l’affichage d’autres fenêtres « filles ».

b. Les labels PG_Label, comme son nom l’indique, donne la possibilité de créer des labels, c’est à dire des champs affichant du texte. Ces labels ont souvent été utilisés pour les titres et sous titres et les choix proposés sur les interfaces.

c. Les champs de saisie La création des champs de saisie s’est faite via l’utilisation de la classe PG_LineEdit. Ces champs nous permettent de récupérer le pseudo du joueur ou encore les différents paramètres demandés pour la connexion du joueur sur le serveur du jeu.

d. Les boutons Les boutons sont obtenus grâce à la classe PG_Button et permettent de valider les choix du joueur dans les menus ou de passer soit à la fenêtre précédente via le bouton « Retour » soit à la fenêtre suivante via le bouton « Valider », ces deux boutons se retrouvant quasiment sur toutes les interfaces. 5. Les différentes interfaces

Pour se déplacer au sein des différentes interfaces il suffit d'utiliser les touches haut, bas, gauche, droite ainsi que la touche enter. Les touche haut et bas permettent de changer de menu, enter permet d'entrer dans un sous menu, et de valider son choix, enfin les touches gauche et droite permettent de se déplacer au sein d'un sous menu. Lorsqu'un choix est sélectionné ou validé le texte change de couleur afin de permettre au joueur de bien visualiser sa sélection.

Chacune des interfaces permettent de valider et de passer à l'interface suivante en amenant

le curseur sur le drapeau valider, ou permettent de retourner à l'interface précédente via le bouton retour, comme prévu précédemment lors de la création graphique ?

Foxracer IMAC 3

- 25 -

a. Schéma de l’enchaînement des interfaces Accueil Partie Solo Partie Multi-Joueur Partie Privée Partie Pulique

Choix du Pseudo Choix du véhicule Personnalisation du véhicule

Foxracer IMAC 3

- 26 -

Lorsque le joueur lance Foxracer, il arrive directement sur l’interface d’accueil que voici :

Elle donne la possibilité à l’utilisateur de choisir le type de partie pour son jeu, via les flèches haut et bas du clavier. Il lui suffit de valider en tapant sur enter pour accéder à l’interface choisie :

Partie en solo, Partie multi joueur, Rejoindre une partie privée Rejoindre une partie publique Quitter le jeu.

b. L’interface partie Solo

Dans un premier temps, le joueur pourra choisir le monde dans lequel il veut que la course se déroule. Plusieurs univers différents sont à sa disposition, avec un aperçu et une description succincte.

Ces informations sont récupérées dynamiquement via la lecture d’un fichier xml. Ceci permet de pouvoir rajouter ultérieurement d’autre monde au jeu, et d’enrichir un peu plus le choix de l’utilisateur.

Ensuite il peut déterminer le niveau de la course.

Foxracer IMAC 3

- 27 -

c. L’interface Multi joueur

Cette interface reprend des éléments contenus dans l’interface de partie Solo, notamment le choix du monde, et le niveau de la course. Mais elle permet en plus de déterminer plusieurs informations nécessaires à la mise en place d’une partie multi joueur.

Trois champs texte permettent de

spécifier respectivement le port tcp à utiliser, le port udp ainsi que le nombre de joueurs maximum pour la course. Ces informations seront directement récupérées pour mettre en place le réseau.

Le joueur pourra ensuite choisir entre une partie privée ou publique. A noter que lors de

la validation, le contenu des champs de saisie est testé, si l’un d’entre eux est vide ou bien invalide une interface de message d’erreur apparaît.

d. L’interface Personnalisation de la partie

Ici le joueur peut spécifier le nom de la partie, le nombre de tour à faire avant de franchir la ligne d’arrivée et enfin le pseudonyme qu’il aura lors de la course.

Tout comme dans l’interface

précédente la validité des champs de saisie sera testée avant de pouvoir passer à la suite.

Foxracer IMAC 3

- 28 -

e. L’interface de rejoindre une partie Privée

Le joueur peut choisir de rejoindre

une partie privée, auquel cas, il devra remplir les informations sur l’adresse ip, le port tcp, le port udp, ainsi que le pseudonyme qu’il aura lors de la course.

Tout comme dans l’interface

précédente la validité des champs de saisie sera testée avant de pouvoir passer à la suite.

f. L’interface rejoindre une partie Publique

Si le joueur choisi de rejoindre une partie publique, il devra saisir son pseudonyme et sélectionner la partie (le serveur) de son choix.

Il pourra ensuite valider pour

passer à la suite ou bien retourner sur l’interface précédente.

Foxracer IMAC 3

- 29 -

g. L’interface choix du véhicule

C’est au sein de cette interface que le

joueur peut choisir la carrosserie de son véhicule, sa couleur, ainsi que les roues.

Lors de la sélection des models, un

aperçu s’actualise permettant au joueur de visualiser précisément sa voiture.

Les différents models de voiture et les

roues sont chargées dynamiquement via un fichier xml, ce qui permettra de pouvoir rajouter aisément de nouvelles carrosseries donnant ainsi plus de choix aux joueurs.

h. L’interface de caractéristique de la voiture

Le joueur doit spécifier 4

caractéristiques différentes pour son véhicule.

La puissance du moteur, la qualité des

pneus, le système de freinage, et enfin le type de suspension.

S’il ne valide pas ses 4 caractéristiques,

des valeurs par défaut leurs seront associées.

On notera que le véhicule choisi au préalable par le joueur s’affiche dans cette interface.

Foxracer IMAC 3

- 30 -

6. Difficultés rencontrées

Le principal enjeu pour les graphistes est de faire une interface qui plaise à tout le monde, ou du moins à la majorité. Il a fallu, à plusieurs reprises, modifier leur allure car les images actuelles n’étaient pas au goût du jour.

Le seul réel problème que nous avons rencontré est la différence apparente entre l’interface de la course et toutes les autres, celle-ci ayant été faite par un autre membre de l’équipe. Nous avons donc essayé de nous rapprocher au mieux de cette interface de jeux et c’est pourquoi nous avons modifié les teintes ainsi que la police des autres interfaces. Nous avons également demandé à la personne responsable de l’interface de jeu de placer certaines de nos images sur son interface.

ParaGUI est apparue comme étant assez simple d’utilisation pour la création des

différentes interfaces. Seulement quelques difficultés sont apparues, en particulier lors de la gestion des événements externes (clavier ou souris) sur certains éléments graphiques (bouton et champs de saisie) ajoutés à une fenêtre donnée.

En effet, il nous a fallu quelque temps et pas mal d’essais pour comprendre que la seule façon d’intercepter les événements externes était de considérer ces éléments graphiques comme des widgets. Pour cela, il a fallu créer des classes supplémentaires pour chacun de ces éléments et les faire hériter des la classe PG_Widget.

Mais cela ne suffit pas car lors de l’ajout de ces mini-widgets à l’interface (Widget) mère, il nous a toujours pas été possible de récupérer les événements et pour cela il a fallu faire en sorte de renvoyer les diverses événements externes aux éléments graphiques qui à leur tour peuvent enfin associer une action à un événement.

Un autre problème s’est présenté au cours de l’utilisation de ParaGUI : le manque de

documentation sur cette application. Sur le site www.paragui.org, nous retrouvons de la documentation sur une seule version : la 1.8, et ce presque sans aucune explication d’utilisation ou de mise en pratique de la librairie GUI. De plus, le fait que pour notre projet nous utilisons la version 1.4 de ParaGUI, assez différente de celle proposée en ligne, nous a un peu plus compliqué la tâche lors de l’utilisation de certaines méthodes.

Foxracer IMAC 3

- 31 -

Partie C : Module Réseau

Foxracer IMAC 3

- 32 -

I. Introduction Le projet nous imposait un jeu en réseau fonctionnant sur le réseau Ethernet de la faculté.

Nous avions par contre le choix en ce qui concerne la gestion des serveurs et les technologies utilisées. Nous avons choisi lors de la conception de mettre en place un protocole, nous imposant les étapes à suivre pour le développement, à savoir qui envoie quoi et comment. 1. Tests de faisabilité

Afin d'être sûr que notre choix de bibliothèque était le bon, nous avons testé ses capacités et ses limites. Le but de ces tests était aussi de savoir ce qui était possible d'envoyer en TCP et en UDP et de comprendre comment fonctionnait la bibliothèque SDL_Net.

Nous avons donc testé les classes TCP Sockets, UDP Sockets et UDP Packets de cette

bibliothèque sur des exemples simples que nous avons récupéré dans le guide d'utilisation SDL_Net.

Ces premiers tests nous ont permis de voir que l'on pourrait passer toutes les informations

dont nous avons besoin par le réseau. 2. Technologies utilisées

a. TCP /UDP

Pour communiquer les données nécessaires au bon fonctionnement du jeu en réseau, nous avions le choix de les transmettre via le protocole TCP ou le protocole UDP. Le protocole TCP (Transmission Control Protocol) est un protocole dit de communication en mode connecté. Il dispose d’un système de détection d’erreur, c'est-à-dire qu’il procède par acquittement des données ce qui assure que les données émises seront bien reçues.

Le protocole UDP (User Datagram Protocol), contrairement au protocole TCP travaille en mode non-connecté : il n'y a donc pas de moyen de vérifier si tous les paquets envoyés sont bien arrivés à destination et ni dans quel ordre. Toutefois puisqu’il ne dispose pas de détection d’erreur il est donc beaucoup plus rapide que le protocole TCP pour l’envoi des données.

b. SDL_Net

SDL_Net est une bibliothèque de réseau fonctionnant avec SDL. SDL est une bibliothèque multi-plateformes, elle supporte donc Linux, Windows et Mac. Nous avons choisi d’utiliser cette bibliothèque car d’une part, elle permet d’utiliser les fonctionnalités réseau de manière simple et intuitive et d’autre part, la partie fenêtrage utilisant la SDL est plus pratique.

Nous avons toutefois recherché des études comparatives de performances entre la SDL_Net et QTNetwork mais hélas nos recherches n’ont pas été fructueuses.

Foxracer IMAC 3

- 33 -

Nous nous sommes aperçus lors de notre développement que la SDL_Net ne nous permettait pas de faire tout ce que nous voulions comme récupérer l’adresse IP de la machine, ce que QTNetwork permet. Nous avons remédié à ce problème en combinant à la SDL_Net les bibliothèques réseau du système. 3. SocketSet

Pendant le jeu, l'application doit sans cesse rester à l'écoute des deux ports, TCP et UDP,

en attente de nouveaux messages.

Les libraires SDL et SDL_Net nous offraient deux possibilités :

• l'utilisation de fonctions bloquantes pour attendre un message, appelée dans un thread spécifique

• l'utilisation d'un socketSet, permettant de tester de façon non bloquante si un message est en attente

Nous avons opté pour la deuxième solution. La vérification est intégrée dans la boucle d'évènement SDL du programme. Elle reste plus rapide que l'utilisation de plusieurs threads tant que le nombre de clients n'est pas trop élevé. Au dessus d'une dizaine de clients, cette solution ralentirait le jeu. Mais dans notre cas, le choix a été fait d'avoir au maximum 8 joueurs simultanés, cette solution est donc meilleure.

7. Transmission des données avant le jeu

1. Quelles données transmettre ?

Avant le lancement de la partie, le joueur doit configurer certains paramètres qu’il soit

serveur ou client. Lorsque le joueur crée sa partie, il configure les ports à utiliser, la carte du jeu, le nombre de tours, le nom de la partie et le nombre de joueurs maximum. Lorsque le serveur est crée les joueurs peuvent demander à rejoindre la partie. Si le serveur refuse, le joueur est renvoyé à l’interface d’accueil. Si il accepte le joueur, il lui envoie le nom de la carte et le nombre de tours afin que le client puisse charger le monde. Le joueur envoie alors au serveur les informations concernant la voiture qu’il a sélectionnée.

Lorsque le serveur décide de lancer la partie, il envoie à tous les joueurs les informations

concernant les autres joueurs afin que chacun possède la liste des joueurs de la partie et charge les voitures.

Lorsque tous les joueurs ont fini de charger, ils envoient au serveur un message de bonne

réception. Le serveur lance la course dès lors qu’il a reçu un accusé de réception de la part de tous les joueurs. 2. Comment transmettre ces données ? Nous avons utilisé le protocole TCP pour transmettre ces données car elles doivent être impérativement reçues pour assurer le bon fonctionnement de la partie.

Foxracer IMAC 3

- 34 -

8. Transmission des données au cours du jeu

Lorsque la partie est lancée, les différents joueurs doivent communiquer entre eux afin que leurs voitures s'affichent chez tout le monde au bon endroit. 1. Quelles données transmettre ?

La première solution qui nous est venue à l'esprit était, comme nous l'avions fait dans les projets précédents, de transmettre à intervalle régulier les informations de position et d'orientation de chaque voiture. Cependant, nous nous sommes rendus compte que le rendu serait alors très peu fluide.

Nous avons donc retenu une autre solution : ce sont les actions des joueurs (c'est-à-dire les

appuis sur les touches) qui sont transmises. Chaque programme client calcule alors les positions de toutes les voitures de la même manière que la voiture contrôlée par le joueur correspondant. Le déplacement des voitures est donc très fluide. 2. Comment transmettre ces données ?

Nous avions le choix entre le protocole TCP et le protocole UDP. Nous avons choisi

l'UDP pour sa rapidité. En effet, le choix d'envoyer les actions sur les touches impliquait un grand nombre de petits paquets à envoyer. De plus, la librairie SDL_Net permet d'envoyer un paquet UDP à tous les clients à la fois, par le biais de channel, ce qui est très pratique pour le serveur qui transfère tous les paquets. 3. Les défauts du système utilisé...

Ces choix ont toutefois des défauts. L'utilisation de l'UDP implique une perte possible

d'information. De plus, une petite erreur de précision, ou un paquet perdu, a une grande répercussion sur la suite de la trajectoire du véhicule concerné, puisque les informations qui transitent par le réseau ne permettent qu'un calcul relatif à la position précédente (qui peut être fausse). On a ainsi pu observer des trajectoires complètement différentes pour une même voiture sur les deux machines de jeu. 4. ...et une solution pour les compenser

Nous avons donc constaté qu'une synchronisation des valeurs réelles de position,

orientation et forces appliquées était nécessaire. Une telle solution avait été envisagée dès le départ, car les défauts du système nous étaient connus. Le choix du TCP pour cette synchronisation s'imposait, puisqu'elle était censée compenser les défauts de l'UDP. A intervalle régulier, donc, chacun envoie les informations nécessaires à la synchronisation.

Foxracer IMAC 3

- 35 -

Cependant, ce système n'est pas encore parfait, car on voit à l'écran les voitures des

concurrents « sauter » d'une position à l'autre au moment de la synchronisation. Le jeu perd donc en fluidité mais gagne considérablement en fiabilité. On pourrait imaginer de remettre progressivement les voitures au bon endroit en les faisant bouger en ligne droite pour que le déplacement brutal soit moins visible.

9. Fonctionnement détaillé

Foxracer IMAC 3

- 36 -

10. Problèmes rencontrés

Le format d’envoi de données nous a posé quelques problèmes. En effet, plusieurs informations devaient être transmises dans le temps, nous avons donc cherché à envoyer un bloc de données sous la forme d’une map et sous la forme d’un objet. Malheureusement, ces moyens se sont avérés inefficaces. Nous avons remédié au problème en parcourant nos données et en les envoyant (et en les réceptionnant) une par une sous forme de chaîne de caractères séparés par un marqueur ($).

Lors de la connexion de plusieurs clients simultanément, le serveur envoyait les

informations du nouveau client au client 1 alors que le nouveau client bloquait le port TCP en essayant d'envoyer de nouvelles informations au serveur. Pour éviter ce problème, nous avons décidé que le serveur enverrait les informations concernant tous les autres joueurs seulement quand ceux-ci auraient tous envoyés leurs informations personnelles.

6. Les parties privées et publiques

Nous avons décidé dès la conception qu’il n’y aurait pas de serveur dédié au jeu mais que les clients qui souhaitent créer une partie hébergent eux même le serveur. Il existe donc un serveur par partie. De plus, nous voulions que les joueurs aient le choix de jouer avec des serveurs connus ou pas. Pour cela, nous avons mis en place des parties privées et des parties publiques.

La configuration des parties consiste en la création d’un serveur (adresse IP, port TCP,

port UDP). En ce qui concerne une partie privée, les clients doivent connaître l’adresse IP et les ports du serveur pour y accéder.

La partie publique permet à des joueurs d’accéder à des parties rendues publiques par le

serveur. Les informations de connexion n’ont pas besoin d’être connues par le joueur. Le joueur peut choisir une partie dans une liste qui contient toutes les parties publiques en cours. Pour ce dernier type de partie, nous avons choisi d’utiliser une base de données contenant le nom des parties publiques non lancées. Si une partie est lancée, elle est supprimée de la base. Nous utilisons PostgreSQL pour la gestion de la base de données et nous utilisons le serveur sqletud.univ-mlv.fr de la faculté.

7. Quelques idées non implémentées dans cette version

Lors de la conception, nous avons eu d’autres idées qui paraissaient intéressantes, mais pas de première priorité. Nous les avons donc mises de côté pour un développement futur du jeu.

Foxracer IMAC 3

- 37 -

1. Le chat

Un chat très simple (où la discussion serait globale) trouverait bien sa place aux moments d’attente du jeu. Il serait donc accessible avant le lancement de la partie, pour le serveur et les clients déjà connectés, et à la fin de la partie, lorsque les joueurs sont arrivés, afin qu’ils comblent l’attente des joueurs plus lents et qu’ils puissent décider de la suite de leur jeu (nouvelle partie, ou juste se dire au revoir).

2. Le serveur d’échange de modèles

Il s’agirait d’un site Internet / base de données où les joueurs de FoxRacer pourraient partager leurs créations (voitures, circuits, thèmes de bruitage…). L’idée était de permettre un accès au site directement depuis l’interface de FoxRacer, pour télécharger et utiliser à la volée ces nouvelles données. Des tests ont été réalisés avec succès sur l’utilisation du protocole http pour envoyer et télécharger des fichiers sur un serveur (avec un petit script php qui réceptionne les fichiers). Cependant, le temps nous a manqué pour intégrer tout ceci.

3. Le transfert de serveur

Lorsque le serveur veut se déconnecter, les clients ont peut-être envie de continuer à jouer ensemble. C’est ainsi que nous est venue l’idée du transfert de serveur : le serveur « sortant » transmet aux clients l’IP du nouveau serveur. La plupart des informations sont déjà présentes chez tous les clients. Une simple reconnexion des clients au nouveau serveur permet alors de continuer la partie.

Foxracer IMAC 3

- 38 -

Partie D : Véhicules

Foxracer IMAC 3

- 39 -

I. Conception Générale

- vert : relatif aux force - rouge : relatif aux parties de la voiture - jaune : relatif au chargement de données

Couleurs tempérées en fonction de leur importance.

Foxracer IMAC 3

- 40 -

2. Conception d'un véhicule 1. Réglages possibles

Un véhicule se compose d'éléments visibles et invisibles mais pourtant déterminant pour la physique. On a séparé le véhicule en 3 éléments principaux visibles : la carrosserie, les roues avants et les roues arrières. Auquel se rajoute un moteur, 4 suspensions, les pneus, et les freins.

La configuration de ces éléments se fait via un éditeur au début de la partie. En effet

l'éditeur propose un panel de choix pour chacun de ces éléments : une liste de carrosserie disponible, une liste de roues avant et arrière associées à cette carrosserie, une liste de moteur plus ou moins puissants, le type de suspension : souple, normal ou dure, le type de pneu : tendre, normal ou dur et le type de freins : freins simples, puissants, assistés.

L'ensemble de ces choix disponibles est chargé en mémoire (fichier XML) dans une

instance de classe CarBD par un CarEditor au début du jeu. Ce Car Editor va lui-même générer un véhicule correspondant aux identifiants de carrosseries, roues etc. demandées par l’utilisateur. 2. Fonctionnement interne (XML)

Le fichier XML pour l'éditeur permet donc de configurer les paramètres des différents éléments disponibles.

Foxracer IMAC 3

- 41 -

Les paramètres de la carrosserie du véhicule sont son identifiant (pour le réseau), son nom, le fichier md3 associé, la texture, l'ombre, le type de particules émises par les pots d'échappement, la distance entre les roues avant et arrière et leur écartement, ainsi que d'autres variables d'ajustement pour l'affichage comme l'échelle, la hauteur de la carrosserie etc. Puis en ce qui concerne la physique du véhicule, les paramètres sont le poids, la surface, le coefficient d'aérodynamisme, la distance entre les roues avant et arrière avec la carrosserie sans calcul de force (hauteur des suspensions).

Les roues ont un identifiant (pour le réseau), un fichier md3, une texture, un type (roue

avant ou arrière), un poids et une variable d'ajustement de l'échelle de la roue. Un moteur a pour paramètre son identifiant (pour le réseau), sa catégorie, sa cylindrée en

centimètre cube, son régime maximum et minimum, son couple et son poids. Les types de freins, pneus et suspensions sont directement accessibles par des entiers dans

les classes associées.

3. Avantages et inconvénients

L'avantage d'avoir conçu un véhicule en plusieurs parties donne une liberté au joueur dans la création de son véhicule. C'est pour cela qu'on peut se permette de parler d'éditeur de véhicule. Le joueur peut ainsi paramétrer son véhicule et pourra se rendre compte des conséquences sur la physique de la voiture.

De plus le fait d'avoir une liste de roues avant et arrières disponibles pour chaque

carrosserie permet de varier le visuel et offre la possibilité pour plus tard de faire un système d'achat ou de bonus offerts quand on avance dans le jeu. Il pourrait être possible par exemple, si l’on finit premier aux deux premières courses, de débloquer de nouvelles roues avant, de nouvelles roues arrière, ou même de nouvelles carrosseries et de nouveaux moteurs.

Un autre avantage réside tout simplement dans le choix du XML. Cela nous permet l'ajout

de nouveaux éléments facilement et dynamise l'éditeur. Une des limites de cette conception réside dans le fait que pour le moment nous ne

différencions pas les quatre roues. Et que il peut il y avoir redondance des carrosseries disponibles dans le XML quand il n'y a que la couleur de la texture qui change. Et comme les roues sont associées aux carrosseries, il peut donc il y a voir une redondance des roues dans le XML aussi.

Foxracer IMAC 3

- 42 -

3. Gestion des événements

La gestion des événements pour les véhicules est indépendante pour chaque instance. Elle se fait par l'intermédiaire de variable d'état sur les touches utilisables pour le déplacement.

Nous avons 5 types d'événements recevables simultanément : avancer, freiner, tourner à

gauche, tourner à droite et sauter. Lorsque la touche associée à l'événement est pressée, nous mettons à jour les états.

Nous recevons donc les états des touches par le monde via la fonction. ManageCarEvent(dt) appelé tous les dt secondes qui applique des traitements sur le véhicule en fonction des états. Par exemple lorsque avancer est à true, on augmente la jauge simulant la pédale d'accélération ou lorsque freiner est à true et que avancer est à false, on diminue la pédale d'accélération pour simuler la décélération et on augmente la jauge simulant la pédale de frein.

Les avantages de cette manière de gérer les événements liés aux véhicules sont que nous

sommes indépendant des événements SDL. Les événements simultanées sont pris en compte (tourner et accélérer). Enfin avoir une gestion par véhicule est très pratique pour le jeu en réseau.

4. Dynamique du véhicule

1. Simulation de la gravité

La gravité du monde a un impact sur les véhicules. Elle est gérée par la classe CarWeight. Il a donc fallut la simuler grâce aux lois de Newton : P=mG. La force du poids exercée par le véhicule est calculée en fonction de sa masse (somme des masses de roues, moteur, et carrosseries). G la gravité du monde, fixé à 9.8 pour rester dans les conditions terrestres. P devient donc une force dirigée vers le bas dans le repère du monde.

Seulement l'effet de gravité d'un véhicule n'a d'intérêt que si on modélise une réaction de

Sol. En effet sans réaction brute du sol, la voiture s'enfoncerait. On additionne donc au Poids une force de valeur équivalente à celui-ci mais de direction orthogonale au sol (suivant le

Touner à droite

Tourner à gauche

Freiner

Sauter

Foxracer IMAC 3

- 43 -

vecteur Up du repère de la voiture). Cette force ne sera appliquée que

lorsque la voiture est en contact avec le sol.

De cette façon, on simule la gravité

exercée sur le véhicule. En l'air la voiture retombe sur le sol. On ressent la force du poids dans son déplacement et enfin selon le degré de la pente la voiture a plus ou moins du mal à monter. Ou au contraire elle peut descendre plus vite.

2. Poussée du véhicule

a. Accélération

La voiture accélère lorsque le joueur appuie sur la flèche du haut. A cet instant, la force de poussée du moteur est prise en compte dans la somme des forces appliquées au véhicule. Cette force orientée dans la même direction que le véhicule permet à celui-ci d’avancer.

Cependant, l’accélération doit se faire de manière progressive. Pour cela, nous utilisons

donc un coefficient variant en fonction des événements reçus entre 0.0 et 1.0 qui sera appliqué à la force de poussée du véhicule (fait varier le régime moteur). On définit ensuite une durée pour atteindre le coefficient maximal, i.e. 5 secondes. Plus la flèche du haut est longtemps enfoncée, plus le coefficient va augmenter jusqu’à atteindre sa valeur maximale 1.0 au bout de 5 secondes. Cette augmentation est donc proportionnelle au temps écoulé.

Lorsque le coefficient est à 1.0, l’accélération est constante (on considère que les autres

forces appliquées ne changent pas), la vitesse continue d’augmenter mais cette fois-ci de façon linéaire. Afin d’éviter d’obtenir des vitesses beaucoup trop rapides, une vitesse maximale est définie pour chaque véhicule.

b. Décélération

La voiture décélère lorsque le joueur n’appuie plus sur la flèche du haut. On reprend le même coefficient que précédemment mais cette fois-ci dans le but de réduire l’accélération. Plus le joueur relâche longtemps la flèche du haut, plus le coefficient va diminuer jusqu’à atteindre sa valeur minimale 0.0 au bout de x secondes. Comme précédemment, cette diminution est donc proportionnelle au temps écoulé.

Foxracer IMAC 3

- 44 -

Lorsque le coefficient est à 0.0, l’accélération est nulle suivant la direction de la voiture, la vitesse est donc constante.

Pour réduire la vitesse, jusqu’à atteindre une vitesse nulle, nous avons alors appliqué les forces de frottement qui sont orientées à l’inverse de la direction de la voiture. Ces forces vont donc nous donner une accélération négative suivant la direction du véhicule. Cette accélération négative va alors réduire petit à petit la vitesse du véhicule. Plus la vitesse est faible, plus les forces de frottements sont faibles. Par conséquent, la vitesse et ces forces vont continuer de diminuer jusqu’à obtenir l’arrêt du véhicule.

Dans un souci de réalisme, le moteur des véhicules possède des éléments caractéristiques d’un vrai moteur :

Le couple moteur La cylindrée Le régime du moteur (en court, minimal, et maximal) Un poids

La poussée du moteur (force de traction ou de propulsion) est une force dont le calcul est

basé sur le couple du moteur et le nombre de tours par minute. La poussée du moteur possède forcement une direction, qui est la même que celle du véhicule. C’est ainsi qu’après avoir appliqué la formule suivante :

3inute´pur´NbTourMcoupleMote=sseeforceDePou *StateMotor

On multiplie toutes les composantes du vecteur direction du véhicule par le résultat

précédent pour obtenir le vecteur « force de poussée ». De ce fait, deux caractéristiques du moteur jouent principalement dans le calcul de la

force de poussée : le régime moteur et le couple. Pour chaque moteur, le couple est constant. Cependant plus on appuie longtemps sur la touche d’avancée, et plus le régime moteur augmente. La décélération est simplement simulée par l'abaissement du régime lorsque l’on relâche cette touche.

Par conséquent, la force maximale d'un moteur est dépendante du régime maximum qu'il

peut supporter et de son couple. L'accélération dite « de poussée » est donc linéaire : le régime augmente relativement au temps d'appui de la touche d’avancée. Enfin, le dernier paramètre qui joue dans le calcul de la poussée est StateMotor qui représente l'état du moteur et varie de 1 à 0.

Pour plus de réalisme et pour avoir une accélération « de poussée » non linéaire, nous

aurions pu, au lieu d'avoir un couple constant pour chaque moteur, créer une fonction par moteur conditionnant le couple moteur en fonction du régime. En effet, en général, le couple d'un moteur est plus fort à bas régime qu'à haut régime, surtout pour les diesels. 3. Freinage et marche arrière

La voiture freine lorsque le joueur appuie sur la flèche du bas. Lorsque la voiture est à

Foxracer IMAC 3

- 45 -

l’arrêt, si le joueur appuie ou continue d’appuyer sur la flèche du bas, la voiture fait une marche arrière.

Tant que la flèche du bas n’est pas enfoncée, le coefficient de freinage vaut 0.0, cette force est donc nulle.

Dès que la flèche du bas est maintenue enfoncée, le coefficient de freinage augmente

proportionnellement au temps écoulé jusqu’à atteindre sa valeur maximale 1.0 au bout de x secondes. La force de freinage augmente donc également jusqu’à atteindre sa valeur maximale. L’accélération va donc se réduire beaucoup plus rapidement qu’avec seulement les forces de frottement et devenir négative, la vitesse va donc diminuer jusqu’à être nulle.

Si la flèche du bas continue d’être maintenue enfoncée, la force de freinage va donc

continuer à exercer une force dans le sens inverse de la direction de la voiture. L’accélération va rester négative et la vitesse va continuer de diminuer et donc devenir négative, ce qui va permettre une marche arrière.

Si l’on relâche la flèche du bas, le coefficient de freinage est remis à 0.0. La voiture subit

alors une accélération ou une décélération suivant l’état de la flèche du haut. Si l’on appuie sur la flèche du bas alors que le véhicule était à l’arrêt, la force de freinage

est de nouveau appliquée progressivement donnant une accélération négative qui donnera à son tour une vitesse négative qui permettra une marche arrière.

Physiquement, la force de freinage est représentée sous la forme d’un vecteur dont la

direction est inverse à la direction du véhicule (donc de la force de poussée). On multiplie chaque composante du vecteur direction par le coefficient de freinage que l’on obtient grâce à la formule :

coeffFreinage= coeffFreinActuel ´ freinageMax *stateBrakes

Avec coeffFreinActuel, le coefficient de freinage de la voiture à un instant t, variant de 0 à 1, et qui augmente si on garde la touche frein appuyée comme nous l’avons expliqué précédemment. freinageMax est le coefficient maximal de freinage de la voiture calculé en fonction du type de freins sélectionné. Enfin, stateBrakes est le dernier paramètre dans le calcul de la force de freinage. Il représente l'état des freins et varie de 0 à 1.

On notera aussi que l'on se sert de la force de freinage comme marche arrière du

véhicule. En effet, la direction du freinage est inverse au vecteur Dir du véhicule. Donc une fois que la poussée est nulle et que le freinage est non nul, la voiture recule.

Foxracer IMAC 3

- 46 -

4. Le contrôle du volant

Pour ce jeu de voiture, il nous a fallu faire déplacer et plus précisément tourner notre voiture. On peut considérer les tournants de la voiture (virages) sous deux angles différents :

La physique Le visuel

a. La Physique

Pour faire déplacer notre voiture, on lui applique plusieurs forces. Celles-ci permettent

à notre voiture de posséder une accélération, une vitesse, et donc une position. Pour faire tourner notre voiture, on applique tout simplement une force latérale à celle-ci s’ajoutant aux moments des forces. Ainsi on obtient une rotation de la carrosserie. Nous avons décidé d’utiliser une jauge pour simuler le volant de la voiture. Cette jauge est contrôlée par le joueur à travers les touches clavier La jauge du volant La jauge de direction qui simule le volant de la voiture est comprise entre -1 et 1.

-1 roues tournées vers la gauche 0 roues droites 1 roues tournées vers la droite Le joueur commande la voiture grâce aux quatre flèches directionnelles du clavier.

Lorsque celui-ci appuie sur les flèches de gauche ou droite il modifie donc la jauge du volant de la voiture. Application de la force

Grâce à la jauge du volant, on peut donc appliquer une force différente à notre voiture.

Si la jauge est négative, on tourne à gauche, on applique une force de la droite vers la gauche.

Si la jauge est neutre, on avance droit, on

n’applique pas de force.

Foxracer IMAC 3

- 47 -

Si la jauge est positive, on tourne à

droite, on applique une force de la gauche vers la droite.

Plus la jauge est grande (proche de -1 si on tourne à gauche et proche de 1 si on tourne à

droite) plus la force appliquée est grande.

On tourne doucement vers la droite : Jauge = 0.2

On tourne complètement vers la droite : Jauge = 1.0

Problèmes du système

La marche arrière : Lorsque la voiture est en marche arrière, les commandes du volant sont inversées, nous avons donc ajouté une condition pour savoir si la voiture est en marche avant ou arrière afin d’appliquer nos forces différemment selon le cas.

Les sauts : Lorsque la voiture saute une bosse, si l’on appuie toujours sur les flèches de gauche ou de droite, notre voiture « tourne en l’air » ce qui n’est pas du tout réaliste. Pour pallier a ce problème, nos avons codé une fonction isOnTheFloor() qui nous permet de détecter si notre voiture touche ou non le sol. À partir de là nous pouvons donc inhiber notre force lorsque la voiture est en l’air.

b. Le Visuel

En ce qui concerne le visuel, même si nous avions tous décidé de donner un aspect

cartoon à notre jeu, nous avons souhaité que notre voiture paraisse réaliste. Au début nous avons réfléchi sur le virage d’une voiture réelle. En effet pour tourner à gauche par exemple, il faut tourner le volant vers la gauche puis le redresser pour revenir droit. Nous sommes donc partis dans cette optique. De plus, afin d’augmenter le réalisme, nous avons décidé de faire rouler les roues afin de monter l’avancement de la voiture.

Foxracer IMAC 3

- 48 -

L’orientation des roues

Pour que le rendu visuel soit réaliste, nous avons donc orienté nos roues en fonction du volant. Nous avons effectué des rotations sur nos roues afin que celles-ci correspondent à la jauge du volant.

Lorsque l’on tourne à gauche les deux roues pivotent vers la gauche.

Lorsque l’on ne tourne pas, les deux roues restent parallèles à la carrosserie.

Lorsque l’on tourne à droite, les deux roues pivotent vers la droite.

La rotation des roues

Nous avons choisi de faire pivoter les roues autour de leur centre afin de donner

l’impression que celles-ci roulent sur le sol.

Lorsque la voiture est en marche avant, les roues tournent dans le sens horaire autour de leur centre.

Lorsque la voiture est en marche arrière, les roues tournent dans le sens anti-horaire autour de leur centre.

Foxracer IMAC 3

- 49 -

Problèmes du système

Lorsque que nous avons testé la jouabilité du volant, nous nous sommes rendu compte qu’il était désagréable de devoir, une fois avoir tourné à gauche, être obligés de tourner vers la droite pour remettre la voiture droite, car les roues ne revenaient pas droite automatiquement. Nous avons donc choisi de remettre celles-ci progressivement droite lorsque le joueur n’appuie plus sur une des de flèche droite ou gauche. Ceci permet de rendre le jeu beaucoup plus jouable. 5. Simulation des suspensions

Afin de simuler le mouvement des roues par rapport à la carrosserie et au relief, nous avons choisi de simuler l'effet de suspension des véhicules. Chaque roue a donc sa suspension associé et relié a un point stratégique de la carrosserie.

Une suspension est caractérisée par la distance entre la roue et le point de la carrosserie

associé. Puis par la direction de la force exercé sur la carrosserie (suivant le vecteur Up du véhicule).

Le calcul de la force est donc : F= (pointCarrosserie- PointRoue)* coefSuspension

A chaque mise à jour de la position du véhicule, on place chaque roue en fonction de la

hauteur du relief sous la roue (fonction getZ sur le Ground). On remet à jour chaque suspension en recalculant la distance entre l'extrémité de la suspension rattachée à la carrosserie et l'extrémité de la suspension rattachée à la roue. (L’étirement de la suspension) .On re-calcul la force de la suspension sur le point de la carrosserie puis on ajoute cette force de norme l'étirement de la suspension fois un coefficient de dureté de la suspension aux moments calculés. On aura une rotation de ce point de la carrosserie.

Une fois ce traitement effectué les quatre roues suivent bien le relief et la carrosserie subit

une rotation autour du vecteur Dir et du vecteur Right du repère du véhicule. (Le repère du

Foxracer IMAC 3

- 50 -

véhicule est mis à jour). Cette technique nous permet facilement d'avoir les quatre roues toujours sur le sol, d'avoir

une carrosserie qui suit la pente du sol et de simuler le déplacement des roues par rapport à la carrosserie pour donner un effet de suspension plus ou moins réactives au relief. Plus le coefficient de dureté de la suspension est faible et moins la carrosserie est réactive aux déplacement des roues par rapport au relief.

Par contre, nous n'avons pas modélisé l'amortissement dans ce système. C’est pour cela

que parfois lorsque qu'il y a une forte variation de relief trop rapide, la voiture met du temps à se stabiliser et tangue assez longuement.

6. Tenue de route Classe : CarFriction

Le calcul de cette force dépend : Du coefficient de frottement de l’air Du coefficient de frottement du sol Du coefficient d’adhérence des roues du véhicule (pour un pneu neuf) De l’état d’usure du pneu De la surface du véhicule De la vitesse du véhicule De la direction du véhicule

Pour calculer cette force, on distingue deux cas :

o la voiture est dans les airs (rebond)

On applique le coefficient de frottement de l’air à la vitesse inversée du véhicule en

fonction de sa surface. Ainsi, pour une même vitesse et un même coefficient de frottement de l’air, un véhicule plus gros subira une force de frottement plus grande.

o la voiture est en contact avec le sol

On calcule le vrai coefficient d’adhérence du pneu en fonction de son coefficient

d’adhérence lorsqu’il est neuf et en fonction de son état d’usure. Plus le pneu est usé, plus il est lisse, moins il adhère au sol.

On applique ensuite la somme de coefficients (air + sol + pneu) à la vitesse inversée du

véhicule en fonction de sa surface. La force est ensuite multipliée par un autre coefficient, dépendant de l’angle formé par le vecteur direction du véhicule et son vecteur vitesse. Ainsi, les frottements seront plus importants si le véhicule se déplace latéralement.

(A cet instant, la force est dirigée dans le sens inverse de la vitesse. On la réoriente donc de façon à ce qu’elle soit dans le sens inverse de la direction de la voiture en effectuant une rotation selon l’angle formé par le vecteur vitesse et le vecteur direction.)

Foxracer IMAC 3

- 51 -

7. Saut du véhicule

Nous avons décidé afin de rendre le jeu plus attractif de donner la possibilité au joueur de faire sauter sa voiture. Dans certain circuit, des boites Bonus ont été placées sur la route, pour les prendre il faudra préparer son saut afin d’attraper ces boites qui seront en l’air.

Pour mettre en place ce saut, nous nous sommes inspiré de la fonction de réaction du sol.

Cette fonction permet à notre voiture de se poser sur le sol et donc s’oppose au poids. A partir de la, nous avons modifié cette fonction pour faire de celle-ci un saut. Nous avons donc ajouté un coefficient qui permet d’augmenter la réaction du sol et ainsi

faire décoller la voiture. Ce coefficient est augmenté lorsque le joueur reste appuie sur la touche « espace » du clavier qui permet de faire sauter notre voiture.

Voiture avec la réaction du sol

Voiture avec la réaction du saut

8. Acceleration, vitesse, position (Olivier) 9. Collisions véhicules

a. Collision Véhicule/décor Réaction du véhicule Le rebond : A chaque fois que la voiture entre en collision avec un objet fixe de l'environnement, elle rebondit. Le rebondissement de la voiture dépend principalement de la vitesse à laquelle elle entre en collision avec l'objet. Tout d'abord, nous avons crée les boites englobantes de la voiture. Ensuite, on détecte s'il y a intersection entre les boites englobantes de la voiture et celles de l'objet. S'il y a une intersection alors la voiture et l'objet sont en collision et par conséquent la voiture rebondit.

Foxracer IMAC 3

- 52 -

Pour le calcul du rebond, nous avons simplement inversé la vitesse et annulé la poussé de

la voiture. Mais cela ne suffisait pas car la voiture repartait très loin. Nous avons donc augmenté le coefficient de frottement afin que la voiture freine plus rapidement lors d'une collision.

Après plusieurs tests, nous avons également constaté que la voiture restait parfois bloquée

dans l'objet du décor. Pour éviter ce cas, la voiture reprenait systématiquement la position qu'elle avait avant d'entrer en collision à chaque fois qu'elle détectait une collision. Si nous continuons d'avancer alors qu'il y a collision, la voiture continue de rebondir. Si nous arrêtons d'accélérer lors de la collision, la voiture rebondit une fois et s'immobilise. Problèmes rencontrés : Nous avons essayé de calculer le rebond en annulant la somme des forces et d'appliquer une force proportionnelle à la vitesse inverse. Mais cette méthode provoquait des résultats non souhaités :

Parfois la voiture se bloquait dans l'objet

Si on arrivait à très grande vitesse, la voiture traversait l'objet

Gestion des dégâts

En fonction de la partie qui a touché un élément du décor. Nous avons voulu altérer l'état de la voiture : le moteur, la direction, l’adhérence, les freins et l'aérodynamique de la voiture. Pour ce faire nous avons donc quatre parties sensibles du véhicule représenté par des boites placés stratégiquement à l'avant (boite 1), à l'arrière (boite 2) et sur les cotés du véhicule (boite 3 et 4 de gauche à droite). Et lorsqu'il y a collision, l'environnement nous envoi la boite touché.

Afin de pouvoir contrôler l'état des dégradations affligés nous avons mis en place une

variable d'état du moteur, des pneus et des freins allant de 1 (100%) à 0 (0%). qui vont directement diminuer les effets des forces généré par ces éléments (par exemple la force de poussée* 0.62). Pour contrôler l'état de l'aérodynamique de la voiture, nous dégradons tout simplement le coefficient d'aérodynamique de la carrosserie en l'augmentant. (En effet plus il est élevé plus la résistance à l'air de la voiture est forte dans le calcul de la friction de l'air).

Pour le calcul des dommages on fait donc un traitement en appelant une fonction

calculDamage qui prend en paramètre l'identifiant de la boite touché. On calcul enduite un coefficients de dommage qui augmente en fonction de la vitesse de collision. Si on touche à l'avant du véhicule (Moteur),

On soustrait à l'état du moteur le coefficient de dommage et on met à jour l'état du moteur dans le calcul de la force de poussée.

On soustrait à l'état des freins le coefficient de dommage et on met à jour l'état des freins dans le calcul de la force de freinage.

On ajoute au coefficient d'aérodynamique le coefficient de dommage et on met à jour l'aérodynamique de la voiture dans le calcul de la friction de l'air.

Foxracer IMAC 3

- 53 -

Si on touche à l'arrière du véhicule,



Si on touche le coté gauche ou à droite du véhicule,

On soustrait à l'état des pneus des roues avants et arrières le coefficient de dommage et on met à jour l'état des pneus dans le calcul des frottements au sol.



Enfin on élève le coefficients de damage de la direction (de 0 à 1 pour la gauche et de 0 à

-1 pour la droite) pour que la voiture ai toujours tendance à tourner à droite si on a tapé à droite ou à gauche si on a tapé à gauche. (Concrètement une force colinéaire au vecteur Right du véhicule s'ajoute aux moments pour faire une rotation autour du vecteur Up du véhicule de gauche à droite ou de droite à gauche).

Avantages et inconvénients

Grâce à notre système de zones sensibles selon 4 boîtes avec des parties dégradables via des coefficients d'état. On a facilement une dégradation de la physique de la voiture en

Foxracer IMAC 3

- 54 -

fonction des zones touchées. Par exemple en dégradant les pneus. La voiture tient moins bien la route, En dégradant les freins on freine de moins en moins bien. En dégradant le moteur. La voiture avance de moins en moins vite. En dégradant la direction, il est de plus en plus difficile de contrôler la direction et le joueur doit compenser. En dégradant l'aérodynamique, la voiture va moins vite. De façon générale, plus on touche des éléments du décor et moins la voiture est contrôlable. De plus, avec ce système de variable d'état, on pourrais afficher facilement dans le HUD l'état d'usure de l'élément de la voiture (par exemple en passage du vert au rouge de la couleur du moteur, des freins ou des pneus).

On aurait pu améliorer le système de dommage sur la voiture en ayant un calcul de

coefficient de dommage spécifique à chaque élément altéré. (Par ex pour le moteur et pour les freins).On aurait pu dégrader aussi les suspensions, la position des roues par rapport à la carrosserie. Ou même altérer le rendu visuel des carrosseries ou des roues en bougeant des vertex ou en ayant à disposition des modèles MD3 altérés avec leurs textures associées. (En ayant par exemple une discrétisation plus fine d'une carrosserie : capot, aileron, ailes etc.)

b. Collision entre Véhicules

Nous distinguons la collision avec les objets du décor et celle avec les voitures puisque les conséquences ne sont pas les mêmes sur la voiture. Comme pour la collision avec les objets du décor, nous appliquons à la voiture la position qu'elle avait avant d'entrer en collision.

Ensuite nous ajoutons à sa vitesse la vitesse de la voiture intersectée (Vb).

Etant donné que chaque voiture à son propre repère, nous obtenons ceci dans le repère de

la voiture A.

Foxracer IMAC 3

- 55 -

Nous avons donc dû appliquer au vecteur vitesse Vb une rotation de l'angle (dir_a,dir_b)

avant de l’ajouter à la vitesse afin de le replacer dans la bonne direction.

Pour appliquer la rotation au vecteur vitesse, nous multiplions le vecteur vitesse Vb par la matrice de transformation suivante :

La somme des vecteurs Va et r(Vb) va ainsi perturber la trajectoire du véhicule A : plus le vecteur r(Vb) sera grand par rapport à Va, plus la trajectoire du véhicule A sera altérée donnant ainsi l’impression qu’il est poussé par le véhicule B.

A l’heure actuelle, il nous est difficile de tester correctement ce raisonnement et de le

corriger ou de l’améliorer étant donné que la détection des collisions rencontre encore quelques problèmes.

8. Affichage du Véhicule 1. Style graphique

Foxracer IMAC 3

- 56 -

a. Choix du style

Le style graphique choisi pour le jeu en concertation avec chacun des groupes est un style de type « Cartoon ». Ce style doit donc se ressentir dans le design des véhicules.

Pour cela, nous avons choisi de modéliser des voitures de dessin animé. Ainsi, le cartoon

est bien présent, et cela permet de plus aux joueurs de retrouver des voitures qu’ils apprécient peut-être déjà.

Nous avions au début envisagé plusieurs possibilités de formes de véhicules en lien avec

le thème du cartoon et notamment celle de véhicules ayant l’apparence d’objets du quotidien sur roues. Nous avons finalement préféré nous arrêter sur les voitures de dessin animé car nous implémentons un modèle physique de voiture le plus proche possible de la réalité, et celui-ci sera mieux ressenti par le joueur s’il se trouve au volant d’un véhicule ressemblant à une vraie voiture, avec quatre roues et une carrosserie.

Quatre modèles de voitures ont été créés. Ils possèdent chacun un gabarit et des formes

différentes, afin de faire varier dans le jeu les paramètres physiques des véhicules, tels que le poids ou l’aérodynamisme.

Les modèles choisis viennent de dessins animés de types différents. Nous avons modélisé

la voiture de Oui-Oui, ainsi que Boumbo, qui viennent d’un univers enfantin. Les deux autres modèles viennent de dessins animés amusants, ce sont le van du dessin animé Scoobidou, et le draster de Fous du Volant. Chacun des véhicules est disponible en plusieurs couleurs. Ainsi, avec seulement quatre modèles, nous pouvons obtenons de nombreux véhicules différents.

b. Rendus

La Mystery Machine, inspirée du dessin animé Scooby-Doo possède six textures différentes.

Foxracer IMAC 3

- 57 -

Il y a deux modèles Oui-Oui : le classique, et le Jamaïcain.

Le modèle Boumbo se décline en trois couleurs de carrosserie différentes et trois couleurs de roues

Foxracer IMAC 3

- 58 -

Le Dragster a six décors différents, et quatre décors de roue

Foxracer IMAC 3

- 59 -

2. Modélisation et exports

a. Formats envisagés

Plusieurs formats d’exportation ont été envisagés : le MD3, le MD5, et le format Wavefront Object (Obj).

Nous avons voulu prévoir la possibilité d’améliorer le jeu ultérieurement en rendant les

déformations du véhicule visibles après un choc. Pour cela, nous avons choisi le format MD3, qui permet de stocker des informations sous forme d’images clefs. Nous pourrions ainsi créer plusieurs keyframes, correspondant aux animations des déformations possibles du véhicule.

Le format MD5, lui, ne possède pas d’images-clefs, mais permet une animation du modèle

par son squelette. Les déformations seraient possibles de cette façon-là, mais beaucoup plus difficiles à mettre en œuvre.

Quant au format Obj, il ne gère pas les animations, et ne permettrait donc pas de déformer

les véhicules.

b. Création et exportation des MD3

La carrosserie et les roues des véhicules doivent être séparées, car elles seront gérées séparément dans le jeu. Ce sont donc des MD3 différents. La réalisation de ces modèles et leurs exports ont été exécutés avec quatre logiciels différents.

Photoshop CS

Les textures ont été créées dans le logiciel Photoshop CS. Celui-ci nous a permis de

réaliser des images au format « tga », gérant la transparence et pouvant être utilisé sur les MD3. Afin de faciliter l’export, on associe une unique texture à chaque MD3, soit : une pour la carrosserie et une pour l’ensemble des roues. La première est au format 512x512 et la seconde, nécessitant moins de détails et appliquée à un objet plus petit, au format 256x256. Ces dimensions ont été réajustées afin d’assurer un compromis entre souci du détail et temps de chargement.

De nouvelles textures sont faites pour chaque déclinaison de couleur mais elles ne

changent pas de nom par rapport à la texture initiale. Seul le nom du répertoire contenant change. Ainsi, le MD3, lui, reste le même.

On peut voir un exemple de l’utilité de la

transparence sur le volant de Boumbo, qui est constitué d’un disque plein.

En effet, modéliser le volant aurait nécessité la réalisation d’une forme contenant beaucoup de facettes alors que le disque, lui, en contient très peu.

Foxracer IMAC 3

- 60 -

3DSMax 5

La modélisation, le mapping des textures et les exports de base ont été effectués grâce au logiciel 3DSMax 5.

Interface du logiciel 3DS Max 5

La contrainte majeure de la modélisation concerne le nombre de polygones acceptés par modèle. Nous avons en effet besoin de modèles qui soient « low-poly » (limités en polygones), afin de conserver un temps de chargement du jeu rapide, ainsi que des mouvements fluides lors de la partie.

Ainsi, nos modèles ne dépassent pas les 1000 polygones. Les voitures, qui ont des formes

assez simples, ont du être choisies en conséquences. Un modèle avec une forme trop compliquée n’aurait pu donner un résultat satisfaisant en low-poly.

Le mapping des textures, c’est-à-dire la façon dont les textures sont placées sur les

modèles, s’effectue avec le modificateur « développer uvw » de 3DS Max. Il permet de plaquer les différentes faces de l’objet sur la texture, tel un patron.

Foxracer IMAC 3

- 61 -

Mapping du Dragster. On peut reconnaître par exemple le demi-cercle du modèle qui

entoure les yeux du dragster

Avant l’export des modèles en MD3, certaines étapes de préparation sont nécessaires. Les éléments doivent être renommés avec un nom significatif. Les carrosseries ont un nom qui commence par « car », et les roues par « roue ». Les textures doivent aussi être renommées, du nom du fichier TGA qu’elles utilisent, afin que la texture soit bien appliquée au MD3. Un plan nommé « tag_floor » doit être créé au niveau du sol, point de repère au moment de l’affichage des MD3.

L’export en format MD3 n’étant pas présent de base dans la version 5 de 3DSMax, nous

avons utilisé le plugin nommé ExportMD3.dle, téléchargeable gratuitement par exemple sur le site www.quake3bits.com, expliquant comment personnaliser Quake III. (http://www.quake3bits.com/htm/tutorials/gmax_to_max_converting.htm).

Foxracer IMAC 3

- 62 -

Milkshape 3D 1.7

L’export MD3 réalisé sous 3DS est souvent imparfait. Il faut donc vérifier que l’on obtient bien ce que l’on veut. On peut visualiser le MD3 texturé à l’aide de Milkshape 3D. (Version 1.7.10), shareware téléchargeable sur http://chumbalum.swissquake.ch/ Ce logiciel nous a été utile pour régler différents paramètres :

Le repère du modèle (carrosserie ou roue) a pu être précisément placé en fonction des tests d’affichages, effectués via la modification du XML dans Foxracer, qui faisaient souvent apparaître un décalage entre les roues et la carrosserie ou un décentrage du modèle.

La texture n’était pas toujours correctement prise en compte lors de l’export. On pouvait ici spécifier son chemin et la lier au modèle.

Certains modèles apparaissaient comme trop petits. Le logiciel permet de faire des « scale » dans la dimension (x,y,z) voulue afin de le mettre à l’échelle.

Milkhape permet de visualiser le MD3 généré sous 3DS

afin de corriger les problèmes d’export

L’export en MD3 via ce logiciel se fait en trois étapes : Il faut tout d’abord générer un fichier de contrôle d’extension « .qc » En éditant celui-ci, on corrige les éventuelles erreurs qu’il contient (chemin et nom

de la texture, du MD3, mise à zéro du nombre d’images clés) Une fois ce fichier sauvé, on peut exporter en MD3.

Foxracer IMAC 3

- 63 -

N’Pherno’s MD3Compiler

Ce logiciel nous a permis en dernier lieu de visualiser le MD3 exporté sous Milkshape, de vérifier le nom de la texture, et surtout de recalculer les normales, qui sont souvent fausses sous 3DS. Une fois ses normales « reconstruites » on exporte le MD3 final en remplacement du précédent MD3

NPherno’s MD3 Compiler permet d’effectuer les vérifications finales

et de redresser les normales des faces du modèle

c. Problèmes rencontrés et contraintes L’export de modèles MD3 est une opération délicate qui demande de nombreux

ajustements sous plusieurs logiciels. Une fois la démarche précédemment expliquée acquise, les exports ne demandaient plus autant de temps, mais la phase de tests et de correction des différents bugs mis à jour par l’affichage dans le jeu a été longue, d’autant plus qu’il a fallu se familiariser avec le fonctionnement de logiciels que l’on ne connaissait pas.

En effet, pour que l’export se passe bien, il faut satisfaire à de nombreuses contraintes

comme par exemple le fait que le nom du MD3 corresponde à celui de la texture, le renommage de la texture dans les matériaux, le plaquage d’une unique texture par modèle, le placement du repère tag_floor…

Enfin, un de nos problèmes fut que les textures de certains de nos modèles étaient trop

lourdes. De ce fait, les machines dotées de cartes graphiques relativement peu puissantes n’affichaient pas la texture ou abandonnaient le lancement du programme.

Foxracer IMAC 3

- 64 -

3. Chargement et affichage des MD3

Nous disposons de seize véhicules de quatre natures différentes : dragster (5 modèles), boumbo (3 modèles), oui-oui (2 modèles) et mystery machine (6 modèles).

Le fichier xml parsé pour charger les véhicules contient 2 modèles md3 par véhicule, un pour la carrosserie et un autre pour les roues. Ce fichier indique au loaderMD3 les modèles à charger, avec leur texture, et permet d'indiquer le placement des roues. Pour cela, nous disposons de plusieurs variables permettant, notamment, de régler la hauteur entre les roues et le repère de la voiture, la distance entre les roues avants et les roues arrières, et l'écartement entre les deux roues avant ainsi qu'entre les deux roues arrières. Pour que ces réglages soient fiables, il est nécessaire que chaque modèle md3 soit centré en 0.

Ce fichier nous permet également de placer les boites englobantes des véhicules. Nous pouvons préciser la position en x, en y et en z, effectuer des translations, des rotations et des homothéties sur les trois axes. Quatre boites permettent d'englober correctement l'intégralité d'un véhicule, une à l'avant, une à l'arrière et une de chaque côté.

Les boites et les roues ont été positionnées à la main, les valeurs sont enregistrées en dur dans le fichier xml. A chaque véhicule correspond un dossier contenant les modèles md3 et leur texture.

Foxracer IMAC 3

- 65 -

4. Les ombres

Dans le jeu Foxracer, nous avons implémenté des ombres factices sous les objets et sous la voiture. Il est important de souligner qu’un vrai calcul des ombres aurait énormément ralenti le jeu. C’est pourquoi l’affichage des ombres s’effectue sous la forme d’une astuce :

L’application charge une texture TGA transparente (32 bytes). À chaque réaffichage de la voiture, la texture se positionne au centre de gravité du

véhicule. Cette texture s’adapte au maillage du sol grâce à une fonction qui retourne pour chaque position du plan XY, la hauteur du terrain.

Une façon d’optimiser l’affichage des ombres aurait été de les orienter en fonction du

vecteur direction du véhicule. En effet, les ombres ne possèdent qu’une position, et s’adaptent au terrain : elles ne s’adaptent pas encore à la voiture, ce qui les oblige à être rondes.

Une simple rotation des ombres, corrélée avec la rotation de la voiture (angle de direction), aurait suffit à palier à ce problème. Cependant, l’orientation des ombres s’initialisant au lancement du programme, il était assez compliqué de remédier au problème.

6. Les bonus et malus

Pour plus d'interaction entre le joueur et l'application, nous avons ajouté deux bonus et deux malus. Il s'agit d'objets intégrés à la scène. Quand l'utilisateur en traverse, une action temporaire se produit.

Les bonus disponibles sont les suivants :

Le bonus accélération augmente la vitesse maximale du véhicule et diminue le temps nécessaire pour l'atteindre. Le véhicule va plus vite. Ce bonus dure dix secondes.

Le bonus « véhicule fantôme » permet au joueur, pendant dix secondes, de traverser le véhicule de ses adversaires, pour cela, on désactive toutes collisions entre ce véhicule et les autres. Ce bonus n’a pas pu être implémenté à temps..

Les malus proposés sont les suivants :

Le malus ralentissement fait l'inverse du bonus accélération : diminution de la vitesse maximale du véhicule et augmentation du temps nécessaire pour l'atteindre. Le véhicule va donc moins vite, pendant dix secondes.

Le malus dérapage diminue l'adhérence des roues au sol en diminuant le coefficient de friction des roues. Cela rend le pilotage plus difficile, plus particulièrement dans les virages. Ceci dure 5 secondes. Le véhicule dérape comme sur de la glace ou sur une tâche d'huile.

Les objets bonus et malus sont des objets de la scène ayant, comme les autres, des boites

englobantes qui nous permettent de détecter une collision. Lors d'une collision, on récupère le type de l'objet, s'il s'agit d'un bonus ou d'un malus, on décide de pouvoir le traverser (pas de rebond) et de déclencher l'action adaptée. Ces options ont nécessité la création d'un timer en relation avec le timer général de l'application afin de gérer la durée de chaque bonus ou malus.

Foxracer IMAC 3

- 66 -

7. Résultats et bilan 1. Les chefs : Un chef qui fait les rapports de réunions Un chef technique Un chef physique 2. Répartition du travail Un sou groupe s’occupant des calculs physiques et de la dynamique de la voiture (contrôle et interactions avec le décor). Six personnes Un autre sou groupe s’occupant de la modélisation de modèles de véhicules, de l’éditeur de véhicule et du son. 5 personnes. Afin que tout le monde s’investisse et comprenne le fonctionnement de la partie véhicule dans sa globalité. Nous avons fait en sorte de varier le plus possible les taches pour chacun d’un prototype par rapport au précédent. 3. Interactions avec les autres groupes Mis à part les réunions globales, nous avons dû communiquer entre nous. Pour les taches reliées entre l’IHM/Reseau, l’environnement et les véhicules, nous avons fait en sorte que chacun sache avec quelles personnes des autres groupes il a fallu communiquer. Par exemple : Editeur XML (module véhicule) et interface d’édition du véhicule (IHM) ou encore détection de collision (environnement) et réaction et gestion de l’état du véhicule (module véhicule). 4. Les réunions Avant chaque prototype, petit rapport d’avancement de chacun sur son travail en interne. Apres chaque réunion générale, réunion pour tenir au courant des décisions prises et répartition du travail.

Foxracer IMAC 3

- 67 -

Partie E : Environnement

Foxracer IMAC 3

- 68 -

I. Présentation

La partie Environnement du projet Foxracer gère l’univers 3D dans lequel évoluent les joueurs.

Rappelons rapidement les différentes fonctionnalités exigées et que nous avons créées :

Gestion des collisions entre les véhicules et les éléments du décor

Stockage des niveaux (cartes) du jeu, ainsi que des différents types de terrain et objets disponibles

Optimisation de leur affichage à l’écran

Il a été décidé d’ajouter au projet un système de particules afin d’améliorer la qualité

graphique du jeu. Enfin, un éditeur de cartes a été implémenté afin de permettre au joueur de créer ses propres environnements 3D et d’y positionner les différents objets.

La gestion de l’environnement sonore est évoquée au chapitre « Partie commune », plus

loin dans le rapport.

2. Création des cartes et modèles

Foxracer permet aux joueurs de pouvoir jouer sur différentes cartes. Les circuits sont générés automatiquement par le programme en 3D à partir de plusieurs fichiers :

1 fichier XML comportant toutes les informations décrivant le monde : noms des

textures et des objets utilisées, leurs positions, etc…

4 fichiers « .tga » : une texture heightmap, une texture d’affichage à plaquer sur le terrain, une texture pour le ciel, et une texture pour donner les informations de type de terrain.

De multiples modèles intégrés dans les cartes, comme par exemple : la vache, les

checkpoints, les bonus, les champignons, etc… Ces modèles sont composés d’un fichier md3, d’une texture et d’un fichier XML contenant les informations pour la génération des boîtes englobante.

Nous allons maintenant détailler chacun de ces composants :

Foxracer IMAC 3

- 69 -

1. XML du monde Le Xml du monde à une forme équivalente à celle-ci : <?xml version="1.0" ?> <foxracer> <brief mapTitle="Campagne (test)"

mapDescription="Paysages bucoliques, boue, ornieres mapPreview="data/worlds/campagne.jpg"/>

<sky tex="sky03.tga" sunX="1.0" sunY="-0.5" sunZ="0.3" sunR="3.0" sunG="3.0" sunB="3.0" ico="icon.gif" /> <fog near="10" far="200" cR="1.0" cG="1.0" cB="1.0" /> <ground ico="icon.gif"> <mdl src="height_ferme.tga" tex="tex_ferme2.tga" typ="typ_ferme_256.tga"/> <size X="1000.0" Y="1000.0" Z="15.0" /> </ground> <objects> <object type="default" name="vache" ico=""> <infos>Meuuuuhhh!!</infos> <onCreate qR="0" qG="0" qB="0" qRegen="0" /> <onHit qR="0" qG="0" qB="0" /> <onDraw> <mdl src="cow.md3" tex="cow.tga" selfIllumination="false" /> <position drop="true" X="240.0" Y="438.0" Z="-0.5" /> <angle X="0" Y="0" Z="0" /> <size X="1.5" Y="1.5" Z="1.5" /> <fx gd="true" gdWidth="30" gdHeight="30" gdLevel="0.1"

gdDepthX="10" gdDepthY="10" gdTex="ombre3.tga" bb="false"/> </onDraw> </object> </objects> </foxracer>

La première balise, la balise « brief », est utilisée pour décrire la carte, cette description est ensuite utilisée dans l’interface lorsque l’on choisit la carte sur laquelle aura lieu la course. Elle permet aussi de connaître le nom de l’image de présentation de la carte qui sera aussi utilisée dans l’interface.

La balise « sky » permet de donner les informations de position et de luminosité du soleil

ainsi que la texture du ciel. La balise « fog » permet de paramétrer le brouillard : la couleur, et sa zone d’influence. La balise « ground » contient les informations relatives au terrain : le noms des 3 textures décrites dans le point suivant, ainsi que les dimensions du terrains. Enfin, la balise « objects » contient tous les objets présents dans la scène et inscrit les uns à la suite des autres. Chaque objet est délimité par une balise « object » et contient des informations comme son type, son nom, sa position, sa taille, sa texture, les effets qui lui sont appliquées…

Foxracer IMAC 3

- 70 -

2. Les textures

Les textures peuvent être créées à la main sous Photoshop ou sous Gimp ou à l’aide de l’éditeur de carte qui s’occupe de les générer. Ces textures se trouvent dans le dossier « ground » du dossier « data ».

Les 4 textures utilisées pour chaque carte sont :

La texture de heightmap

Heightmap de la carte « ferme »

La heighmap est idéalement d’une taille de

1024*1024 pixels. En fonction de la valeur du niveau de gris des pixels de cette image, le terrain sera plus ou moins élevé à cet endroit là. Sachant qu’un pixel noir équivaux au point le plus bas et un pixel blanc au point le plus haut.

La texture du sol

La texture du sol de la carte « ferme »

La texture du sol est la texture qui est appliquée sur

le terrain. Elle doit être d’une taille relativement importante pour qu’il y ait suffisamment de détails. C’est pour cela qu’elle doit faire idéalement 1024*1024 pixels.

La texture du ciel

La texture du ciel de la carte « ferme »

La texture du ciel est la texture qui est appliquée à l’intérieur d’une sphère entourant le terrain. Elle doit aussi être d’une taille relativement importante pour

Foxracer IMAC 3

- 71 -

qu’il y ait suffisamment de détails. C’est pour cela qu’elle doit faire idéalement 1024*1024 pixels.

La carte des types

La texture des types de la carte « ferme »

Elle n’a pas besoin d’être très détaillée. On se contente donc d’une taille de 256*256 pixels. Cette texture permet, à partir de la position du véhicule, de savoir sur quel type de terrain il se trouve. Effectivement, les différentes couleurs des pixels de cette texture correspondent à différents types de terrains. Par exemple, un pixel ayant pour valeur RVB : (150,150,150) sera associé au type « goudron » et un pixel ayant pour valeur (0,255,0) sera associé au type « herbe ».

3. Les modèles

Les modèles sont générés dans le programme à partir de 2 fichiers : un fichier « md3 » pour tout ce qui est informations 3D et une texture en « .tga ». Tous les objets sont regroupés dans le dossier « objets » qui se trouve dans le dossier « data ».

Les modèles doivent être créés à la main sous 3D Studio Max par exemple. Ils doivent

être modélisés en low poly (pas plus de 500 faces !) et être texturé correctement pour qu’une seule texture leur soit appliquée. La modélisation requiert donc des règles relativement strictes de modélisation.

Une fois l’objet modélisé sous 3D Studio Max, il faut le convertir en .3DS puis l’importer

dans un logiciel appelé MilkShake. Une fois sous MilkShake, il faut remettre le modèle droit, le redimensionner et le déplacer à l’origine. Il faut ensuite générer un fichier « .qc » qui contient les informations nécessaire à la génération du « .md3 ». Le .qc contient notamment le nom de la texture et le nombre d’image clef (une dans notre cas). Une fois ce fichier générer, on peut enfin procéder à la conversion en « .md3 ».

Il faut ensuite importer le md3 dans un petit logiciel qui s’appelle MD3Compile et qui

permet de recalculer les normales qui ont été quelque peu malmenée par ces multiples conversions. On a enfin un objet prêt à être intégré dans notre monde.

9. Chargement et affichage du monde

Le petit moteur 3D de FoxRacer a été développé dans un souci d'optimisation, pour

Foxracer IMAC 3

- 72 -

permettre au jeu de tourner correctement sur des configurations restreintes. Les classes créées se veulent facilement réutilisables dans d'autres projets, c'est pourquoi elles sont indépendantes de la SDL. La plus importante d'entre elle (la classe World) gère tout les objets présents dans le jeu. Elle contient des paramètres de rendu (brouillard, lumière, effet cartoon, camera...) et permet le contrôle du véhicule du joueur. 1. Économie des transferts vers la carte graphique

Afin de limiter l'envoi de données vers la carte graphique, seuls les objets présents dans le champ de vision de la caméra sont affichés. L'angle formé par le vecteur direction de la caméra et le vecteur reliant la caméra à l'objet doit être inférieur à l'angle d'ouverture. Cette optimisation accélère considérablement l'affichage, car elle diminue l'utilisation du CPU (moins d'accès aux données), les transferts vers la carte graphique, et les calculs de la carte (moins de vertex à traiter).

L'affichage est aussi optimisé par l'emploi de vertex arrays (pour les sommets, normales et

coordonnées de textures) et non une suite de primitive OpenGL, plus lente. Les vertex arrays compilés auraient pu être utilisés, puisque la géométrie des objets est fixe, mais l'extension nécessaire n'est pas présente sur toutes les cartes. La solution des listes d'affichage OpenGL a aussi été abandonnée, car elle diminuait le frame rate au lieu de l'augmenter (en stockant les données géométriques dans la mémoire de la carte graphique).

Le terrain est l'objet du décor le plus complexe, en terme de nombre de polygones. Pour

obtenir une qualité convenable, il doit avoir une définition minimum de 512x512 points, soit plus de 500 000 triangles. Il a donc fallu le diviser en sous-blocs de tailles plus réduites. La première étape consiste à charger le terrain dans sa totalité (avec mise à l'échelle souhaitée et calcul des normales des points). L'étape suivante est la construction des sous-blocs par simple recopie des données du grand terrain, qui est ensuite effacé. Pour l'affichage, chaque sous-bloc subit le même test que les autres objets, ainsi seule la partie visible du terrain est envoyée à la carte.

Exemple avec un angle de limitation trop faible

Foxracer IMAC 3

- 73 -

2. Économie de la mémoire

Les modèles md3 et les textures ne sont chargés qu'une seule fois en mémoire. Chaque ressource est référencée par son chemin sur le disque. Ainsi un même modèle peut-être être dupliqué dans le monde avec des textures différentes, ou une même texture appliquée à plusieurs modèles sans duplication en mémoire, car les objets affichés n'utilisent en fait que des pointeurs vers les ressources chargées. Ils possèdent également leur propre matrice de transformation, utilisée par la carte graphique, ce qui autorise différents paramètres d'échelle, de rotation et de position pour un même modèle.

Le même champignon avec des tailles et orientations différentes

3. Effet cartoon Pour obtenir un effet cartoon, les objets sont dessinés en trois passes :

La première passe affiche le contour des faces arrière, sous forme de lignes noires

épaisses. La deuxième passe affiche les faces avant avec la texture de l'objet, l'éclairage

Foxracer IMAC 3

- 74 -

désactivé. La troisième réaffiche les faces avants avec la texture de shading semi-

transparence, (blending additif) et sans éclairage. Cette texture est à une seule dimension et ses coordonnées sont recalculées pour chaque sommet en fonction de l'angle entre la normale au sommet et la direction de la lumière.

Cette technique de cel-shading demande donc légèrement plus de temps processeur qu'un affichage classique, mais ne ralentit pas le jeu. Elle présente également l'avantage d'être portable puisqu'elle n'utilise pas d'extension OpenGL comme le multitexturing, qui aurait permis de fusionner les passes 2 et 3, ou les shaders.

Foxracer IMAC 3

- 75 -

Comparaison avec et sans effet cartoon 4. Les objets physiques

Une classe d'objet physique a été créée dans le but de servir à la fois au contrôle des véhicules et aux objets de décor. Dans la version actuelle de FoxRacer, seuls les véhicules utilisent ses fonctionnalités. Cette classe relativement simple est une ébauche de moteur physique. Elle permet d'appliquer une force au centre de gravité d'un objet, générant alors une simple translation, où en n'importe quel point, générant alors un moment de force et donc une rotation.

Pour appliquer une rotation à l'objet selon n'importe quel axe, la méthode des quaternions

a été adoptée. Ils permettent en effet de convertir une rotation, donnée par son axe et son angle, en matrice de rotation. La matrice résultante de l'objet est alors obtenue en multipliant sa propre matrice (correspondant à une base orthonormée directe), par la matrice de rotation.

Application d'une force à un objet

10. La gestion des types de terrains

Le jeu, permet, au véhicule de réagir en fonction du type du terrain sur lequel il se trouve. Par exemple, si le véhicule roule sur de la glace ou du sable, l’adhérence au sol sera énormément réduite.

Les différents types de terrains sont stockés dans un fichier XML qui est interprété par le jeu. L’utilisation d’un fichier XML extérieur au jeu, permet à l’utilisateur de l’éditeur de carte de créer ses propres types de terrains. Par exemple, le joueur peut créer un type « boue »

Foxracer IMAC 3

- 76 -

qui sera ajouté au XML. Ce type sera ensuite reconnu par le jeu puisqu’il puisera les informations relatives aux types dans ce fichier XML. Il est organisé ainsi :

<?xml version="1.0" ?> <types> <type name="bitume" tex="bitume.jpg" r="150" g="150" b="150" adherence="1.0"> <type name="herbe" tex="herbe.jpg" r="0" g="255" b="0" adherence="0.8"> </type> </types>

La première balise indique la version de xml utilisée.

La balise « types » indique la nature du document XML.

Les balises « type » contiennent les informations relatives à chaque types : son nom, le nom de la texture associée pour l’éditeur, sa couleur RVB associée dans la carte des types, et son cœfficient d’adhérence du véhicule sur ce type de terrain.

Une fois que le programme à analyser les informations du fichiers XML et qu’il a stocké

les données de la texture des types (voir la partie « création du monde et des modèles »), il peut, à partir de la position du véhicule, lui dire sur quel type de terrain il se trouve. Il regarde pour cela à quelle couleur RVB d’un type, fait référence le pixel se trouvant sur la carte des types à la position du véhicule.

5. La détection des collisions

Afin d'éviter de traverser des objets ou d'autres véhicules de la scène, la détection des

collisions est nécessaire. Or, les algorithmes de collision sont généralement à forte complexité et, par conséquent, ils peuvent ralentir énormément le jeu. Il nous fallait donc trouver une méthode efficace, simple et rapide. 1. Le principe

Pour ce faire, nous avons utilisé le théorème de l'axe séparateur. Mathématiquement, un axe est séparateur si un plan orthogonal à cet axe sépare deux polygones convexes. Son algorithme consiste à déterminer tous les axes séparateurs des deux formes dont on teste la collision potentielle. Ensuite, on teste chaque axe séparateur potentiel jusqu'à trouver un axe le long duquel les formes sont disjointes. S'il n'existe aucun axe séparateur, alors il y a collision.

Pour utiliser cette méthode, on a besoin de trouver les directions perpendiculaires aux

objets et de calculer le projeté de l'objet sur un axe.

Foxracer IMAC 3

- 77 -

Schéma du théorème des axes séparateurs 2D

Dans ce schéma, on remarque que, sur les axes orthogonaux, les projetés des objets se

chevauchent donc il y a peut être une collision entre ces deux objets. Cependant, en projetant les objets sur une droite parallèle à un côté de l'objet bleu, on remarque que les projetés sont distincts, il existe donc un axe séparateur perpendiculaire à cette droite démontrant l'absence de collision entre l'objet vert et l'objet bleu.

2. Les boîtes englobantes

On détecte la collision sur les boîtes des objets. Il nous était possible de choisir entre deux types de boîtes, les boîtes alignées sur leurs axes (AABB) et les boîtes orientées (OBB). Il nous a paru plus judicieux de choisir les OBB car elles nous permettaient de construire un squelette simple de l'objet.

Les boîtes sont créées à partir d'un fichier XML dont le nom correspond à celui du fichier md3 de l'objet. Chaque objet, en fonction de sa forme, peut donc avoir un nombre différent de boîtes. Par conséquent, il n'y a pas de positionnement automatique des boîtes. Pour chaque boîte, dans le fichier XML de l'objet, on indique ses dimensions, sa position et ses angles de rotation.

Les boîtes sont placées en position relative à l'objet. Or, pour l'algorithme des axes séparateurs, nous avons besoin de leur position relative au monde. À cause d'un problème de conception, les transformations subies par l'objet n'étaient pas appliquées aux boîtes. Nous avons donc modifié la conception du placement des objets afin de remédier à ce problème.

3. Son intégration dans le programme

Foxracer IMAC 3

- 78 -

Le choix d'utilisation de la méthode des axes séparateurs avec les boîtes OBB permet d'obtenir un résultat suffisamment fin pour ne pas faire d'autres tests de collision, notamment sur les facettes de l'objet.

La collision peut être détectée entre un véhicule et un autre, un véhicule et un objet de décor, ou un objet de décor avec un autre. Par exemple, dans le cas d'un test de collision entre les véhicules et les objets présents sur la scène, on teste, pour chaque véhicule et pour chaque objet du décor, la collision entre chaque boîte du véhicule et chaque boîte de l'objet de décor. Notre programme renvoie 0 s’il ne détecte pas de collision. Autrement, il renvoie l'identifiant de la boîte du véhicule qui est en collision avec un objet.

6. La gestion des checkpoints Quand un véhicule entre en collision avec un objet de la scène, on récupère le type de

l’objet du décor qui a été auparavant extrait du fichier xml. Si l’objet est du type « checkpoint », on appelle la fonction « getCheckpoint ».

Pour qu’un tour soit validé, le joueur doit passer par tous les checkpoints décimés tout au

long du circuit. Chaque fois que l’utilisateur passe par un checkpoint, on compare l’identifiant de cette balise (c) à celui du checkpoint précédent validé (n). Pour que le checkpoint courant soit validé son identifiant doit être égal à celui du checkpoint précédent validé plus un, c’est-à-dire n+1=c. Si cette équation n’est pas vérifiée alors on envoie un message d’erreur au joueur lui indiquant qu’il a oublié un checkpoint si n+1>c ou qu’il a déjà validé ce checkpoint si n+1<c.

La ligne d’arrivée est un checkpoint particulier qui arrête la course. La validation de ce

checkpoint stoppe le chronomètre et annonce son temps au joueur.

11. Le système de particule Le système de particules est utilisé dans le projet pour simuler la fumée sortant du pot

d’échappement. Pour cela, on utilise des billboards (afin que les textures utilisées pour les particules soient

toujours orientées vers la caméra) qui possèdent une position, un instant de naissance ainsi qu’une durée de vie. Aucun mouvement n’est calculé. Les particules se contentent d’apparaître à une position quand vient leur instant de naissance (par rapport au temps du véhicule) et de disparaître selon leur temps de vie. Leur position est calculée par rapport à celle du véhicule. À la mort de chaque particule, leur position est recalculée et leur temps de naissance initialisée par rapport à la position et au temps du véhicule. De cette façon, aucun calcul de mouvement n’est nécessaire, les particules étant créées selon la trajectoire de la voiture.

Le nombre de particules apparaissant est compris entre 0 et 10 (limité volontairement pour éviter de surcharger et de ralentir le jeu). Le nombre de particule affiché est lié à la façon dont l’utilisateur pousse le moteur du véhicule à un instant t (plus le moteur est mis a contribution, plus il y aura de particules affichées). Cela permet de ne pas afficher de particules de fumée

Foxracer IMAC 3

- 79 -

de pot d’échappement à l’arrêt et d’augmenter l’immersion en ajoutant un lien entre les actions du joueur et ce qu’il voit à l’écran.

Ce système de particules a aussi été pensé afin d’afficher les brins d’herbes, grains de poussière, neige au niveau des roues lors d’un virage (la position étant celles des roues et non plus celle de la voiture, les textures étant différentes). De même qu’un système similaire aux particules de fumée a été pensé pour effectuer le tracé des roues sur le sol (à l’aide d’une texture semi transparente, chargé de noircir le sol aux passages des roues), la différence réside dans le fait que ce n’est pas un billboard qui serait utilisé pour affiché la texture mais un objet ombre (c'est-à-dire un plan facettisé qui épouse la pente du terrain à un instant t). La technique aurait été de récupérer la position des 2 roues arrières, de placer une ombre-trace en dessous de chaque roue à un instant t et de ne renouveler la position de l’ombre-trace qu’au bout d’un certain temps (le temps de vie de la particule de trace sur le sol). En utilisant un certain nombre d’ombre-traces dont la vie et la mort se chevauchent, on aurait pu simuler un tracé sur le sol qui suit la trajectoire des roues, comme la fumée du pot d’échappement suit la trajectoire de la voiture. Bien sur, à l’instar des premières générations de jeux de courses 3D, on aurait vu un tracé segmenté (selon le nombre et la taille de particules trace utilisés). L’affichage de ce tracé ne devait se faire que lors de virage ou de freinage.

Mais par manque de temps, ces systèmes n’ont pas pu être finalisés et n’ont donc pas été intégrés au projet.

Les textures utilisées pour les particules constituant la fumée du pot d’échappement varient selon les véhicules (cette information est stockée dans le .xml des véhicules) tandis que celles qui étaient prévues pour afficher les effets du passage du véhicule sur le sol devait être fonction du type du terrain sur lequel le véhicule effectuait son virage (information est stockée dans le .xml des types de terrains).

12. L’éditeur de cartes

1. Conception

Le but de l’éditeur de cartes est de générer un environnement 3D et d’y placer des objets. Nous avons tout d’abord imaginé que l’utilisateur pourrait agir directement sur l’environnement 3D. Il aurait différents outils lui permettant de modeler un relief (création de bosses, extrusion, ...). Cependant, cette solution, bien qu’intuitive, nous a semblé trop difficile à mettre en œuvre.

Nous avons alors imaginé une nouvelle solution qui utiliserait la carte de hauteur

(heightmap) du terrain. Cette carte est composée de pixels de différents niveaux de gris, qui stockent l’information de relief du terrain. L’utilisateur pourrait créer la heightmap de son terrain en 2D grâce à différents outils, dont un pinceau disposant de différentes tailles. Puis, il « basculerait » en mode 3D pour afficher la vue en relief.

Cette solution a emporté l’adhésion du groupe : elle offre un réel confort à l’utilisateur, puisque la création du relief se fait avec une vue 2D simple de la carte et des outils basiques. 2. Interface QT

Foxracer IMAC 3

- 80 -

La mise en place de l'interface Qt s'est faite en trois phases. La première par le biais de QT designer nous a permis de créer un premier squelette de l'éditeur. Le système est basé sur des onglets ce qui permet une meilleure ergonomie. Il sépare en effet la vue 3D et le avue 2D d'un côté, la gestion du terrain, des textures et des objets de l'autre. Malheureusement si Qt designer est assez efficace pour placer les éléments, il ne permet pas de réaliser facilement des fenêtres graphiques OpenGL. Nous avons donc du reprendre un ancien code et l'adapter à nos besoins pour insérer des widgets. Une fois l'interface mise en place, nous avons pu y ajouter une touche graphique de manière à la rendre plus attractif. Nous avons donc réalisé des icônes en utilisant Photoshop. Ainsi chaque bouton prend une signification logique, compréhensible en un coup d'oeil. Afin d'être sûrs que tous soient compris, nous avons ajouté des infos bulle sur chaque élément. À ce moment là, nous avions donc une vision assez nette de l'aspect final de l'éditeur.

La seconde phase a été de connecter chaque bouton à une fonction. Cette étape fut assez

longue et fastidieuse, chaque type de bouton ayant un comportement particulier et un signal précis. Des comportements propres à Qt ont pu êtres utilisés pour réaliser des opérations qui autrement auraient été presque impossibles. Ainsi, nous récupérons les textures à utiliser grâce aux fenêtres d'explorations modales auxquelles nous avons ajouté des filtres afin d'obtenir une sélection de fichiers utilisables. Nous avons également voulu offrir à l'utilisateur un confort d'utilisation encore plus grand en lui facilitant le travail. Nous voulions par exemple que le choix des couleurs se fasse selon deux manières. En utilisant un colorpicker de QT qui nous renvoie une couleur, mais également en proposant de remplir directement le code hexadécimal de la couleur et un bouton refresh.

Ce premier squelette réalisé il a donc fallu donner à ces fonctions un code qui permettrait

de créer de nouvelles cartes pour FoxRacer. Pour cela il était nécessaire de faire très attention à la position de ces fonctions car en interagissant avec les widgets présents sur les onglets il

Foxracer IMAC 3

- 81 -

existait le risque de doubler les actions ou encore de tracer sur la mauvaise carte. Au final, chaque bouton de notre interface est utilisable et permet de paramétrer un comportement sur les cartes, que ce soit la vue 3D de visualisation, ou la vue 2D de dessin et de texture. 3. Fonctionnalités de l’interface

Onglet : Environnement Taille du pinceau

Tailles de pinceau prédéfinies (un champ permet de choisir une taille personnalisée). Quand aucun outil de nivelage n’est sélectionné, ce pinceau dessine un dégradé de noir qui se fond avec la teinte du terrain.

Nivelage du terrain

Augmentation du niveau du terrain

Creuser le terrain

Nivelage à une valeur moyenne

Génération de bruit

Tous les pixels dont la hauteur est supérieure au seuil fixé (dans le champ Seuil) sont ramenés à la valeur de ce seuil.

Génération d’un terrain aléatoire

Génération d’un terrain aléatoire qui prend en compte le terrain actuel

Remise à zéro du terrain au niveau du seuil choisi

Foxracer IMAC 3

- 82 -

Application d’un flou sur tout le terrain

Ambiance Eau Réglage du niveau de l’eau et de sa texture

Brouillard Réglage de la distance proche et lointaine du brouillard ainsi que de sa couleur

Soleil Réglage du sa position horizontale et de sa couleur

Ciel Réglage de sa texture Onglet : Terrain

Taille du pinceau

Tailles de pinceau prédéfinies (un champ permet de choisir une taille personnalisée)

Champ sélection du type de terrain Choix parmi une liste du type de terrain à peindre

Créateur de type de terrain Cette partie très explicite permet de définir tous les paramètres d’un terrain afin de créer son type de terrain personnalisé.

Onglet : Objets

Ajout d’un objet

Suppression d’un objet

4. Outils et filtres

a. Outils de modelage du terrain

Afin de laisser l’utilisateur contrôler la forme de son terrain d’une manière plus simple qu’un outil de dessin traditionnel, nous avons mis au point une série d’outils orientés vers le modelage de terrain.

Foxracer IMAC 3

- 83 -

5 outils de modelage de terrain

Chaque outil est représenté par une icône de couleur marron représentant le profil de

l’effet qui sera appliqué au terrain. De plus, chaque outil est influencé par la taille du pinceau et s’applique autour du curseur de la souris de l’utilisateur lors du clic dans la vue 2D de l’éditeur.

4 tailles par défaut et un réglage

En plus de la taille du pinceau, les outils utilisent parfois une puissance et un seuil. Nous avons donc au final 5 outils différents de modelage de terrain sous forme de « pinceaux » à la taille réglable :

1. Surélever : Surélève le terrain et crée une bosse plus ou moins haute selon la puissance 2. Creuser : Creuse le terrain et crée un trou plus ou moins profond selon la puissance 3. Aplanir : Crée rapidement un point praticable par un véhicule sur un relief bosselé 4. Bosseler : Surélève le terrain selon un bruit de Perlin 5. Couper : Coupe le terrain selon la valeur de seuil. Si cette valeur est positive alors, les

sommets du terrain seront coupé sinon les creux seront remplis.

Exemples des outils : Surélever, creuser, aplanir, couper

b. Filtres de modelage de relief

Modeler un terrain à la main n’est pas quelque chose de facile et de rapide. De plus obliger l’utilisateur à décider de chaque bosse, falaise et vallonnement du terrain sans aucun autre moyen que de les peindre à la main n’est pas une bonne solution pratique. Toujours dans un souci d’utilisation facilitée de l’éditeur, nous avons mis en place une série de filtres graphiques orientés vers le modelage de terrain.

Foxracer IMAC 3

- 84 -

4 filtres de modelage Le bruit de Perlin est une solution pratique et rapide permettant de générer un nombre

infini de terrain aléatoire. Cet algorithme calcule en fait plusieurs calques aléatoires de plus en plus précis afin de les associer pour donner l’image finale. La particularité de cet algorithme est qu’il est entièrement paramétrable selon 3 variables :

1. La fréquence du bruit de Perlin permet de contrôler le nombre de valeurs aléatoires sur la carte ce qui permet au final de générer plus ou moins de « monts ».

2. La persistance est une valeur permettant de régler la façon dont les différents calques de Perlin seront associés afin de rendre l’image finale.

3. Le nombre d’octaves indique le nombre de calques qui seront associés. Plus il y a de calques, plus la précision du terrain généré sera haute.

Afin de garder l’utilisation du filtre la plus facile possible, nous avons figé la persistance et le nombre d’octaves afin de laisser l’utilisateur décider uniquement de la fréquence. Au final Le résultat est toujours précis et réaliste.

Exemple de bruits de Perlin : A gauche bruit brut, à droite même bruit moyenné avec un

autre

Certains outils et certaines utilisations des différents outils mis à disposition dans l’éditeur peuvent faire apparaître des reliefs peu réalistes ou trop « discrétisés ». Pour palier à ce problème nous avons mis en place un filtre d’adoucissement réglable. Ce dernier applique un flou sur l’image d’altitude plus ou moins fort selon l’intensité indiquée dans l’interface.

c. Peinture du terrain

Une fois satisfait de la carte d’altitude, l’utilisateur aura sans aucun doute envie d’indiquer

Foxracer IMAC 3

- 85 -

les différents types de sol. Par défaut le type de sol est l’herbe. L’utilisateur devra donc définir les endroits qu’il souhaite praticable par les véhicules. Pour cela il changera simplement d’onglet et passera en mode édition de terrain.

Sélection du type de terrain dans la liste

Une fois en mode peinture de terrain et si la vue 2D est activée, l’utilisateur pourra sélectionner son type de terrain dans la liste puis peindre ce dernier directement sur le terrain. De la même manière que pour le modelage de terrain, il est possible de régler la taille du pinceau.

Lors d’un clic, l’utilisateur verra la texture du type de terrain, qu’il aura préalablement sélectionné, apparaître sous son pinceau mélangé à la texture précédemment présente sur le sol.

Mixage en temps réel de la texture du type de terrain

Afin de faciliter la peinture de sol en fonction de la forme du relief, nous avons pensé à

afficher les courbes de niveau du relief. Grâce à ces courbes, il est donc possible à l’utilisateur de se repérer rapidement dans la forme du relief sans pour autant perdre en visibilité.

Affichage des courbes de niveau d’un relief chaotique

Foxracer IMAC 3

- 86 -

Plus les courbes sont rouges, plus le niveau est bas et inversement, plus les courbes sont vertes, plus le niveau est haut. Il serait facilement envisageable de permettre à l’utilisateur d’afficher plus ou moins de courbes de niveaux qui sont actuellement définies à 3. 5. Affichage du terrain en tps réel

L’une des fonctionnalités de l’éditeur de terrain est de pouvoir visualiser en temps réel et en 3D ce que l’utilisateur dessine en vue de 2D. Nous avons comme point de départ la carte de hauteur chaque nuance de gris correspond à une hauteur. On interprète les données de la carte de hauteur en coordonnées réelles, on utilise pour cela une classe terrain qui regroupe un tableau de sommets du terrain, un tableaux de normales aux sommets et un tableau de coordonnées de textures. Le calcul de terrain est très gourmand en ressource pour éviter donc de faire les calculs trop souvent c’est-à-dire à chaque réaffichage de la fenêtre OpenGL, la mise à jour du terrain ne se fait que lorsqu’on est dans la vue 3D, à tout moment l’utilisateur peut modifier sa carte de hauteur dans la vue 2D et visualiser le résultat dans la vue 3D. Ainsi, l’utilisateur peut corriger sa carte s’il le désire.

Il en est de même pour la carte de texture, l’utilisateur pourra visualiser le terrain texturé en 3D à mesure qu’il dessine sa texture.

a. Déplacement de la caméra

La gestion du déplacement de la caméra a demandé le plus de temps. Les événements liés à la souris étaient initialement mal gérés : il était impossible de se déplacer correctement autour de la carte. En fait, des appels de fonctions se faisaient de manière contradictoire. À chaque clic, la caméra se remettait dans sa position initiale au lieu de mémoriser le déplacement qu’elle venait d’effectuer. Il a fallu créer de nouvelles variables de déplacement pour résoudre le problème.

b. Gestion de la lumière Une fois la caméra réglée, nous nous sommes rendus compte d’erreurs au niveau du

placement de la lumière. L’éclairage du terrain variait de manière très abrupte tandis que l’on se déplaçait dans la scène. Nous avons d’abord pensé qu’il s’agissait d’une erreur dans le calcul des normales du terrain. En réalité, cela était dû à un mauvais positionnement de la lumière, qui était trop près du terrain. Nous l’avons donc éloignée, en veillant à ce qu’elle éclaire le bon côté de la carte 3D.

c. Gestion de la texture d’eau Enfin, nous avons modifié l’affichage de la texture d’eau. Nous l’avons redimensionnée

afin qu’elle soit de la même taille que la carte 3D. Sa position initiale a été également modifiée afin qu’elle soit parallèle à la carte.

Foxracer IMAC 3

- 87 -

6. Ambiance soleil, mer, brouillard.

Créer des reliefs et des circuits est indispensable pour obtenir une carte jouable, mais pour lui donner plus de cachet il faut aussi jouer sur l'ambiance globale : la position du soleil et sa couleur pour un effet "sunshine", position de la mer et texture pour un effet "lagon" peuvent par exemple offrir une carte paradisiaque. Le brouillard est également important pour régler la visibilité et donc l'impression météo. Tous ces éléments sont bien entendu paramétrables dans FoxEditor.

Commençons tout d'abord par le soleil. Deux paramètres sont réglables, sa position au

zenith : un simple slider nous renvoie un entier correspondant à sa nouvelle position. Ensuite sa couleur. Celle-ci, de même que celle du brouillard peut s'obtenir de deux manières. Une pour les utilisateurs novices, qui choisissent dans la palette la couleur qu'ils souhaitent. On obtient alors une QColor composée de getR, getG, getB, qui permet de paramétrer en direct la nouvelle couleur. La seconde plutôt destinée aux graphistes qui préfèrent doser directement le code hexadécimal demande de remplir un champ de texte. Ce code est ensuite envoyé à une méthode qui le convertit en un tableau de float. Elle est faite de telle sorte que la casse n'est pas importante, dans le cas ou la couleur n'existe pas, les valeurs inexistantes sont remplacées par une valeur par défaut. La précision est réduite à deux dixièmes afin d'éviter des calculs inutiles. Ces réglages permettent donc de régler l'ambiance lumineuse de la scène.

La couleur du soleil ainsi que celle du brouillard sont paramétrables.

Le brouillard se règle selon le même principe, un choix de la couleur d'un côté et de l'autre

les réglages inhérents au brouillard OpenGl. Deux sliders permettent de paramétrer la composante Near du brouillard proche, ainsi que le paramètre Far. Ces deux valeurs sont ensuite injectées dans les fonctions du glFog. glFogf(GL_FOG_START, 0.1); glFogf(GL_FOG_END, 25);

Foxracer IMAC 3

- 88 -

Réglage des paramètres du brouillard.

Le résultat est visible immédiatement sur le vue 3D qui représente le terrain en heightmap.

Ces deux éléments réglés, nous obtenons l'atmosphère finale de notre nouvelle carte. Il reste encore à régler la composante hydraulique de la scène. Pour cela il convient de commencer par choisir la texture qui sera appliquée. L'utilisateur peut donc explorer ses dossiers à la recherche de sa texture qui sera immédiatement appliquée sur un plan. La position de ce plan et donc le niveau de l'eau se règle ensuite par un nouveau slider qui déplace le plan en temps réel sur la vue 3D.

Choix de la texture de l’eau et réglage du niveau

7. Positionnement des objets sur la carte

La possibilité pour l’utilisateur de créer lui-même ses circuits de course est un atout indéniable pour Foxracer. C’est pourquoi nous avons décidé de créer une interface permettant de générer un terrain 3D et d’y positionner différents objets.

Foxracer IMAC 3

- 89 -

a. Réglages possibles Qt Designer a permis de concevoir une interface claire et fonctionnelle pour l’utilisateur.

Listing des fonctionnalités disponibles : - Pinceau - Choix des textures - Vues 2D/3D - Sauvegarde du monde dans un fichier XML : cf partie b « Fonctionnement interne » (Captures de la fenêtre de rendu OpenGL)

Afin de permettre à l’utilisateur de placer lui-même les objets sur la carte, une méthode de picking a été implémentée. Lorsque celui-ci clique sur l’interface, le programme récupère la position de la souris dans la fenêtre (coordonnées X et Y).

Le cadre noir représente l’interface de l’éditeur. Le carré rouge représente le buffer de la carte. La croix verte symbolise le pixel où vient de cliquer l’utilisateur.

Nous effectuons ensuite une action (utilisation du pinceau, placement d’un objet, ...) sur le pixel de coordonnées (X, Y) de la carte. Par défaut, la carte est positionnée de manière à recouvrir parfaitement l’interface de l’éditeur. En effet, les deux éléments sont tous les deux de taille 512 x 512. Un problème se pose ensuite lorsque l’utilisateur décide de déplacer la carte.

Dans l’exemple ci-dessus, l’utilisateur a éloigné la carte de l’interface (augmentation de la distance rho). La carte apparaît plus petite dans la fenêtre.

L’utilisateur clique au même endroit qu’avant : le programme va enregistrer les

coordonnées (5,5) pour effectuer une action sur le pixel de coordonnées (5, 5) de la carte. Or, le pixel (5,5) de l’interface correspond maintenant à du vide. Le clic de l’utilisateur ne devrait donc lancer aucune action sur la carte. Il s‘agit donc de lier le repère de l’interface à celui de la carte.

Foxracer IMAC 3

- 90 -

Nous avons d’abord décidé de prendre en compte chaque déplacement de la carte (translation, rotation), puis calculer à chaque fois les nouvelles positions des quatre coins de la carte dans l’interface. Cette méthode s’est avérée trop fastidieuse. Nous avons alors fait appel à la méthode de picking implémentée lors du projet de deuxième année. Cette méthode utilise une série de classes liés à l’objet « Caméra », ainsi qu’à divers éléments géométriques (point3D, vecteur, rayon). L’intégration de ces classes n’a pas été facile car la version initiale de l’éditeur de cartes ne connaissait pas l’objet « Caméra ». 8. Exportation des cartes créées

a. Principe L’utilisateur peut à tout moment sauvegarder au format TGA la carte de texture ou la carte

de niveau qu’il vient de créer en cliquant sur « Exporter » dans le menu « Fichier ». En outre, en choisissant « Sauver » ou « Sauver sous », nous enregistrons tout son travail. Tout d’abord, nous enregistrons, au format TGA, la carte de niveau, la carte de texture et la carte de type de terrain. Nous créons le fichier XML du monde (décrit plus haut) qui réunit toutes les informations relatives à l’environnement du terrain.

La première fois que l’utilisateur enregistre son travail, il indique le nom qu’il souhaite donner à son environnement ainsi qu’une brève description. Ce nom sera donné aux trois cartes ainsi qu’aux fichiers XML. Si le nom donné est « Neptune », les fichiers créés seront les suivants :

- Neptune.xml pour le XML principal - Neptune_HeightMap.tga pour la carte de niveau - Neptune_TexMap.tga pour la carte de texture - Neptune_TypesMap.tga pour la carte de types de terrain

b. Création des XML

En ce qui concerne l’écriture des fichiers XML, QT met à notre disposition des fonctions

simples. Nous avons choisi la méthode d’écriture DOM qui permet une utilisation plus libre des données.

Lorsque l’utilisateur crée son terrain et qu’il renseigne par exemple la position du soleil ou la texture du ciel… nous sauvegardons en même temps ces données comme étant des informations à stocker dans les XML. Cependant ceux-ci sont générés uniquement quand on sélectionne « Sauver » ou « Sauver sous » dans le menu « Fichier ».

Les informations que l’utilisateur n’aura pas renseignées seront remplacées par des

valeurs par défaut dans le XML.

c. Créations des cartes

Chaque carte est enregistrée au format TGA selon les options qui lui sont spécifiques. Ainsi, la carte de niveau est enregistrée au format TGA non compressé niveaux de gris alors que les autres sont enregistrées au format non compressé couleurs.

Foxracer IMAC 3

- 91 -

Partie F : Partie commune

Foxracer IMAC 3

- 92 -

I. Son

Pour que le jeu soit complet et de façon à le personnaliser, nous avons décidé de créer notre propre bibliothèque de sons. Que ce soit les sons d’environnements, comme des ambiances champêtres, les sons propres aux voitures, comme le klaxon ou une exclamation, ou les musiques, les sons ont tous été enregistrés par nos soins. De plus, de façon à développer l’aspect comique du jeu, nous avons opté pour une solution amusante d’enregistrement : le tout à la bouche ! 1. Enregistrement et mixage

a. Enregistrement L’enregistrement a été réalisé à l’Université Marne la Vallée, bâtiment Charles Cros, dans

les studios d’enregistrement. Une quinzaine d’élèves IMAC se sont réunis pour fournir une bibliothèque riche et originale.

Les sons ont été enregistrés à l’aide d’une paire de micros statiques placés de façon à

reproduire une stéréo comparable à celle des oreilles humaines. Le logiciel Pro-Tools utilisé sous mac nous a permis d’obtenir un excellent résultat, très proche des sons originaux.

Le temps passé pour l’enregistrement a été d’une demi-journée. Il nous a manqué une

autre demi-journée pour pouvoir enregistrer les musiques du jeu, les studios étant très prisés, surtout en cette période de rendu de projets.

Les principales difficultés de l’enregistrement ont été de trouver un créneau permettant à

un grand nombre d’IMACiens d’être présents et de réussir à gérer une quinzaine de personnes réunies dans une petite pièce et ne sachant pas trop quoi dire aux micros !

b. Mixage

Le mixage a été réalisé sur des ordinateurs personnels, les studios étant plutôt réservés à l’enregistrement qui nécessite une bonne acoustique. Les sons ont été traités de façon à obtenir un rendu plus réaliste, surtout pour les ambiances qui ont nécessité l’ajout de réverbération et de compression. Les sons plus simples ont souvent été gardés tels quels, certains parfois pitcher de façon à rendre un effet cartoon amélioré.

La bibliothèque obtenu se divise en 3 grandes catégories : - Les sons hors jeu, qui comprennent les bruitages et musiques présents pendant la

navigation dans l’IHM. - Les bruitages des véhicules, qui sont propres à chaque véhicule suivant le modèle. - Les sons en jeu, qui regroupent les musiques de jeu, les ambiances sonores et les

bruitages tels que la foule en délire ou le feu tricolore. Le temps passé pour cette partie a été de deux demi-journées. Le travail ayant été bien fait

lors de l’enregistrement, cette phase a été assez simple et d’autant plus facilitée par Pro-Tools et un bon Mac Intel.

Foxracer IMAC 3

- 93 -

2. Intégration et gestion du son dans Foxracer

L’ajout du son dans Foxracer a pu se faire à l’aide de la librairie SDL_Mixer, permettant de charger, lire plusieurs formats de sons, du WAV au MP3. Ainsi, il a été décidé de charger des fichiers MP3 pour les sons d’ambiance, car plus légers, et d’utiliser le format WAV pour les bruits ponctuels.

La classe FoxSound est donc chargée de gérer le côté sonore du jeu. Elle comporte plusieurs fonctions permettant de contrôler la musique, son volume, mais aussi de jouer un son ponctuel. Une seule musique peut être jouée à la fois, de manière à ne pas surcharger l’écoute, tandis que plusieurs sons ponctuels peuvent être joués en même temps. Une série de sons ponctuels a déjà été implémentée dans le jeu, comme le son de bienvenue, le compte à rebours, le passage de checkpoint ou la victoire finale.

La banque de sons étant importante, et certains éléments du jeu n’ayant été finalisés que

très tard, tous les sons n’ont malheureusement pas été intégrés. Cependant, la classe FoxSound est faite de telle sorte que l’ajout d’un nouveau son ne nécessite, en général, que l’ajout d’une seule ligne de code.

2. Constantes de précompilation

Le fichier compilation.hpp est un fichier qui contient des constantes de précompilation (#define) qui sont à commenter ou décommenter, selon la plateforme et les conditions dans lesquelles le programme est compilé. A l'heure où le rapport est écrit, il y a 5 constantes dans ce fichier :

COMPILING_WITH_OFFICIAL_RTIMAGE définit si l'émulation de RTImage est effective ou non (cf. Emulation de RTImage).

PARAGUI_VERSION_1_1_8 définit quelle version de Paragui est utilisée.

USING_IMG_LOAD définit si, pour le chargement des images, on utilise

IMG_Load, ou bien un module de Foxracer qui charge des TGA, réalisé exprès pour le portage Windows.

PNG_PIXELS_IN_BVR_FORMAT définit si les images utilisées lors de la

création de textures sont dans l'ordre BGR ou RGB.

NO_SOUND définit si le son est utilisé. Pratique pour désactiver le son sur des ordinateurs sans carte son.

3. Émulation de RTImage

Malgré la présence de RTImage.cpp dans le programme final, RTImage n'est en réalité

Foxracer IMAC 3

- 94 -

pas utilisé. En effet, il a été jugé préférable de supprimer RTImage car : RTImage, utilisant par exemple X11, … n'était pas du tout portable. Moins un programme dépend de bibliothèques diverses et variées, plus il est

facile à maintenir/modifier. Or le programme utilisait déjà SDL_image /SDL/OpenGL pour charger des textures.

La solution était donc d'utiliser FoxDisplay à la place. Or reprogrammer un tas de code

dans le programme de chargement de l'environnement, etc …était long et laborieux. La solution utilisée est donc assez surprenante : on "émule" RTImage, en remplaçant le

code de RTImage par des appels à FoxDisplay. Seules les méthodes utilisées dans le programme ont été réécrites. Ca marche, et l'avantage est qu'on peut "switcher" de la compilation avec le "vrai" RTImage (qui a été gardé au cas où), et le "faux", juste en changeant une constante dans le programme (cf. les constantes de précompilation).

4. Support des manettes de jeu

Sur Windows et Mac OS X, ou sur tout système Linux possédant un driver, les manettes de jeu sont nativement reconnues par Foxracer. Les joysticks devraient l’être tout autant.

Aucun réglage de commandes n’est cependant proposé dans Foxracer. Toute manette Logitech ou Playstation devrait être reconnue et fonctionner sans problème. Les manettes d’autres marques n’ont pas été testées et certaines touches peuvent ne pas correspondre.

À l’aide de la manette, il est possible de se déplacer dans le jeu, d’accélérer, freiner,

sauter, changer de caméra et effectuer un zoom. Il est également possible de valider les choix dans les menus principaux.

Foxracer IMAC 3

- 95 -

Partie G : Bilan et conclusion

FOXRACER -...

Documents

Transcript of FOXRACER -...