COURSE DE VOITURE EN 2D

Transcription

1 Télécom SudParis Année scolaire 2008/2009 Projet Informatique 1 ère Année CSC 3502 COURSE DE VOITURE EN 2D BELKACEM Guillaume *LIMA Mathieu* PAGET Aurélie PATER Laure Enseignant responsable : LERICHE Sébastien, département informatique Version du 18 Mai 2009 Page 1 sur 30

2 Sommaire 1 Introduction.3 2 Cahier des charges Fonction du logiciel Performances requises pour la bonne exécution du logiciel Affichage Caractéristiques techniques Mémoire Processeur Système d exploitation Contraintes de réalisation Exigences de qualité requises Concernant la documentation Concernant la réalisation du projet Concernant le suivi du projet Développement Analyse du problème et spécification fonctionnelle Fonctionnalités du jeu Données manipulées Interface avec l utilisateur Conception préliminaire Définition des modules Plan des tests d intégration Conception détaillée Menu de choix Règles d animation et de mouvement Gestion des collisions Gestion des points et du temps Codage Description de la bibliothèque SDL Commentaires des codes Tests Vérification individuelle Tests d intégration globaux Intégration Interprétation des résultats Manuel utilisateur Pré requis Installation et lancement du jeu en 5 étapes Lancement du programme Instructions de jeu Conclusion 23 Page 2 sur 30

3 7. Bibliographie Annexes Annexe 1 : Gestion de projet Plan de charge Planning prévisionnel Suivi des activités Code source Site Web 30 Page 3 sur 30

4 1. Introduction Dans le cadre du projet CSC 3502 de l école TELECOM SudParis, nous devons réaliser un «projet informatique». Nous avons donc formé un groupe de 4 étudiants en faisant en sorte de choisir des personnes avec lesquelles nous sommes capables de travailler efficacement. Ensuite est venue la question du choix du projet. Nous avions une cinquantaine de projets proposés et nous avons choisi parmi ceux là le projet «Jeu de voiture en 2D» de Sébastien LERICHE. Et ce, pour plusieurs raisons :. Tout d abord, certains d entre nous ont l habitude ou on eu l habitude de jouer à des jeux vidéos ; il était donc intéressant, pour eux mais aussi pour les autres, de voir ce qui se cachait derrière cela. En effet, en tant que simple joueur, nous appuyons sur des touches ou jouons avec un joystick, mais nous ne connaissons rien à la réalité du jeu. Nous nous sommes donc dit qu il pouvait être intéressant de voir sur quoi se basaient ces jeux qui ont bercé notre enfance, ou plus!. De plus, ce projet a quelque chose de concret : nous savions que une fois le code commencé, si nous y passions le temps nécessaires, à la fin nous aurions une satisfaction concrète : un jeu auquel nous pourrions vraiment jouer.. Pour finir, ce projet nous permet de mettre en pratique tout ce que nous avons appris dans le module CSC 3002, c'est-à-dire en programmation en langage C tout en découvrant un nouvel outil qu est la bibliothèque Simple DirectMedia Layer (SDL). Ce projet complet nous permet également de travailler sur tous les aspects techniques d un programme informatique : analyse d un problème avec ses contraintes, conception puis implémentation d une solution, validation du résultat ; mais aussi sur tout ce qui est gestion d équipe et de planning. Page 4 sur 30

5 2. Cahier des charges 2.1 Fonction du logiciel Notre projet a pour but la réalisation d un jeu de voitures, pour 2 joueurs, en 2D. Toutes les commandes seront effectuées au clavier. 2.2 Performances requises pour la bonne exécution du logiciel L ordinateur sur lequel le jeu sera lancé devra posséder au minimum les caractéristiques suivantes : Affichage -Résolution de l écran -Couleurs d affichage -Vitesse de défilements des images 800x bits 25 images/s Caractéristiques techniques -Mode de saisie Clavier Mémoire -Type -Capacité RAM 512 Mo Processeur -Vitesse du processeur 1.5 GHz Système d exploitation -Plateforme -Système d exploitation PC Tous 2.3 Contraintes de réalisation Le jeu devra être portable, c est-à-dire qu il peut être utilisé quelque soit le système d exploitation installé. Le programme sera codé en langage C. Page 5 sur 30

