Slide 6 : transition L'environnement de travail en place, je vais parler un peu du déroulement du projet et de la conception que j'ai pu en faire. Slide 7 : gestion de projet








télécharger 25.79 Kb.
titreSlide 6 : transition L'environnement de travail en place, je vais parler un peu du déroulement du projet et de la conception que j'ai pu en faire. Slide 7 : gestion de projet
date de publication31.03.2017
taille25.79 Kb.
typeDocumentos
ar.21-bal.com > droit > Documentos

Slide 3 : Le jeu


Frogger est un jeu d'arcade développé à l'origine par la société Konami en 1981.

Le principe est le suivant, on dirige une grenouille et l'objectif est de la mener jusqu'à sa maison en évitant tous les obstacles sur le chemin. Le trajet est découpé en deux zones.

Il faut d'abord traverser une route en évitant de passer sous les roues des voitures, puis une rivière en sautant de tronc en tronc (la grenouille coule….).

Slide 4 : Le projet


Le projet est donc de reprendre le concept de ce jeu Frogger, en respectant les règles minimales :

  • Un nombre de vie, ou grenouilles à faire traverser

  • Les différentes zones :

    • une où la grenouille meurt si elle rencontre un objet,

    • une où c'est exactement l'inverse.

  • Un chronomètre limitant le temps disponible pour faire parvenir une grenouille au bout du chemin

  • Des niveaux de difficultés croissantes (vitesse, nombre d'obstacles, temps…)

  • Le décompte des points

Le projet doit être développé en utilisant le langage JAVA.

Slide 5 : environnement technique


Pour réaliser le projet, j'ai dû faire un choix parmi un certains nombres d'outils et de techno. :

  • Le langage est imposé : Java. J'ai choisi d'utiliser la dernière version (pour utiliser les dernières MAJ / features)

  • eclipse : l'IDE de développement Java (avantages sur NetBeans : plugins, long dév… )

  • Un système de gestion de version : git. Simple, efficace, libre, github gratuit (repo distant)

  • Outils de build : ANT, pour sa simplicité de mise en œuvre. Correspond tout à fait à mes besoins. Créé à la base par apache, en Java…. Vieillissant par rapport aux derniers outils en date (Graddle).

  • Une librairie graphique : JavaFX, le remplaçant officiel des swings. Objectif d'apprentissage, profiter du l'exercice pour en apprendre le plus possible.

    • Accompagné d'un outil graphique de création d'IHM !! pratique !

Slide 6 : transition


L'environnement de travail en place, je vais parler un peu du déroulement du projet et de la conception que j'ai pu en faire.

Slide 7 : gestion de projet


Concernant l'organisation du temps, au départ, j'avais prévu un planning général pour toute la durée du projet en m'appuyant sur ma première analyse du cahier des charges. Je prévoyais une phase de formation, de conception, de codage et de documentation. J'avais découpé ma phase de développement en plusieurs parties correspondant directement aux différents "moteurs" nécessaires. En suivant ce planning et dans le cas où je n'aurais rencontré aucune difficulté (cad que la conception aurait été parfaite et le développement évident), j'aurai construit mon application par ajout successif de briques fonctionnelles (partie graphique, partie collisions etc…).

Finalement, j'ai abandonné ce planning prévisionnel dès le début de la phase de développement, pour adopter une méthode plus agile avec une stratégie de développement et d'enrichissement d'un prototype.

J'ai ensuite fait progresser mon "MVP" (minimum viable product) en faisant évoluer les différents "moteurs" par itérations successives en trois phases :

  • Une phase de recherche et formation pour un problème donné

  • Une phase de développement de la solution

  • Une phase d'implémentation

Cela m'a permis de garder constamment une version de l'application que je pouvais tester et montrer et m'assurer que mon choix était fonctionnel. C'est aussi rassurant de voir une évolution dans le travail…

Il s'agissait ici de parler de la façon dont j'ai travaillé, maintenant je vais parler un peu de la conception.

Slide 8 : IHM


Le cahier des charges est explicite sur les menus qui doivent apparaître dans l'écran d'accueil :

  • Menu jouer : qui doit lancer la partie

  • Scores : qui permet la consultation des meilleurs scores

  • Options : qui permet de modifier la difficulté du jeu

  • Quitter…..

Chacun de ces menus répondent à un cas d'utilisation précis. Je vais détailler un peu le cas le plus intéressant : jouer.

Slide 9 : Lancer un partie


A haut niveau, soit du point de vue de l'utilisateur (joueur ici), une partie doit se composer au minimum :

  • D'un début : ce peut être le démarrage d'un chronomètre, ou une position particulière sur l'écran... chaque jeu à son début (échec, plateau, carte…), ici c'est le clique sur le bouton jouer.

  • Un déroulement, le gameplay : la phase de jeu proprement dite où chaque action du joueur aura des répercussions sur la suite du déroulement de la partie.

  • Une fin… un but à atteindre, sinon aucun intérêt, qui est différent selon les jeux également (argent, point, domination, temps)

Slide 10 : Eléments du jeu


Un niveau plus bas, d'un point de vue technique, on a de nouveaux éléments (classiques) :

  • Des objets graphiques en mouvement (grenouille, obstacles)

  • Des comportements particuliers lors de leurs interactions avec la grenouille (collisions)

  • Une gestion des points, des vies et du chronomètre (règles)

Ce qui permet de séparer les responsabilités en plusieurs "moteurs" :

  • Le moteur de jeu : qui va gérer les déplacements des objets graphiques (et les afficher).

  • Le moteur de collisions : qui va tester les collisions entre les différents objets graphiques.

  • Les moteur de règles : qui va compter les points, les vies restantes, gérer le chrono.

Slide 11 : Déroulement d'une partie


Ce diagramme de séquence simplifié représente le déroulement d'un cycle d'une partie de jeu.

On y retrouver les différents moteurs évoqués précédemment et les dialogues entre eux.

Une fois la partie lancée, on entre dans une boucle de jeu infinie qui effectue plusieurs actions :

  • Si le joueur a appuyant sur un contrôle, il faut déplacer la grenouille

  • Auquel cas, il faut vérifier si la grenouille peut se déplacer vers la position demandée, on vérifie donc le type de collisions qu'il y aura.

  • La réponse est envoyée au moteur de règle pour savoir si on peut autoriser ou non le déplacement.

  • Selon le retour, on peut déplacer la grenouille et mettre à jour l'IHM ou non…

Slide 12 : transition


Après une analyse du cahier des charges et une phase de conception globale de l'application, je suis rapidement passé au développement.

J'ai choisi d'utiliser l'API JavaFX pour le projet, donc il m'a fallu apprendre et comprendre quelques notions liées à son utilisation.

Slide 13 : JavaFX


Un petit topo général :

  • C'est une librairie graphique développée par oracle, pour remplacer les swings.

  • Elle est intégrée de base au JDK (JRE ?) depuis la version 8, et nécessite cette version pour fonctionner.

  • JavaFX se veut multiplateforme : linux, os x, windows.

On s'écarte un peu du concept de programmation de l'IHM directement dans le code que l'on retrouve dans le développement d'application riche, lourde, pour se rapprocher du concept de développement web, avec la possibilité de décrire les IHM dans des fichiers séparés en (F)XML. Ces fichiers sont parsés par l'API et les objets (que l'on appelle des nodes) sont rendus accessibles.

