Rapport Projet 1A2A Bataille Spatiale IHM

Rapport Projet 1A-2A2e Année

Bataille Spatiale : Interface

Participants au projet : François Danguy, Lucas Boutrot, Tendry Rakotondramasy et Gabriel RiouTuteurs : Mr. Porcq et Mr. Delhoumi

Client : Mr. Bouillard

Bataille Spatiale:InterfaceRapport projet 1A-2A

1


2

Remerciements

Nous tenons tout d'abord à remercier notre client M. Bouillard pour avoir proposer ce projet qui nous a permis de travailler dans le monde du jeu vidéo.

Nous remercions nos tuteurs M.Porcq et M. Delhoumi pour nous avoir suivi jusqu'au bout et nous avoir apporté leurs conseils et leurs inquiétudes.

Nous remercions l'IUT d'Ifs, M. Jeanpierre et Mme. Jort pour avoir organiser ces projets tutorés.

Nous remercions nos professeurs d'expression-communication ainsi que nos professeurs de gestion de projet car nous ne serions pas arrivé aussi loin sans leurs conseils.

Nous remercions nos camarades du groupe Moteur pour avoir collaboré avec nous durant 1 an dans la réalisation de ce projet.


3

Sommaire

I. La construction du jeu

1. Les scènes

2. Le plateau

II . La création d'une ambiance.

1. Images et animations

2. Établissement des éléments nécessaires à l'interaction utilisateur/système

3 . Conception sonore

III. L'approche théorique et l'amélioration du projet

1. Modélisation UML

2. Amélioration / Refonte et développement de solutions


4

Introduction

Ce projet nous a été confié l'année dernière, le 28/01/2013, dans le cadre des

projets 1A-2A, projets pédagogiques organisé par l'IUT d'Ifs, antenne de l'IUT de

Caen. Notre client est M. Esteban Bouillard, étudiant d'Informatique de notre

promotion. Nos tuteurs sont M. Porcq et M. Delhoumi. Nous sommes un groupe de

quatre étudiants : François Danguy, Lucas Boutrot, Tendry Rakotondramasy et

Gabriel Riou. Nous travaillons sur l'IHM (Interface Homme-Machine) d'un jeu vidéo

en partenariat avec un autre groupe d'étudiants s'occupant du moteur de jeu, ce

groupe est constitué des étudiants : Cédric Mascart, Charles Duprey, Frédéric

Cosnefroy et Adrien Demoget. A noter que Tendry Rakotondramasy nous a rejoint

cette année, son ancien projet étant abandonné.

Ce rapport fera un léger rappel de la situation dans laquelle nous nous

trouvions l'année dernière,puis, nous rapporterons les avancées dans le projet par

rapport à l'année dernière, enfin nous donnerons notre ressenti sur ce projet.


5

Rappels de l'année dernière :

Étude

Mr. Bouillard nous ayant posé les conditions de réalisation du jeu, nous sommes entré en phase d'étude. Premièrement, il a fallu déterminer les règles du jeu, les deux groupes se sont réunis sur deux semaines pour fixer les règles. Il s'agissait d'un jeu de stratégie en tour par tour en 2D dans le thème de la science-fiction (deux bases spatiales s'affrontent grâce à des vaisseaux). Le jeu devait être jouable en local sur une même machine, avec l'accord de Mr. Bouillard nous avons décidé de rendre le jeu jouable en local sur deux machines distinctes et même en ligne.

Les règles fixées, les deux groupes ont du fixer les bases de développement du jeu : le langage utilisé, la bibliothèque, le moyen de partage de source et de communication et les conventions de codage. Nous avons choisi le C++ plutôt que le Java suite à une étude comparative entre les deux langages (étude trouvable dans le rapport de 1ere année). Nous avons procédé également à une étude entre plusieurs librairies graphiques pour enfin choisir la SFML (Simple FastMultimedia Library) comme librairie. Nous utilisons Git pour partager nos sources via l'interface GitHub qui permet de faciliter le partage de données. Nous communiquons principalement sur un groupe privé Facebook crée pour le projet.

Apprentissage et début des travaux