6 Les graphismes proviendront pour une part de la librairie SDL et pour l autre de données trouvées sur internet. 2.4 Exigences de qualité requises Concernant la documentation Rédaction d un plan de charge et d un planning prévisionnel Le plan de charge contient un tableau avec la liste des tâches à effectuer et pour chacune d entre elles l indication de la personne responsable et de la charge estimée. Le planning quant à lui contient la liste des tâches nécessaires à la réalisation du projet avec indication des participants aux activités et des durées, avec date de début et de fin de chacune d entre elles Concernant la réalisation du projet Recours au cycle incrémental : Page 6 sur 30

7 2.4.3 Concernant le suivi du projet Tout au long du projet, il est conseillé à chaque étudiant de noter le temps que lui aura nécessité la réalisation d une tâche. Cela lui permettra de compléter son suivi d activité et ainsi de comparer son planning au planning prévisionnel. Des réunions hebdomadaires, fixées au lundi soir de 17h à 18h par défaut, seront organisées avec l encadrant pour suivre et évaluer le bon avancement du projet. Un site web, réalisé par les étudiants, permettra aussi de suivre l état d avancement du projet. Page 7 sur 30

8 3. Développement 3.1 Analyse du problème et spécification fonctionnelle Notre logiciel met à disposition un jeu de voiture faisant interagir deux joueurs. Chacun des joueurs contrôle une voiture par l intermédiaire d un clavier en entrée et d un écran en sortie. Les utilisateurs doivent avoir la possibilité de jouer une partie en respectant les règles définies dans la partie conception détaillée Fonctionnalités du jeu Au début du jeu, les utilisateurs ont le choix entre trois circuits différents et trois voitures différentes. Une fois le choix réalisé, les deux voitures (une pour chaque utilisateur) se mettent en place sur la ligne de départ. Le but du jeu est alors de faire 3 tours de circuit le plus rapidement possible. Le gagnant est celui qui arrive le premier. Mais il y a aussi un classement parallèle sur la rapidité d un tour de terrain : c'est-à-dire, qu en plus de chronométrer le temps pour faire les trois tours, le jeu chronomètre aussi le temps mis pour faire un tour de piste. Il y a alors un top 3 des meilleurs temps réalisés dans le jeu. Un joueur peut donc ne pas gagner la partie mais rentrer dans ce classement. Lorsque le dernier joueur franchi la ligne d arrivée, un message s affiche à l écran qui indique quel joueur est le vainqueur, les temps mis par chacun des deux joueurs pour faire les trois tours de circuit ainsi que le temps du meilleur tour de chacun Données manipulées Nous manipulons dans le code de ce jeu des fichiers.c,.h, ainsi que des bibliothèques graphiques (principalement SDL). Pour les images réelles et logiques des circuits, nous manipulons également des fichiers image. Les fichiers concernant la partie codage sont permanents mais les données concernant une partie sont temporaires, excepté le top 3 des meilleurs tours Interface avec l utilisateur Nous avons donc en entrée le clavier avec deux combinaisons de touche (une pour chaque joueur) comme expliqué dans les règles de jeu. En sortie, nous avons l écran de l ordinateur qui permet de suivre la progression des voitures. Page 8 sur 30

9 3.2 Conception préliminaire Définition des modules Les structures de données utilisées sont :. typedef enum {false, true} Bool; dans main.c. typedef struct { int time1; int time2; int time3; int posj1; int posj2;} Score; dans updatescore.c Description :. Le fichier scores.txt dans lequel sont stockés les meilleurs temps est organisé grâce à la structure Score en 6 lignes, une structure par ligne.. Les 3 premières lignes de ce fichier correspondent aux meilleurs temps de course pour chaque circuit et les 3 dernières lignes correspondent aux meilleurs tours pour chaque circuit. Page 9 sur 30

10 . time1 est le meilleur temps. time2 est le 2eme meilleur temps. time3 est le 3eme meilleur temps. posj1 vaut -1 si le joueur 1 n'a pas fait de meilleur temps, 0 si le joueur 1 a fait le 1er temps 1 si le joueur 1 a fait le 2eme temps 2 si le joueur 1 a fait le 3eme temps - de même pour posj2 avec le joueur 2.. Cette structure permet un accès en lecture et en écriture aux meilleurs temps. Modules : Page 10 sur 30

