Création d un jeu d arcade : Frogger

Transcription

1 Projet Langage Java UE : programmation & modélisation objet [RILA] RILA14 Création d un jeu d arcade : Frogger

2 Table des matières Le contexte... 3 Le jeu... 4 Spécifications fonctionnelles... 5 Déroulement du projet... 6 Itérations successives... 6 Gestion de planning... 6 Restitution du travail... 7 Le programme... 7 Rapport... 7 Soutenance... 8 Cesi S.O. RILA 2014 Page 2

3 Le contexte Vous êtes développeur chez KilaKila Games, une startup spécialisée dans le développement de jeux vidéo. Depuis peu, l entreprise s est spécialisée dans la refonte d ancien classique des jeux vidéo pour les remettre au goût du jour. Votre patron a investi dans un stand à l E à Los Angeles. Il souhaite ainsi montrer toutes les qualités de l entreprise afin d attirer d éventuelles investisseurs. Il a préféré privilégier la qualité en revisitant un classique des jeux vidéo d arcade : Frogger 2. Votre mission est simple : fournir une version de Frogger complète d ici l E3. Ce projet est crucial pour le développement de votre entreprise. Il faut montrer de quoi vous êtes capable en termes d effets visuels et sonores! 1 Electronic Entertainment Expo : Salon international des jeux vidéo basés à Los Angeles. 2 Frogger est un jeu d'arcade développé par Konami et sorti en Cesi S.O. RILA 2014 Page 3

4 Le jeu Le but du jeu est de diriger des grenouilles jusqu'à leurs maisons. Le joueur doit diriger les grenouilles en les déplaçant case par case en évitant des obstacles (voitures, rivière, ). Figure 1 - Image représentant la version originale de Frogger 1 Le joueur doit déplacer 4 grenouilles jusqu à leur maison (7) 2 Le score est calculé en fonction du nombre de lignes traversées. Chaque déplacement vers le haut ajoute 10 points au score. Lorsque le joueur arrive à conduire une grenouille jusqu à sa maison (7), le score est multiplié par le nombre de secondes restantes 3 Le joueur a 1 minute pour chaque grenouille. Une progress bar permet d indiquer le temps restant. Dès que le temps est écoulé, une nouvelle grenouille est positionnée au départ (s il n y en a plus, le joueur a perdu). 4 Départ 5 Cette zone sur 5 lignes correspond à une route avec plusieurs types de voitures et de camions. Les voitures sur chaque ligne ont une vitesse aléatoirement calculée. 6 Cette autre zone sur 5 lignes est une rivière avec des tronçons de bois de taille variable et des tortues. Si la grenouille tombe dans l eau, le joueur a perdu. Les tortues se déplacent par 2 ou 3 et vont sous l eau de manière aléatoire. Si la grenouille se trouve sur une tortue qui se met à nager sous l eau, le joueur a perdu. 7 Il y a 5 maisons de grenouille. De manière aléatoire, une mouche se positionne dans l une des maisons pour empêcher la grenouille de rentrer dans sa maison. Cesi S.O. RILA 2014 Page 4

5 Spécifications fonctionnelles Vous devez réaliser : - Le jeu présenté précédemment - 3 niveaux avec une difficulté croissante (vitesse plus rapide, nombre d obstacles plus important ) - L enregistrement des meilleurs temps Vous êtes libres (et encouragés) d ajouter des éléments supplémentaires au jeu (nouveaux obstacles, ). Le but n est pas de faire une copie originale du jeu mais une nouvelle version correspondant au goût du jour. Les ressources graphiques que vous utiliserez pourront être librement choisies ou tirées du jeu original : l univers présenté tourne autour de la grenouille mais vous êtes libre d utiliser l univers de votre choix (une poule rentrant au poulailler et évitant des renards par exemple ). Votre application contiendra un menu d accueil permettant de : o Commencer une nouvelle partie o Afficher les meilleurs scores o Afficher les options o Quitter N oubliez pas que vous faites une application pour démontrer les compétences de votre entreprise. Il faut donc que les graphismes et les effets soient à la hauteur! Les options permettent de sélectionner le niveau de difficultés. Lorsque le joueur arrive à rentrer les 3 grenouilles sur un niveau de difficulté, son identifiant lui est demandé pour que son score puisse être inscrit parmi les meilleurs temps. Cesi S.O. RILA 2014 Page 5