Une fois les bases conditionnées et les deux groupes séparées nous nous sommes lancer dans l'apprentissage du C++ qui n'est pas un langage que l'IUT nous enseigne. Les plate-formes d'apprentissage furent multiples : Openclassroom, developpez.net, … L'inclusion de la SFML dans le code s'est avérée assez simple car nous avions déjà pour la plupart utilisé cette librairie adaptée en Java lors d'un projet pédagogique. Il a fallu créer un répertoire Git commun pour que tout le monde puisse partager ses premières créations. Nous n'avons pas eu à suivre des cours pour Blender étant donné que Lucas en a déjà fait sa spécialité. Nous lui avons donc confié dès le début le rôle d'infographiste. A la fin de l'année, François a pris de l'avance sur la structuration de notre projet et a entamé les premières classes. Cette base faite nous avons pu nous adapté très facilement l'année suivante pour compléter le code.


6

I. La construction du jeu

1. Les scènes :

Tout d'abord définissons la scène dans le contexte de notre jeu.Une scène correspond à une vue au sein du programme, c'est à dire à ce que verra l'utilisateur à un

moment donné. L'ensemble des scènes construit la hiérarchie des vues du programme. Lorsque l'application se lance, une première scène est crée, c'est la scène mère. Par le clic sur un bouton, la scène mère engendre une nouvelle scène dite scène fille. Cette scène fille peut mémoriser son parent, cette mémoire se caractérise principalement par l'utilisation du bouton "retour". En effet, s'il n y avait pas de mémorisation, comment pourrions-nous sortir d'un menu d'options pour retourner dans le contexte de la partie ? L'action d'un bouton est donc principalement de faire naître une scène fille à la scène courante, puis de l'afficher.

En résumé, la scène se construit donc de cette manière :

- Elle possède une source sur laquelle l'utilisateur peut retourner (si l'application le permet).

- Elle possède des boutons qui permettent de naviguer dans l'application. Ces boutons font naître etaffichent une nouvelle scène qui n'hérite que de la destination des scènes précédentes.

Pour être plus explicite nous allons définir les principales scènes présentes dans le jeu :

- Le menu principal :

C'est la racine du jeu, le menu est la première scène que le joueur voit lorsqu'il lance l'application. Ilpermet d'établir les bases de la navigation au sien du jeu. Il est donc parent de toutes les scènes, et parent direct des scènes suivantes : le mode solo, le mode multijoueur, la création d'un serveur, les options, la sortie de l’application


7

- Le mode solo :

C'est la scène qui va permettre au joueur de créer une partie locale (sur l'adresse IP :127.0.0.1). Elle est fille du menu principal et fait naître la scène jeu si on clique sur "Lancer".

- Le mode multijoueur

Ce mode permet de rejoindre une partie déjà existante en ligne. On rentre l' adresse IP du serveur et le numéro du port utilisé. Si l'utilisateur rentre de bonnes données, il rejoint la partie. Il peut également retourner vers sa scène mère, le menu principal.

- La création d'un serveur

La scène de création d'un serveur permet de créer un serveur en rentrant l' adresse IP utilisée et le numéro du port. Si la création du serveur est confirmée, l'utilisateur rejoint la partie. L'utilisateur peut également retourner au menu.

- Les options

Cette scène permet de modifier les options du jeu (Rentrer les options.) Elle ne donne naissance à aucune autre scène et est accessible dans le menu principal et en pleine partie.

- Le jeu

C'est dans cette scène que le jeu se déroule, elle sera plus amplement expliquée dans la partie « plateau » de ce rapport.


8

Voici un diagramme de classes représentant la hiérarchie des scènes au niveau du code.Les deux scènes que nous avons mises en avant ci-avant ont été détaillées pour comprendre leur fonctionnement:


9

2. Le plateau :

Nous allons maintenant expliquer comment fonctionne l'affichage du plateau, de façon détaillée,ainsi que du lien avec le réseau, qui fait office de contrôleur dans notre cas.

Pour cela, cette partie se concentrera sur trois axes principaux :

A - Affichage du plateauB - Affichage des casesC - Correspondance avec le réseau

A – Affichage du plateau

Le plateau est la zone de jeu principale, constitué de cellules, contenant les différents éléments dujeu (Vaisseaux, Bâtiments, Événements).

Plateau de jeu

Les déplacements dans ce plateau peuvent se faire dans 8 directions : Gauche, droite, haut, bas,haut-gauche, haut-droit, bas-gauche, bas-droit. Pour que ces déplacements paraissent plusréalistes et clairs sur le plateau que nous affichions, nous avons donc décidé en commun accord dereprésenter les cases sous forme hexagonale.