11 3.2.2 Plan des tests d intégration Le programme est se décompose en trois modules importants :. La gestion et l affichage des menus. La gestion des scores. La course de voitures Nous allons donc pouvoir tester dans chaque module les fonctions apportées au programme principal telles que l affichage de menu, les collisions, les dérapages ou l entrée de nouveaux scores. Une fois que les tests internes à chaque module sont concluants, on peut alors effectuer l intégration des modules dans le programme principal et le tester en ajoutant une par une les fonctionnalités apportées. Page 11 sur 30

12 3.3 Conception détaillée Menu de choix Choix initial entre 3 circuits et 3 voitures (une pour chacun des joueurs) Règles d animation et de mouvement. La voiture peut avancer, reculer et tourner : plus l utilisateur appuie sur la touche «droite» plus la voiture tournera à droite et idem à gauche..tant qu elle est sur la piste, quand l utilisateur appuie sur la touche «avant» la voiture accélère jusqu à une limite qui représente la limite du moteur d une vraie voiture.. Si la voiture va trop vite dans un virage : elle dérape.. Lorsque la voiture sort de la piste il y a plusieurs possibilités : soit elle est dans l herbe, auquel cas, elle va ralentir, soit elle cogne contre un obstacle: auquel cas, elle s arrête Gestion des collisions. La voiture ne peut pas sortir de l écran : si elle arrive au bord de l écran, elle s arrête.. Si elle entre en collision avec un obstacle tel que des bottes de foins, elle s arrête.. On ne considère pas ici les collisions entre les voitures Gestion des points et du temps Au début, nous voulions faire un système de points pour tenir compte, non seulement du joueur qui arriverait en premier mais également de celui qui a fait le tour le plus rapide, de celui qui est le moins sorti de piste avec un système de bonus. Mais ce système s est avéré inutile puisque celui qui sort de piste est déjà pénalisé puisqu il ralentit et qu il n est pas forcément avantageux d être très inégal dans le jeu (il faut faire trois tours rapide et pas seulement un). Nous nous servons donc du temps comme système de points. Le premier arrivé gagne. Parallèlement à cela nous avons quand même un système d enregistrement du temps de chaque tour afin d établir un top 3 des meilleurs tours. Page 12 sur 30

13 3.4 Codage Description de la bibliothèque SDL La SDL, Simple Directmedia Layer, est une bibliothèque multimédia destinée à permettre l accès au matériel graphique. De plus, elle présente l avantage d être portable, c est-à-dire qu on peut l utiliser aussi bien sous Linux que sous Windows. Enfin, elle est totalement libre, sous licence LGPL. Son utilisation nous a entre autres permis de gérer : -le fenêtrage -la vidéo 2D -les évènements hardware (clavier dans notre cas) Et les timers Et de nous servir de certaines fonctions de base prédéfinies telles que : SDL_SetVideoMode qui permet d activer le mode vidéo souhaité SDL_WM_SetCaption qui permet de donner un titre à notre fenêtre SDL_BlitSurface qui permet de copier une surface SDL_CreateRGBSurface qui permet de créer une surface de type SDL_Surface * SDL_Flip qui permet de mettre à jour l écran SDL_FreeSurface qui permet de libérer les surfaces utilisées IMG_Load qui permet de charger une image RotozoomSurface qui permet de faire tourner et de zoomer une surface SDL_PollEvent qui permet de sonder et voir les évènements en attente SDL_Delay qui permet d attendre un temps donné en millisecondes avant d effectuer un retour dans une boucle Commentaires des codes Lancement du jeu : accueil Le jeu se lance avec l exécutable main compilé à partir de main.c. La fonction init() permet d initialiser la bibliothèque SDL, les différentes polices utilisées et d ouvrir la fenêtre du jeu. On entre alors dans une première boucle : while (!wanttoquit && menu_id < 7) Elle permet de quitter le jeu si l utilisateur le souhaite. Page 13 sur 30