6 Déroulement du projet Le projet est individuel. L entraide et le partage de connaissance sont bien sûr recommandés. Cependant, un effort particulier sera réalisé pour détecter tout code source qui pourrait trop se ressembler entre plusieurs projets. Le projet débute dès à présent et se termine le 04/06/2015 par une soutenance. Dans la partie qui suit, nous proposons un déroulement de projet, qu'il est conseillé de suivre afin d' «avancer lentement mais sûrement» ; il est toutefois possible de s'écarter de ce scénario mais si le projet ne devait pas aboutir ou être inachevé vous ne feriez que compliquer le travail des évaluateurs. Itérations successives Tout d'abord vous devez développer de manière itérative, c'est à dire faire grossir le projet en ajoutant à chaque fois des petites fonctionnalités afin de toujours avoir quelque chose qui fonctionne. Gestion de planning Comme pour tout projet, une bonne gestion du temps sera nécessaire : - déterminez d'abord un plan d'attaque : définissez vos objectifs définissez votre planification, e.g. celle qui vous permettra de choisir telle ou telle option de développement suivant le temps disponible - lancez le projet - faîtes tous les jours des points d'avancement : ce sont ces points d'avancement qui vous permettent de piloter votre projet - gardez la tête froide et ne quittez pas des yeux les minima attendus - débutez le rapport et le diaporama de soutenance dès le début du projet puis complétez-les tout au long du projet. Cesi S.O. RILA 2014 Page 6

7 Restitution du travail Le programme Afin de pouvoir faire facilement les itérations, il est fortement conseillé d'utiliser un outil de version de code source (SVN ou Git) : vous serez ainsi à même de sortir la dernière version stable de votre projet pour la soutenance. Pour éviter les surprises de dernières minutes, il est également conseillé d utiliser un dépôt de source distant (ex : Github ou BitBucket) afin de garantir l intégrité et la sécurité de votre code source. Ci-dessous quelques remarques, concernant les points qu est en droit d attendre votre responsable technique pour évaluer la qualité de votre programme : - les conventions d écriture sont respectées sur l ensemble du code : JavaBean, Architecture logicielle, Nommage en camelcase (UpperCamelCase = classe, interface et lowercamelcase = tous les autres, c'est-à-dire méthodes, attributs, ), Javadoc, Encapsulation, Designs patterns - vous travaillez comme si vous étiez en équipe : le code doit être suffisamment clair pour être compris sans javadoc (même si vous devez faire quand même une javadoc). - la gestion des exceptions mise en place est utile - les données et textes affichés sont pertinents et sans faute d orthographe - les composants doivent être correctement positionnés dans les fenêtres qui doivent supporter le redimensionnement - les saisies utilisateurs doivent être contrôlées - les composants doivent présenter une forte cohésion et un faible couplage - etc. Une version stable du code de votre application devra être remis 1 semaine avant la date de soutenance à votre intervenant (ou rendu accessible par un moyen quelconque : lien GitHub, Bitbucket, ). Ceci ne vous empêchera pas de modifier le code jusqu à la soutenance. Rapport Le rapport doit être remis, sous forme électronique 2 jours minimum avant la date de soutenance. Il est destiné au responsable technique de votre entreprise. Ce rapport contiendra au minimum : Partie 1 : Présentation - Introduction - Rôles des membres du groupe - Rappel de la demande Cesi S.O. RILA 2014 Page 7

8 Partie 2 : Gestion de projet - Planning prévisionnel - Planning (réalisé) - Synthèse sur l organisation et le déroulement du projet (dont la répartition de la charge de travail) Partie 3 : Développement - Analyse fonctionnelle (les diagrammes de cas d utilisation seront présentés dans cette partie) Ne pas oublier l ordonnancement des priorités - Maquette de l IHM - Une présentation des technologies, frameworks et outils utilisées pour la conception de votre application - Conception UML commentée. Vos choix conceptuels doivent être justifiés. En cas d écart entre l analyse et la réalisation, des justifications doivent être fournies dans l analyse des écarts. Tout diagramme non commenté ne sera pas pris en compte. La conception est une composante majeure du projet au même titre que la réalisation. Partie 4 : Conclusion & perspective - Analyse des problèmes rencontrés et solutions apportées. Dans le cas où des solutions n ont pu être trouvées (écarts entre la conception UML et le livrable technique, fonctionnalités non implémentées ), il faut proposer des pistes de solutions ou fournir des explications. Vous pouvez distinguer 3 types de solutions : curatives, préventives, correctives. Il est conseillé de résumer les problèmes et les solutions dans un tableau à la fin de cette partie. - Evolution proposée pour le système - Bilan personnel - Le bilan personnel est une capitalisation d expérience. Dans le bilan personnel apparaîtront les Compétences initiales au démarrage du projet, et les compétences acquises durant le projet. Sur l ensemble des compétences, il faudra distinguer les compétences initiales et celles acquises qui ont été nécessaires pour le bon déroulement du projet. Soutenance Elle a lieu le 04/06/2014 La présentation est destinée au responsable technique de votre entreprise. Le travail sera soutenu de préférence sous la forme suivante : - présentation de 20 minutes, - des questions/réponses individuelles de 10 minutes maximum, - une délibération du jury Cesi S.O. RILA 2014 Page 8