Représenter les cases sous forme hexagonale peut paraître simple, mais un problème se pose toutde même : La position des cases. En effet, pour un plateau avec des cases carrées, l'algorithme estassez simple. Cependant, pour des cases hexagonales, cet algorithme ne marche plus.


10

Pour illustrer ces propos, voici un plateau avec des cases carrées :

Plateau de jeu carré

Et voici le code générant ce plateau :

Code générant un plateau de jeu carré

Le principe est assez simple, on positionne la case se trouvant à la position (i ; j) selon la taille descases. Ainsi, la case (2 ; 3) va se trouver à la position (2 * (20 + 5) : 3 * (20 + 5)). 20 étant la taille dela case, et 5 l'espacement entre chaque cases.


11

Reprenons le même algorithme, mais cette fois avec des cases hexagonales. Voici le plateaugénéré :

Plateau de jeu hexagonal

Le plateau ne s'affiche pas exactement comme on le voudrait. Déjà, c'est moins beau, et de plus,les déplacement en diagonale sont ambigus.

Il a donc fallu changer l'algorithme, et nous avons alors trouvé un algorithme permettant derésoudre ce problème, grâce à un des membres du groupe moteur, Cédric Mascart.

Voici le code précédemment utilisé, mais modifié pour un plateau hexagonal :

Code générant un plateau hexagonalLa principale différence se trouve lorsqu'on calcule la position en x. Cette fois, la case à la position(2 ; 3) ne sera pas placée à la position :

(2 * (20 + 5) : 3 * (20 + 5))

,mais à la position :

((2 * 2 + 3) * (20 + 5) * 3 / 5) : 3 * (20 + 5))


12

On voit que la position en y est utilisée pour calculer la position en x, et qu'une constanteapparaît : 3 / 5, qui est une constante calculée au préalable, et qui vaut pour tout les plateaux decette forme là.

Voici donc notre nouveau plateau :

Plateau de jeu hexagonal

Désormais notre plateau s'affiche exactement comme nous le voulons.

Ensuite, pour donner une impression de 3D, nous avons voulu représenter le plateau en 3Disométrique, c'est à dire de la 2D mais avec une perspective vue toujours du même angle, ce quiévite les éventuels calculs 3D, tout en donnant une impression de profondeur.

Les cases hexagonales se prêtant bien à la 3D isométrique, les seuls éléments qu'il fallait prendreen compte étaient alors les images, et c'est donc Lucas qui s'est occupé de donner aux images lebon angle.

La prochaine étape était alors la gestion d'une case.

B – Affichage des cases

Les cases sont, pour nous, des objets, que nous ajoutons au plateau, et qui se gèrentindividuellement.

Ainsi, chaque case sait sa position, et interroge le modèle de temps en temps pour savoir si elledoit changer son affichage.


13

Si la case du modèle correspondante contient un vaisseau, un bâtiment ou un événement, elle vaalors changer son affichage, et afficher l'image correspondante.

De même, si la case fait partie d'une des « zones » possibles (Parcourable, Attaquable,Constructible, etc), elle va changer sa couleur pour rendre l'affichage plus clair.

Et comme chaque case est traitée individuellement, si un clic est effectué, la case correspondanteva en être notifiée, et elle pourra alors agir en conséquence.

Un nouveau problème s'est alors posé : comment notifier le plateau qu'une case a étésélectionnée ?

Le problème a été assez rapidement résolu, il nous fallait juste, lors de l'appui d'une case, envoyerun message vers le plateau, pour qu'il puisse alors agir en conséquence. Les actions liées au casesne sont donc plus gérées dans les cases, mais les cases notifient le plateau, qui va alors agir enprenant en compte toutes les cases.

Les cases ne sont alors plus vraiment « pensantes ». Elles questionnent le modèle de temps entemps, modifient leur affichage en conséquence, et en cas de l'action d'un utilisateur, envoient unmessage au plateau, pour qu'il se charge d'effectuer l'action correspondante. Au cas où cetteaction modifierait la case, elle serait mise à jour au prochain questionnement.

Un autre soucis auquel nous avons eu à faire face, a été la couleur de la case. En effet, les caseschangent de couleur si elles font partie d'une zone parcourable, attaquable ou encoreconstructible.