14 Puis on entre dans une deuxième boucle : while (SDL_PollEvent (&event)) Elle permet de détecter les événements du clavier (appui de touches). Ensuite, on charge tel ou tel menu grâce au fonction load_menu et à l indicateur menu_id qui représente le numéro du menu affiché à l écran. menu_id Accueil Séléction des voitures Sélection du circuit Course Fin de la course Meilleurs temps Code principal du jeu Le code principal du jeu est ici la course et est décrit dans le fichier course.c. Tout d abord, on charge les images des voitures sélectionnées précédemment avec IMG_Load(). Par exemple : car1 = IMG_Load("../img/car_red.png"); Ensuite, en fonction du circuit (indiqué par l entier mapnum), on charge l image de fond, on positionne les voitures et on initialise l angle de départ. Avant le départ, la procédure countdown() décrite dans le fichier countdown.c permet d afficher un compte à rebours à l écran. Ensuite, la course commence Grâce à une boucle while (SDL_PollEvent (&event)), on test l appui sur les touches de direction des voitures (flèches directionnelles pour le joueur 1, (Q,Z,S,D) pour le joueur 2) et on agit en conséquence sur la vitesse et l angle des voitures (rotozoom.h). On affiche des informations à l écran telles que le temps de course et la vitesse des voitures grâce à la procédure infos() décrite dans infos.c. On vérifie et stocke les informations concernant le nombre de tours et les temps de meilleurs tours grâce à la procédure checkpoint() décrite dans checkpoint.c. L entier cp permet de comptabiliser le nombre de tours effectués. On utilise le tableau de 4 cases time[] construit et mis à jour tel que :. time[0] = temps du joueur 1 au bout des 3 tours. time[1] = temps du joueur 2 au bout des 3 tours. time[2] = meilleur temps au tour du joueur 1. time[3] = meilleur temps au tour du joueur 2 Page 14 sur 30

15 Utilisation d une image logique L image logique est l image du circuit simplifiée avec que quelques couleurs où chaque couleur de pixel a une signification précise et correspond a une propriété précise du circuit. Par exemple le blanc ralentit la voiture, le rouge l arrête. On utilise pour cela la fonction obtenirpixel décrite dans util.c. On compare alors à chaque instant de jeu la couleur du pixel où se situe la voiture avec les couleurs d environnements spéciaux (obstacles, ralentissements). Image Physique du circuit Image Logique du circuit Fin du jeu Lorsque le dernier joueur franchi la ligne d arrivée au bout de 3 tours, l entier findecourse passe de 0 à 1 et on charge le menu suivant. Grâce à la fonction load_menu5 et grâce au tableau time[], le menu affiche :. qui est le vainqueur : if (time[0] < time[1]) text4 = TTF_RenderText_Blended(font2, "Vainqueur : Joueur 1!", font_color); else text4 = TTF_RenderText_Blended(font2, "Vainqueur : Joueur 2!", font_color);. les temps des deux joueurs en minutes et secondes. Le dernier menu est celui des meilleurs temps. A la sortie du menu précédent, on fait une mise à jour des meilleurs temps (fichier scores.txt ) avec la procédure updatescore() décrite dans le fichier updatescore.c. On affiche alors les meilleurs temps mis à jour, avec le nom du joueur (J1 ou J2) affiché devant la performance s il y a un nouveau record. Cet affichage particulier s effectue grâce à la procédure affichejoueur() décrite dans le fichier affichejoueur.c. Page 15 sur 30

16 3.5 Tests Vérification individuelle Après l écriture de chaque partie du programme, le but était de l intégrer au programme déjà existant et de tester le tout voir si chaque partie marchait. Si ce n était pas le cas, il fallait l enlever du code principal et retravailler dessus. C est ce qui a été le cas plusieurs fois pour la gestion des dérapages où la voiture ne tournait pas et ne dérapait pas forcément comme nous le voulions Tests d intégration globaux Pour les tests globaux, on vérifiera que les fonctions développées séparément sont compatibles entre elles et forment un ensemble qui respecte le cahier des charges initial. Pour chacun de ces tests, en cas de problème, nous utilisions le débuguer : ddd Tests sur la rotation des voitures On considère une des voitures (le code est le même pour les deux) et on regarde si la réaction aux touches est bonne (si elle ne tourne pas trop vite ou ne se retourne pas) Tests sur les collisions avec des obstacles On vérifie en faisant aller une voiture sur un obstacle que celui là la stoppe bien et que elle ne passe pas dessus sans réaction du jeu Tests sur l arrivée de la voiture au bord de l écran On fait aller une des voitures au bord de l écran et on vérifie qu elle s arrête bien et qu elle ne re rentre pas par le côté opposé de l écran Tests sur les dérapages de la voiture On vérifie que lorsqu une voiture prend un virage trop vite, elle parte bien en dérapage mais que le dérapage soit contrôlé, suivant un bon angle. 3.6 Intégration L étape d intégration permet de vérifier que l ensemble des modules testés précédemment séparément fonctionnent aussi tous ensemble. Mais tous les modules n ont pas pu être testés séparément du fait de l interdépendance de certains d entre eux. Nous les avons donc rajoutés au code principal pour les tester à chaque fois. L'intégration des différents modules s'est donc faite au fur et à mesure de la progression du codage. Cette intégration fut l'occasion de nouveaux tests des fonctions en C, car certaines erreurs imprévisibles en mode terminal sont apparues en mode graphique, et ont dû être rectifiées. Page 16 sur 30