Le fait de pouvoir décrire l'IHM dans un fichier à part permet, dans un cadre professionnel, de diviser le travail entre le développeur et l'intégrateur ou dév front end…

A niveau du projet, cela m'a permis d'organiser un peu l'architecture de l'application, de tester le rendu avec différents fichiers Fxml, et surtout d'utiliser un outil graphique pour construite mes IHM : Scene builder.

Slide 14 : Animations


JavaFX a été développé avec l'idée de moderniser les IHM des clients riches et intègre dans cette optique des fonctionnalités telles que les animations, les effets, la 3D, les médias audio et vidéo.

Pour gérer les animations, il faut définir des images-clés pour des moments précis. On définit donc un état initial d'un objet au temps 0 et l'état final du même objet au temps 1. La transition entre ces deux états est gérer par l'API.

Son gérée, nativement, plusieurs types de transition, dont les translations que j'utilise dans le projet pour déplacer mes objets, ce qui permet de ne pas voir une téléportation de la grenouille ou des obstacles.

Les animations reposent sur le principe de ligne de temps (timeline) et il est possible par ce bais de définir ses propres animations (c'est le cas de sprites).

Slide 15 : Game loop


C'est également le cas de ma boucle de jeu.

La classe Timeline accepte dans sa signature un gestionnaire d'événement.

Plutôt que d'utiliser une boucle classique "while(true)" et organiser une gestion complexe des Threads pour gérer les cycles d'une partie, j'ai déclaré et lancé une timeline, dans laquelle j'effectue les opérations.

Ainsi, je peux définir le nombre de FPS que je souhaite : 1000ms / 30 = 30FPS. Et chaque frame effectue les opérations de mise à jour du chrono, de déplacements des objets et de vérification des règles.

Slide 16 : Collisions


Deuxième point important une fois qu'on a des objets qui se déplacent, c'est de pouvoir tester s'ils sont en collisions…

La vérification des collisions permet :

  • De savoir si la case que sera la position de la grenouille après son déplacement est accessible. Et donc d'autoriser ou non le déplacement.

  • De savoir si le "type" d'obstacle rencontré.

Le type des collisions est défini par une propriété des nœuds directement dans le fichier FXML.

Dans sa première version, la moteur de collisions testé tous les nœuds connus de la map afin de vérifier leur position par rapport à la grenouille. Il se trouve que j'avais des problèmes de ralentissements et des ratés, les nombres de nodes s'élevant à plus de 100…

J'ai donc revu le principe et essayé de le simplifier.

Slide 17 : Collisions


J'ai essayé de définir les cas dans lesquels les collisions avaient lieu et les conséquences possibles :

  • Quand la grenouille se déplace :

    • On n'accepte pas le déplacement

    • On accepte le déplacement

      • On meurt

      • Ou pas

  • Quand les obstacles se déplacent :

    • La grenouille doit vérifier qu'elle n'est pas en collision avec ces obstacles.

Ainsi dans le premier cas, je teste uniquement la liste des éléments statiques du plateau et qd j'ai un déplacement.

Dans le second cas, je teste uniquement l'obstacle en mouvement.

Pour ce second cas, j'ai mis en place un pattern qui m'a semblé adapté à mon problème : le pattern mediator.

L'objectif est de faire communiquer des objets sans qu'ils n'aient besoin de se connaître (couplage faible). La méthode ressemble au pattern observer, dans le sens où les "observateurs" doivent s'inscrire à un sujet observable, afin d'être notifiés lorsqu'un événement survient.

Avec le pattern mediator, les objets observateurs sont nommés "collègues" et s'inscrivent à un objet "mediateur". Lorsqu'un des colleagues émet un événement, il envoie un message à travers le mediateur, message qui est ensuite transmis aux colleagues inscrits.

Dans le cas du projet, le médiateur est le moteur de collisions, et les collègues sont les objets graphiques qui peuvent se déplacer. Quand un obstacle bouge, l'objet grenouille est notifié et vérifie s'il est en collision avec cet obstacle.

Cette seconde version du moteur de collision est celle qui est implémentée dans la version actuelle de l'application.

Slide 18 : transition


J'ai essayé de présenter les problématiques principales du projet et les solutions que j'ai choisis. Maintenant, j'ai fait ces choix à moment donné et selon une expérience donnée, où ces choix m'ont semblé pertinents. Je ne ferai pas nécessairement ces mêmes choix aujourd'hui, et ils seront certainement encore différents de ceux de demain.

Slide 19 : Perspectives


Gestion du redimensionnement : chercher un moyen de rendre le redimensionnement intéressant. Avoir une plus grosse grenouille n'apporte rien je trouve. Un décors autour peut être une solution… Le mieux serait sans doute d'agrandir la taille de la map, qui embarquerait plus d'obstacles et serait accompagnée de règles adaptées.

Les déplacements sont un problème majeur que j'ai dû résoudre en début de développement. Après avoir travaillé sur le déplacement de la grenouille, en utilisant une animation JavaFX (translation), j'ai adapté la solution pour prendre également en compte les déplacements des obstacles.

Aujourd'hui j'ai plusieurs problèmes :

  • La gestion des déplacements troncs/grenouille et la sortie de la grenouille depuis un tronc.

  • Chaque nœud appelle une nouvelle animation 30x par seconde….. => pb de gestion de mémoire.

Au niveau du moteur de collision, une optimisation peut être faite en travaillant sur un système de radar. Chaque objet graphique serait autonome avec, autour, une zone de détection de collision. L'idée étant de ne notifier que les autres objets qui se trouvent dans cette zone et non la totalité de la liste des éléments…

Une grosse évolution serait de transformer toute la logique en une machine à état fini. On pourrait ainsi définir différents états et différentes transitions, qui spécifieraient les limites du jeu : déplacements, collisions, règles… qui pourraient être définis dans un fichier de configuration ou xml par exemple.

Slide 20 : Technique


Au travers du projet, mais également en formation, et aussi en entreprise… j'ai appris beaucoup de choses… Mon niveau technique se limitait à 8 mois de formation dont 2 mois de POO et de 3 mois de stage.

Cela m'a permis de m'intéresser à JavaFX, qui semble être une techno intéressante pour les applications riches, tant qu'elles existent encore…

Je commence aussi à mieux comprendre la logique POO et les implications d'un développement objet.

UML : je n'avais pas la vision "outil" d'UML… C'était pour moi une méthode complexe qui était utilisée par des pros de la conception… Bon finalement la vision a évoluée et il s'avère que c'est un outil pour communiquer et représenter graphiquement des fonctionnements qui peuvent parfois être très complexes, avec différents types de diagrammes à des niveaux techniques différents.

Comme tous outils, et au même titre que la méthode Agile ou les tests unitaires, je crois qu'il faut commencer par essayer de les adopter (si cela nous convient) le plus souvent possible afin de gagner en expérience, afin que cela devienne véritablement bénéfique.

Slide 21 : Expérience


Il s'agissait de mon premier vrai projet tout seul… et je dois dire que je manque de méthodologie pour gérer un projet… Notamment en ce qui concerne la phase pré-développement :

  • Difficulté à estimer le temps nécessaire pour une phase ou un dév…

  • Difficulté de conception. En début de projet, je ne savais pas par quel bout prendre le sujet… On a vu de puis une méthode qui ne demande qu'à être essayée.

Enfin, du fait que ce soit un jeu, il a fallu adopter une logique différente d'une simple application de gestion. En dehors du côté ludique du projet, il est intéressant par ce besoin de prendre du recul par rapport à l'algorithmique de base afin de se poser des questions d'architecture, d'optimisation, de rendu, d'ergonomie, de captiver l'utilisateur…

Toutes les questions qui définissent finalement le métier du développement : le travail de recherche de solutions, de choix, de tests… d'ouverture d'esprit, qui donne de nouvelles idées et qui sont bénéfiques dans le travail de tous les jours. (Ça peut être une simple animation utilisée dans une application qui permet de rendre le travail d'un utilisateur plus "visuel" et "ludique"…)

Slide 22 : Bilan personnel


Ces derniers mois ont été très formateurs. Le projet m'a obligé à me poser des questions et à chercher des solutions plus ou moins convaincantes et élégantes. Il a fallu que je critique chaque solution technique avec mon expérience à un moment donné.

J'ai effectué par ce biais un travail sur moi-même, afin d'avoir également un regard critique et de connaître mes attentes et le chemin à parcourir pour y arriver…

C'est aussi un premier projet qui me permet de voir un peu ce qui est attendu ici, pour la formation RILA. Et je dois dire que, malgré le plaisir certain que j'ai à "jouer" en développant, j'espère vraiment que je serai à même de ne pas recommencer la même erreur de gestion du temps pour le prochain projet (parce que c'est quand même légèrement épuisant sur la fin…).

similaire:

Slide 6 : transition L\Réunion n°3 Gestion de Projet charte du projet tic 9 juillet 2008...
«Phase de définition ou pré-étude» du projet et permet, après validation par le Comité de Pilotage, de lancer le projet

Slide 6 : transition L\De Juillet 2008 editorial
«structurants», comme l’on dit, un projet d’aménagement global de la place a été demandé à la D. D. E et au C. A. U. E (Conseil en...

Slide 6 : transition L\Rapport final Préparé par Stéphanie Tremblay Chargée de projet (2013-2014)...
«Universal Design for Learning» ou cua aux réalités québécoises de nos établissements francophones d’enseignement supérieur 19

Slide 6 : transition L\Table des matières
«Le Taillan», décide de mettre en place un projet de gestion de qualité pour ses châteaux. Un programme sous Microsoft Access est...

Slide 6 : transition L\Projet de conception de site web

Slide 6 : transition L\Rapport d’activite 2010 (Projet présenté à l’AG.) Actions nationales «Code de la rue»
«La mobilité au cœur des éco-quartiers» a pris peu a peu forme dans le cadre d’un partenariat avec le Club des Villes et Territoires...

Slide 6 : transition L\Jean de graeve ingénieur Supélec Option Informatique Tel : +33612905627...

Slide 6 : transition L\Profil et domaines d’expertise Mise en place de méthodologie Agile...
...

Slide 6 : transition L\Installation de l’environnement de travail 3
«niveau avancé». Vous pouvez les passer sans que cela impacte le déroulement de la formation ou les explorer si vous avez déjà atteint...

Slide 6 : transition L\Prestations offertes
«L’intérêt de la mise en place d’un pmo», «Quels outils choisir pour réussir son pilotage…» et également dans la revue de l’afai...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com