Cependant, une case peut être à la fois déplaçable et constructible, et la zone déplaçable sesuperpose bien souvent à la zone attaquable. De plus, cela faisait 4 couleurs : Une pour une casenormale, une pour une case déplaçable, une pour une case attaquable, et une pour une caseconstructible, à celles-ci s'additionnant les couleurs pour les cases survolées/sélectionnées. Celaaurait alors fait assez fouillis, et nous avons donc réfléchir à une solution.

La solution a été de proposer à l'utilisateur d'afficher les zones de son choix, grâce à des cases àcocher, permettant d'activer l'affichage de chaque zone. Ainsi, l'utilisateur, si il le souhaite, peutafficher les trois zones en même temps, ou encore seulement une de ces zones, ou bien deux deces zones.


14

Sélection des zones

La dernière chose à gérer était donc la communication avec le réseau, autrement dit le contrôleur.

C – Correspondance avec le réseau

Notre jeu étant un jeu pouvant être joué en réseau, une des principales choses à mettre en placefut la gestion de ce réseau.

Niveau interface, nous voulions une gestion du réseau transparente, et non impactant surl'affichage.

Ainsi, nous avons choisi d'utiliser une gestion du réseau asynchrone. C'est à dire que lorsqu'uneaction doit être effectuée, nous envoyons une requête au réseau (Faisant office de contrôleur), quiva alors stocker cette requête, et la traiter parallèlement à l'affichage, en l'envoyant au serveur, quiva alors effectuer les actions nécessaires, puis modifier la copie du plateau que le client possède,pour refléter les changements effectués.

Notre affichage se mettant à jour selon le plateau côté client à chaque tour de boucle, c'est à diretout les 20 millisecondes en 60 images par seconde, les changements sont donc affichés presqueinstantanément, et il n'y a pas besoin d'attendre de réponse de la part du serveur.

Cela nous permet de mettre à jour l'affichage constamment et de garder 60 images par seconde,sans être bloqués par le réseau.


15

Voici un diagramme de séquence schématisant la communication avec le réseau :

Légende : Communication avec le réseau

Ici, l'affichage s'actualise constamment selon le plateau présent au niveau client, et lorsqu'unemodification doit être apportée, envoi un message au réseau, qui va alors transmettre au serveur,qui va a son tour envoyer une nouvelle copie du plateau au client. L'affichage étant actualiséconstamment, les prochains affichages seront donc fait selon le nouveau plateau client, et lesmodifications seront alors visibles.


16

II . La création d'une ambiance.

1. Images et animations :

Lucas a fait les images à l'aide des logiciels Blender et Photoshop. La création d'une même image se décompose en plusieurs étapes, dont certaines ont été automatisées par des scripts:

La configuration des éléments statiques entre deux modélisations différentes, comme les caméras, les lumières et tous les paramètres de rendu, est générée par un script python dans Blender.

Scène configurée

La modélisation est faite à la main. Cette étape consiste à déplacer les sommets (ou vertex) dans l'espace 3D, ces sommets sont reliés par des faces et forment un maillage (ou mesh) qui représente un objet. Dans le jeu, les objets sont les vaisseaux, les bâtiments, les événements et tous les éléments de l'interface.


17

A partir du maillage, on produit un patron en désignant les arrêtes sur lesquelles on souhaite découper le maillage. On pourra ensuite dessiner les texture directement sur le patron, etelles seront appliquées sur l'objet. Cette partie est appelée le dépliage UV, où U et V sont les coordonnées de la texture, X, Y, et Z étant déjà prise pour la vue à trois dimensions.

Ensuite, on prépare les textures correspondantes à l'objet avec Photoshop, puis on l'applique directement sur l'objet, en réglant les propriétés des matériaux: Brillant, matte, miroir, transparence...


18