17 Voici donc ce qu il s est réellement passé lors de notre projet par grandes étapes: -codage d un point tournant sur un circuit -codage du remplacement du point par une voiture -codage de la gestion des collisions et des obstacles -codage des équations de dérapage de la voiture -codage de l ajout d une deuxième voiture et du choix des circuits -codage de la gestion du temps et des scores -codage de la gestion des accélérations, décélérations en fonction de l endroit de l image auquel on se trouve en faisant appel à l image logique. Ainsi les tests ont essentiellement consistés à examiner si chaque nouvelle étape codée s ajoutait bien ou remplaçait bien les étapes précédentes, c est-à-dire fonctionnait exactement telle que nous l attendions sans erreur ou écart. Page 17 sur 30

18 4. Interprétation des résultats Nous avons réussi à réaliser un jeu de voiture qui fonctionne correctement. Il n est évidemment pas conforme à la réalité de ce qu il se passerait sur un véritable circuit mais en donne une bonne idée. Notre jeu reste simple mais rempli le cahier des charges. Nous avons donc réalisé un jeu de voiture de base. Avec plus de temps, nous aurions pu agrémenter un peu plus notre jeu et améliorer certaines fonctionnalités. Nous aurions par exemple pu rajouter des boosters qui accélèreraient la voiture au moment où elle passe dessus. Mais le temps imparti était trop court pour rajouter de nombreuses fonctionnalités. Page 18 sur 30

19 5. Manuel utilisateur 5.1 Pré requis Pour jouer avec ce jeu de voiture vous devez au préalable avoir installé la bibliothèque SDL sur votre ordinateur. Pour se faire, vous pouvez aller sur le site Installation et lancement du jeu en 5 étapes Etape n 1 : Téléchargez l archive source.tar.gz Etape n 2 : Décompressez l archive Etape n 2 : Placez-vous dans le répertoire src/ Etape n 3 : Tapez la commande make dans votre terminal Etape n 4 : Tapez./main dans votre terminal Etape n 5 : Jouez! 5.3 Lancement du programme Le programme commence par le menu d accueil. Pressez alors la touche «entrée» pour continuer : Page 19 sur 30

20 A l aide des flèches du clavier, des touches Q et D, ainsi que de la touche «entrée» choisissez la couleur des voitures proposées pour chaque joueur : De la même façon choisissez un des trois circuits de jeu : Page 20 sur 30

21 5.4 Instructions de jeu Bienvenue dans le jeu Race Driver 2D! Mais en fait quel est le but du jeu? Finir trois tours de circuits avant l autre joueur, autrement dit, franchir le premier la ligne d arrivée. Si vous avez plus d ambition vous pouvez également essayer de faire un tour de circuit le plus rapidement possible pour rentrer dans le TOP 3 du jeu. Comment me déplacer sur le circuit? Rien de plus simple! Le joueur 1 doit se servir des touches : A quoi servent chacune des touches? Flèche du haut : faire avancer (et accélérer) la voiture Flèche de gauche : faire tourner la voiture à gauche Flèche de droite : faire tourner la voiture à droite Flèche du bas : faire freiner la voiture, ou reculer en cas d arrêt Comment s en servir? Flèche du haut : Appuyer sur cette touche vous permettra de faire augmenter la vitesse de la voiture. La relâcher fera progressivement diminuer la vitesse de la voiture jusqu à son arrêt complet. Ainsi pour avancer sans s arrêter ou ralentir il faut maintenir la touche flèche du haut enfoncée. Flèche du bas : Appuyer sur cette touche vous fera ralentir Flèche de droite : Appuyer une fois sur cette touche fera tourner la voiture vers la droite. Pas besoin de maintenir cette touche enfoncée par la suite. Flèche de gauche : Appuyer une fois sur cette touche fera tourner la voiture vers la gauche. Pas besoin de maintenir cette touche enfoncée par la suite. Page 21 sur 30

