skizzle/docs/rapports/rapport-final/parts/develop.tex

\chapter{Développement}

\section{Moteur physique}

Cette partie du projet est basée sur l'algorithme du pré-rapport.
La première tâche fut l'organisation des classes, réalisée par Mattéo
à partir du diagramme de classe. Lors de cette première étape, le projet
était constitué de trois classes : la classe Engine, contenant le moteur
physique et gérant l'affichage du jeu, la classe Ball qui contenait les
propriétés de l'objet ball, ainsi que la classe Block qui contenait les
propriétés des blocs. Des classes furent rajoutées plus tard dans le
développement du projet afin de mieux répondre aux besoins d'affichage
et de moteur physique.

L'affichage fut géré par des fonctions draw() permettant de boucler
sur les différents objets afin de mettre à jour le dessin affiché en
fonction de leur position. Il fallut également gérer la caméra avec
l'objet view de la SFML, et l'adapter au redimensionnement de la
fenêtre. Enfin, pour un meilleur rendu graphique, nous avons chargé
et appliqué des textures aux objets (textures provisoires lors de
cette étape). Pour cela, nous avons décidé de créer la classe
ResourceManager afin de permettre de charger les ressources depuis
tout dossier où se trouverait l'exécutable.

Lors de l'implémentation des forces et des collisions, nous avons
rencontré quelques difficultés, notamment au niveau des collisions.
En effet, grâce aux tests du moteur dans différentes situations,
nous avons pu repérer des erreurs de collisions. Cela mena à la
création d'une nouvelle classe Object réunissant les balles et les
blocs dans un même tableau et définissant les propriétés communes
des objets. Nous avons donc passé plus de temps que prévu sur cette
partie du projet.

\section{Niveaux du jeu}

Tout d'abord, il fallut définir le format des fichiers de niveaux,
puis lire et écrire le format. Afin de pouvoir créer des niveaux
plus facilement, mais également permettre aux utilisateurs de jouer
à leurs propres niveaux, nous avons choisi de créer un éditeur de
niveau en mode graphique. Cela nous prit plus de temps que prévu,
c'est pourquoi il nous restait peu de temps pour la création de
niveaux. Nous avons donc réfléchi à des niveaux courts mais
demandant de la réflexion afin de les rendre intéressants
malgré le manque de temps.

\section{Interface du jeu}

Afin de mieux gérer l'affichage entre les menus, l'éditeur et les
niveaux, nous avons décidé de découper le jeu en états. Nous avons
créé une classe abstraite gérant tous ces états, ainsi qu'une
classe par état : Menu pour le menu principal, Rules pour les
règles du jeu, Editor pour l'éditeur de niveaux et Game pour
le jeu, ainsi qu'une classe abstraite Level pour gérer les niveaux.

Le menu principal se basait ainsi sur ce découpage. Chaque option
renvoyait à un état différent ou modifiait l'état du menu si cela
envoyait sur un autre menu (choix de niveaux).

Interface de l'éditeur ?

Menus pause, gagné, perdu ?

\section{Univers graphique}

Nous avons décidé d'ajouter des musiques au jeu afin de le rendre
plus vivant. Pour cela, nous avons fait appel à un étudiant de
l'IUT de Montpellier, Maxime \textsc{Petitjean}, pour aider Maëlle
à créer des musiques pour chaque niveau ainsi que pour le menu
à l'aide du logiciel Ableton.

Nous avons également décidé de créer nos propres textures pour un
rendu du jeu plus personnel. Après les dessins préalablement
réalisés par Maëlle sur papier, Rémi s'est chargé de les numériser
en repassant les contours pour créer une image vectorielle sur
Inkscape. Puis Maëlle les a colorées avec le même logiciel,
pendant que Rémi se chargeait des textures des blocs que nous
avions au préalable définies à l'oral en groupe.

Nous n'avons pas eu le temps d'implémenter le décor avant le rendu
du code, mais il est prévu que cela soit fait avant le passage à l'oral.