Une fois l'objet fini, modélisation et textures, on effectue le rendu final de l'objet sous les différentes prises de vue. Comme il y a six vues différentes et quatre niveaux par objet, il serait long de faireles vingt-quatre rendus à la main (attendre la fin d'un rendu, changer de caméra, puis en lancer un autre). Un second script effectue donc tous les rendus automatiquement, et trie les images par niveau et par vue.


19

Pour finir, à partir des six images de chaque niveau, on crée un sprite automatiquement grâce à un script exécutable par Photoshop. On pourra par le code, avec la libraire SFML, sélectionner une partie du sprite à afficher.

Certain objet, particulièrement les événements comme les comètes ou les chargements, sont animés. Pour une animation, les étapes sont similaires à celles d'une image fixe. La différence est qu'il y aura une image pour chaque mouvement, à raison de vingt-cinq images par seconde. Ces images sont elles aussi placées dans un sprite par un script exécuté par Photoshop.


20

Classe animation:

L'animation récupère le sprite de l'animation. Ensuite, à chaque itération du jeu, quand l'affichage est rafraîchi, une méthode d'actualisation calcul le temps écoulé. Si ce temps est supérieur à un vingt-cinquième de seconde (pour qu'un humain perçoive une animation il faut au minimum vingt-quatre images par seconde), alors on passe à l'image suivante. Pour passer à l'image suivante, il suffit de décaler le carré de sélection du sprite de 480 pixels vers la droite, ou vers le bas si nous arrivons au bout de l'image. Un booléen gère s'il l'animation est active ou non, cela permet de la mettre en pause s'il y a besoin.

2. Établissement des éléments nécessaires à l'interaction utilisateur/système :

Le premier travail que nous avons eu à effectuer a été l'implémentation et l'amélioration des éléments nécessaires à l'interaction entre l'utilisateur et notre système.Il est cependant important de comprendre comment peut être implémentée une solution pour cette problématique, c'est pourquoi nous vous proposons de consulter le schéma suivant afin de comprendre quels sont les enjeux de cette problématique.

On voit bien que l'utilisateur, afin d’effectuer une action qui paraît simple, a besoin de passer par plusieurs étapes et plusieurs éléments intermédiaires.La bibliothèque que nous utilisons (SFML) n'offre pas comme certaines autres dans certains langages (Swing en JAVA par exemple), d'objets pré-générés et simples d'utilisation comme des boutons, des champs de textes ou encore des cases à cocher.

Il a donc fallu les développer nous même en respectant plusieurs contraintes telles que :- Une écriture et un fonctionnement simple, analogues aux objets fournis dans d'autres bibliothèques plus simple d'utilisation.- Une gestion de toutes les fonctionnalités que les éléments pourraient nous apporter.Afin de résoudre ce problème, nous avons choisi de développer des éléments génériques, servant


21

de base à tous les éléments complexes qui découleraient de ceux-ci.En clair en prenant l'exemple d'un élément cliquable, celui-ci est composé d'une image, et d'une zone le rendant cliquable, ces particularités sont communes pour plusieurs éléments tels les boutons ou les cases à cocher mais aussi les cases du plateau. Il fallait donc optimiser la structure pour que chaque élément puisse être traité de manière analogue et être développé de manière simple en utilisant au maximum les attributs communs entre lui et les autres éléments de l'interface.

Le diagramme de classe illustre bien cette notion mais nous vous proposons aussi de consulter leschéma associé montrant de manière moins "Informatique" le lien entre les éléments


22

Dans le cadre du respect de cette structuration, nous avons eu à implémenter la zone cliquable ainsi que les éléments en découlant tels que les boutons ou les case à cocher, toutefois nous avons eu a développer les barres et à retoucher aux informations affichées à l'écran.

Le problème principal des éléments graphiques était la communication et l’interprétation d'une action sur celui-ci par une scène dans le jeu. C'est pourquoi nous sommes passés par plusieurs versions que nous expliciterons dans une autre partie.

Globalement, pour développer un élément générique, il fallait le rendre cliquable, donc permettre a l'élément de savoir s'il contenait la position de la souris et aussi de lui permettre d’intercepter unclic sur la souris ou encore une entrée clavier. Il fallait aussi, dans le cas d'une case à cocher ou d'une zone de texte, "activer" l'élément en cliquant dessus.

Il était important de soigner le développement de ces éléments car ceux-ci seraient réutilisés de très nombreuses manière tout au sein du développement du projet, et ces éléments étaient aussi nécessaires pour afficher ne serait-ce que quelque chose à l'écran (comme les boutons des scènes ou encore les vaisseaux et les cases).

Toute ces fonctionnalités ont pu être implémentées grâce au temps que nous avons passé à bien structurer le code afin de le rendre extensible et réutilisable, et aussi grâce à la documentation dirigée par François.


23

3 . Conception sonore :

Le projet étant un jeu-vidéo, l'univers sonore était aussi un aspect important, autant que celui graphique, géré par Lucas.

Tendry : « Malheureusement, étant le seul à m'être occupé de cette partie et celle-ci ne représentant pas une importance majeure, par rapport au travail de projet étudiant, même si essentielle quand au produit final, je n'ai pas pu l'approfondir comme je le souhaitais. J'ai tout de même pu concevoir les bases de la gestion sonore. »

Tout d’abord le logiciel que j'ai utilisé pour la conception sonore est Fruity Loops (Version 9)

La conception de quelques pistes audio s'est révélée complexe quand au choix des instruments et à l'intensité de celles-ci. Il fallait rester dans le thème d'un jeu de "Bataille Spatiale", sachant qu'une musique typique d'un jeu-vidéo devait pouvoir se lire en boucle, sans gêner l'utilisateur mais en étant tout de même notoire.

Je me suis basé sur le choix d'instruments produisant un son plutôt mécanique, et se rapprochant plus du bruit blanc ou du brouillage radio. J'ai aussi choisi de rester dans une hauteur de son plutôtbasse afin de ne pas gêner l'utilisateur au cours d'une partie.

Afin d'obtenir un élément important mais nécessitant peu de travail afin de nous concentrer sur l'implémentation de l'interface, nous avons choisi un système de pistes audio par intensité.En clair la musique s'intensifiera au cours d'une partie, plus celle-ci dure, plus forte sera l'intensité et plus vive en sera la musique.


24

Il est intéressant de parler de cette notion car elle est gérée au sein du code via une classe.Elle possède juste un chronomètre changeant la musique jouée en fonction du temps écoulé.La classe permet aussi de gérer le lancement des sons au sein de l'application. L'utilité de cette classe permet d'éviter une gestion et un lien direct entre des scènes, ou des éléments et les ressources. La classe agit comme une sorte de contrôleur et possède des fonctions simples pour lancer et charger des sons ou musiques.


25

III. L'approche théorique et l'amélioration du projet

1. Modélisation UML :

La modélisation UML s'est faite en trois temps, sachant que l'on s'est principalement concentré surle diagramme de cas d'utilisations. Ce diagramme étant le pilier même de la communication entre le client / les personnes externes au projet et les développeurs, il était important de le soigner et de le développer de sorte à ce qu'il puisse guider la manière dont serait implémentées les fonctionnalités.

La première version du diagramme était trop orientée "développement", elle était travaillée et aboutie mais une personne externe au projet ne pouvait comprendre ce qu'il faisait ressortir. C'est pourquoi la deuxième version, réalisée à l'aide des tuteurs, a pu apporter des réponses plus concrètes à la question : "Que fait notre programme ?".


26

Cette même formation nous aura aussi permis de modéliser un autre diagramme, le diagramme deséquence, expliquant en détail les interactions et le fonctionnement de notre solution logicielle dans le cas du déplacement d'un vaisseau. Il était important de détailler ce passage car sa complexité ne pouvait pas être vulgarisée de manière effective au sein d'un diagramme de cas d'utilisation, et de plus ce cas étant assez générique au sein de notre application, la lecture de ce diagramme pouvait faciliter la compréhension de notre solution.


27

Ci-dessous notre diagramme de classes :


28

2. Amélioration / Refonte et développement de solutions

Avant même de pouvoir s'intéresser au développement des fonctionnalités de jeu, il a fallu améliorer les fonctionnalités d'affichage.

Il a fallu choisir la bonne taille et les bons procédés graphiques pour rendre les cases visibles et à lafois transparentes vis à vis du fond spatial que le jeu affiche.Il a aussi fallu gérer la vue qui déplace le plateau, afin de bloquer son défilement une fois arrivé au bout du plateau, ou encore implémenter une fonction de zoom, sachant que la résolution des images du jeu était suffisamment bonne pour le permettre.

Afin de pouvoir jouer une partie, il était essentiel de proposer un mécanisme intuitif, compréhensible et rapide au joueur pour qu'il puisse effectuer des actions.Les actions les plus importantes étant : l'attaque, le déplacement et la construction.Nous avons dans un premier temps développer des fonctionnalités permettant d'accomplir ces actions de manière confuse et brouillonne.

Elles consistaient à l'affichage de toutes les informations que nous avions implémentées telles que les portées relatives aux déplacements/attaques et constructions. Cela générait une surcharge de l'interface et finalement à un masquage d'information, par exemple lorsque la portée de déplacement était plus grande que la portée d'attaque, on ne pouvait plus consulter la portée d'attaque.Nous nous sommes occupé de la réorganisation et de la refonte de ces mécanismes afin des les rendre intuitifs et réalisables.

Nous avons d’abord changé la manière dont étaient affichés les informations du joueur en exploitant au maximum les élément génériques, tels que les barres.Il fallait montrer au joueur les niveaux de ses variables (Énergie, commandement etc.), et aussi lui indiquer quand ceux-ci étaient faible, sachant qu'au départ, ne sachant pas qu'il n'y avait aucune limite quand aux valeurs des variables, nous avions implémenté des barres de mesure acceptant une valeur maximale dont la progression de celle-ci coïnciderait avec le rapport de la valeur de la variable sur sa valeur maximale.

Après avoir appris qu'il n'y avait pas de limites sur les infos du joueur, nous nous sommes servi de la barre de mesure uniquement pour la santé des vaisseaux et bâtiments, et avons utilisé une barre de statut changeant de couleur en fonction de la valeur courante de la variable. Cela permettant donc d'indiquer clairement au joueur quand ses ressources sont basses et quand il peut au contraire en abuser pleinement tout en respectant une sorte de "convention" quand à l'utilisation de barres informatives sur les ressources dans un jeu de stratégie.

Ensuite nous nous sommes occupé de la gestion des portées qui était vraiment problématique. Nous avons choisi d'insérer les cases à cocher dans l'interface car elles étaient la solution adaptée à cette problématique.Elles permettent d'activer l'affichage de certaines informations et laissent le choix à l'utilisateur de pouvoir jouer à sa manière.


29

Par exemple s'il préfère lire les valeurs chiffrées des portées et compter les cases pour arriver à ses fins, rien ne l'oblige à cocher les valeurs de portées pour y parvenir.Il peut aussi toutes les afficher, malgré le fait qu'il aura une interface confuse, s'il est capable et préfère jouer dans ce contexte, notre interface lui permet.

Il fallait aussi s'occuper des boutons permettant de réaliser les actions.Nous sommes partis du principe que lorsqu'un utilisateur veut effectuer une action, il va d’abord sélectionner la case de destination de l'action sur le plateau.Ensuite en fonction de ce que possède la case, c'est à dire si elle est vide où s'il y a un vaisseau ou un bâtiment dessus, nous affichons le bouton correspondant à l'action pouvant être effectuée.En cas de succès il s'affiche alors une animation si il y a eu attaque ou sinon le vaisseau est déplacé immédiatement, consommant ainsi les ressources du joueur.

Le choix de la gestion des actions de la sorte découle de "conventions" sur les jeux de stratégie où il est souvent nécessaire de pré-sélectionner l'élément graphique acteur puis l'élément cible ou la zone cible du déplacement. Ce choix combiné aux options possibles de notre interface permettent à l'utilisateur de jouer et d'effectuer ces actions de nombreuses fois sans rencontrer de difficultés.


30

Ressentis :

François Danguy :

Ce projet m'a beaucoup apporté, sur bien des domaines, et je vais tenter de les lister ici.

Tout d'abord, j'ai appris ce qu'était le travail en équipe, ses avantages, et ses inconvénients, et ce fut unebonne expérience, m'apprenant que ce n'est pas une chose facile, mais qu'au final, cela reste beaucoupplus efficace.

Ensuite, j'ai pu apprendre un nouveau langage, le C++, ce qui, je pense, me servira beaucoup par la suite,puisqu'il nécessite une certaine rigueur, qu'il me manquait, et qu'il m'a fallu apprendre.

Ce projet a été également pour moi l'opportunité de découvrir plus en détail une librairie que je connaissaisdéjà, la SFML.

J'ai également appris à me servir d'outils externes, comme Cmake, rendant la compilation en C++énormément plus simple, ou encore à me servir d'Eclipse pour le C++, et à le configurer pour qu'il fasse ceque je souhaite qu'il fasse.

Enfin, j'ai pu améliorer ma connaissance des différents aspects de la gestion de projet : Diagrammes UML,Communication avec le client/les tuteurs, et bien d'autres choses.

Tendry Rakotondramazy :

Avant toute chose, je tiens à dire que l'année dernière, j'étais un membre d'un autre projet qui était le suivant : E-formation Legallais. Malheureusement, ce projet n'a pas pu être abouti et à dû être abandonné, c'est pourquoi j'ai choisi d'intégrer ce groupe au cours de ma deuxième année d'études.

J'ai principalement choisi ce projet et ce groupe en particulier car j'ai une préférence pour le développement d'interfaces logicielles, ainsi que pour l'algorithmie graphique. Qui plus est le projet contenait plusieurs points communs avec le précédent (Même langage, même problématiques au niveau del'interface et des événements).

Toutefois il m'a fallu un long temps d'adaptation au projet, à ses enjeux, et j'ai dû contextualiser et identifierles besoins ainsi que les solutions logicielles devant être apportées.

C'est pourquoi, afin de faciliter et d’accélérer mon insertion dans ce projet, j'ai souhaité m'occuper de la modélisation UML de notre projet, cela pouvait me permettre de comprendre le travail qui avait déjà était effectué et d'y apporter ma contribution.


31

Lucas Boutrot :

Malgré certains problèmes de communication et d'organisation, qui nous ont justement permis de serendre compte de ce qui pouvait arriver dans un tel projet, une bonne entente au sein du groupe interfaceet du groupe moteur nous a aussi permis de travailler dans de bonnes conditions, et d'avancer au mieuxavec une équipe de huit personnes. Les différences de niveau entre les membres on permis meilleursd'aider ceux qui avaient des problèmes ou des difficultés, ce qui a pu les faire progresser. Ce projet estintéressant car il nous a appris à nous servir de nouveaux outils et de nouveaux langages comme le C++.

Gabriel Riou :

Le projet 1A-2A m'a apporté plusieurs choses. Premièrement, j'ai pu travailler dans une équipe de huitpersonnes, cela permet de s'ouvrir sur les méthodes de travail et de communication que nous emploieronsdans le monde de l'entreprise. J'ai appris de nouveaux aspects techniques : la modélisation, le langage C++,la création d'images. Nous avons subit des échecs et nous avons toujours réussit à nous en sortir car nousavons établis une cohésion au sein de l'équipe qui nous a permis d'avancer lors des coups durs.


32

Conclusion

Pour conclure, la réalisation de ce projet a été un parcours mêlant découverte, entraide et difficultés tout en nous formant pour le monde professionnel.

Les groupes sont normalement formé de quatre personnes, nous avons travaillé à huit, nous pensions que cela simplifierait le travail mais au contraire cela l'à amplifié. C'est une bonne leçon qui nous aura permis de nous préparer aux contraintes de l'entreprise où les équipes de projet sont beaucoup plus important.

Nous avons pu découvrir les contraintes posées par un client ainsi que la pression portée par les tuteurs pour rendre le projet prêt dans les temps.

Le projet n'est bien sur pas terminé, il y a des choses qui manquent par rapport aux demandes du client mais nous avons essayé de notre côtéde rendre le projet accessible à quelqu'un qui voudrait le retravailler, l'achever ou même l’améliorer.


33

Webographie :Documentations et tutoriels C++ :

http://fr.cppreference.com/w/

http://stackoverflow.com/

http://www.cplusplus.com/reference/

Documentation et tutoriels blender et photoshop :

http://www.grafikart.fr/tutoriels/photoshop/automatiser-scripts-jsx-435


34

http://fr.cppreference.com/w/

http://www.grafikart.fr/tutoriels/photoshop/automatiser-scripts-jsx-435

http://www.cplusplus.com/reference/

http://stackoverflow.com/

Annexe 1 : Fiche de relecture du rapport de projet Bataille Spatiale : Interface.

Réalisé par le groupe Puissance4D1

Page de garde : Manque une image et peut être intégrer l’intitulé de la formation et un logo de l’IUT toussa toussa …Quelque souci de mise en page : Partie qui commence sur la fin d’une page…

Je ne suis pas persuadé par votre plan qui met l’analyse avant la réalisation, en effet on voit que ce n’est qu’à la troisième partie que vous parlez d’analyse et de diagramme UML. Cela correspond à votre projet mais commencer votre rapport par une analyse IHM (diagramme en mode Mister Brutus) serait intéressant.

Bonne explication du plateau, clair, précis.

B/ Affichage des cases : Manques une petite image (en enlever une du plateau pour la mettre danscette partie ?)

II) 1) Image et animationUn peu plus fournir l’explication pour l’animation. Pas facilement compréhensible.

II) 2)Problème de mise en page du diagramme de classe.

Etoffer la conclusion ? Et la webographie ?


35

Education

Rapport Projet 1A2A Bataille Spatiale IHM