22 Le joueur 2 devra se servir des touches : La correspondance des touches avec le joueur 1 est la suivante : z=flèche du haut q=flèche de gauche s=flèche du bas d=flèche de droite Remarque importante Attention si vous allez trop vite, votre voiture va déraper! Négociez donc bien vos virages! Page 22 sur 30

23 6. Conclusion Ce projet a été très enrichissant pour chacun d entre nous malgré les très nombreuses difficultés rencontrées. Tout d abord, il a fallu apprendre à se servir de la bibliothèque SDL, outil complètement inconnu et donc nouveau pour nous. Nous avons certes eu la plupart des fonctions de la SDL pré-codées mais il a quand même fallu apprendre à s en servir à bon escient. Une partie difficile du projet a aussi été de gérer les déplacements sur l écran des deux voitures en manipulant à la fois le C et la SDL. Nous avons ainsi découvert que la programmation d un jeu, même simple était beaucoup plus compliquée qu il n y parait et demandait beaucoup de travail. Mais ce projet a aussi permis de nous obliger à prendre en compte toutes les phases de la création d un projet et de réaliser que pour qu il marche, toutes les étapes sont indispensables. Nous avons également réalisé que dans un projet informatique, plus que dans tout autre projet, il faut avancer à petit pas, puis reculer pour mieux ré-avancer. Nous avons ainsi découvert une nouvelle façon de travailler : Création de petits bouts de code par différentes personnes puis assemblage de ces derniers puis mis en place des modules pour finalement aboutir à un code complet. Une autre difficulté rencontrée a été les fluctuations de motivation des membres de l équipe. En effet, sur un projet de plusieurs mois, il est difficile de rester motivé tout au long du projet et il est encore plus difficile de faire en sorte que tout le monde soit motivé en même temps. Mais le choix du groupe de départ a été très important. Heureusement, nous connaissant bien, il était plus facile de communiquer entre nous ainsi que de nous motiver mutuellement. Nous pouvions ainsi parler régulièrement de nos objectifs et de nos problèmes. Les réunions quasi hebdomadaires ont également beaucoup compté pour l avancement du projet puisqu elles nous forçaient à un travail plus ou moins régulier. La dernière difficulté rencontrée a été le respect du plan de charge. En effet, tous les membres de l équipe n avait pas la même aisance à programmer ce qui a mener au fait que pendant que certains avançaient sur le projet, d autres stagner un peu plus longtemps sur la même fonction ce qui a mener à un déséquilibre dans la répartition du plan de charge. Même si au final, le nombre d heures prévues pour chacun a en moyenne été respecté, la répartition de ces heures l a moins été. Mais malgré toutes ces difficultés, nous avons quand même une grande satisfaction d avoir réussi à finir ce projet, d avoir au final un vrai jeu de voiture qui marche. Ce projet a avant tout été un travail d équipe ce qui donne une satisfaction d autant plus grande puisqu il y a à la fois la satisfaction d avoir mené un projet à bien mais aussi celle de l avoir mené ensemble. Evidemment notre jeu reste perfectible et de nombreuses autres fonctions auraient pu être mises en place telles que les boosters. Nous aurions pu aussi prendre des images de vrais circuits mais cela s est avéré très compliqué. Nous aurions pu également améliorer le système de collisions et de rebonds. Malgré ces améliorations, nous restons tout à fait satisfaits du projet et remercions Sébastien LERICHE pour son aide et sa compréhension. Page 23 sur 30

24 7. Bibliographie Annexes 8.1 Annexe 1 : Gestion de projet Plan de charge PLAN DE CHARGES PREVISIONNEL Description de l'activité Charge en % Charge en H Aurélie PAGET Respo. Doc. Charge en H / Participant Laure Guillaume PATER BELKACEM Respo. Respo. Com. Qualité Mathieu LIMA Chef de Projet Total 100% Gestion de projets 25% Réunion de lancement 2% Planning prévisionnel et Suivi d'activités 2% Réunions de suivi 12% Rédaction 6% Site Web 3% Conception préliminaire 12% Définition d'un modèle de données 3% 6 1,5 2,5 1,5 2,5 Définition d'un format de fichiers associé au modèle de données 2% Définition des fonctionnalités, des règles du jeu 5% 10 2,5 2,5 2,5 2,5 Maquettage des IHM 2% Page 24 sur 30

25 1er incrément: le moteur physique 34% Conception du moteur physique 8% Modélisation des intéractions voitureenvironnement 6% Définition des intéractions joueurclavier 2% Codage du moteur physique 20% Définition des différents modules (.h) 2% Ecriture des interfaces (.h) 1% Ecriture du makefile 1% Ecriture des différentes fonctions 10% Tests unitaires 6% Intégration du moteur physique 6% Intégration des différents modules 4% Tests d'intégration 2% e incrément: les graphismes 10% Conception 1% Définition du chargement des images physique et logique 0,50% 1 1 Définition du chargement des propriétés du circuit 0,50% 1 1 Codage 6% Définition des modules supplémentaires (.h) 1% Ecriture des interfaces (.h) 1% Réecriture du makefile 1% Ecriture des différentes fonctions 2% Tests unitaires 1% Page 25 sur 30

26 Intégration 3% Intégration des différents modules 2% Tests d'intégration 1% e incrément: les menus et la gestion des scores 11% Conception 2% Création des images des menus 1% Définition du chargement et de l'enregistrement des scores 1% Codage 6% Définition des modules supplémentaires (.h) 1% Ecriture des interfaces (.h) 1% Réecriture du makefile 1% Ecriture des différentes fonctions 2% Tests unitaires 1% Intégration 3% Intégration des différents modules 2% Tests d'intégration 1% Soutenance 8% Préparation de la soutenance 6% Soutenance 2% Page 26 sur 30

27 Gestion de projets 25% Conception préliminaire 12% er incrément: le moteur physique 34% e incrément: les graphismes 10% e incrément: les menus et la gestion des scores 11% Soutenance 8% Planning prévisionnel Page 27 sur 30

28 8.1.3 Suivi des activités SUIVI DES ACTIVITES Description de l'activité Charge en % Charge en H Aurélie PAGET Respo. Doc. Charge en H / Participant Laure Guillaume PATER BELKACEM Respo. Respo. Com. Qualité Mathieu LIMA Chef de Projet Total 100% Gestion de projets 22% Réunion de lancement 2% Planning prévisionnel et Suivi d'activités 2% Réunions de suivi 12% Rédaction 5% Site Web 1% 2 2 Conception préliminaire 12% Définition d'un modèle de données 4% 8 1,5 2,5 1,5 1,5 Définition d'un format de fichiers associé au modèle de données 2% Définition des fonctionnalités, des règles du jeu 4% 8 2,5 2,5 1,5 1,5 Maquettage des IHM 2% er incrément: le moteur physique 34% Conception du moteur physique 8% Modélisation des intéractions voitureenvironnement 6% Définition des intéractions joueurclavier 2% Page 28 sur 30

29 Codage du moteur physique 21% Définition des différents modules (.h) 2% Ecriture des interfaces (.h) 2% Ecriture du makefile 1% Ecriture des différentes fonctions 11% Tests unitaires 5% Intégration du moteur physique 6% Intégration des différents modules 4% Tests d'intégration 2% e incrément: les graphismes 12% Conception 1% Définition du chargement des images physique et logique 1,50% Définition du chargement des propriétés du circuit 0,50% 1 1 Codage 8% Définition des modules supplémentaires (.h) 1% Ecriture des interfaces (.h) 1% Réecriture du makefile 1% 1 1 Ecriture des différentes fonctions 3% Tests unitaires 2% Intégration 3% Intégration des différents modules 2% Tests d'intégration 1% Page 29 sur 30

30 3e incrément: les menus et la gestion des scores 12% Conception 3% Création des images des menus 2% Définition du chargement et de l'enregistrement des scores 1% 2 2 Codage 7% Définition des modules supplémentaires (.h) 1% Ecriture des interfaces (.h) 1% Réecriture du makefile 1% Ecriture des différentes fonctions 2% Tests unitaires 2% Intégration 4% Intégration des différents modules 2% Tests d'intégration 2% Soutenance 8% Préparation de la soutenance 6% Soutenance 2% Code source Le code source est disponible à l adresse suivante : Site Web Page 30 sur 30