Grace aux objectifs fixés par nos enseignants, nous sommes - je le pense - maintenant plus apte à nous confronter à ce genre d'objectifs. Tant au niveau personel qu'en tant que groupe.
Il va sans dire que comme pour tout projets, notre chemin a été semé d'embuches. En l'occurence, nous souhaitons faire part de l'abandon d'un de nos membre. Eddy Jiofak qui souhaite se réorienter.
\item{le VCS git pour garder une trace de l'avancement du projet. Avec comme remote une instance privée de gitea nous permettant de vérifier les MR/PR plus efficacement.}
\item{Une instance de DroneCI permettant de vérifier que le projet serait toujour compilable et que les tests ne seraient pas raté sans que nous nous en rendions compte.}
\item{Javafx, comme recommendé par nos enseignants.}
\item{Pieces les Niveaux sont stockées sous forme de matrice de booléen}
\item{Un parser de fichiers efficace et donnant des fichier légers.}
Pour la rétention des niveaux, plusieurs possibilités s'offraient à nous. Nous avons alors décidés d'accomplir une série d'objectifs propre à notre projet avec un parser de fichiers dédié.
\item{Les données du niveau seront encapsulées dans un header/footer pour laisser la possibilité d'enregistrer plus d'informations (images/musiques) dans un seul fichier dans le futur.}
\item[Header/Footer]{ Les données du niveau commencent par les 3 \emph{caractères} 'S', 'M', 'S' (ou \verb|0x534D53|) et se terminent par les 3 \emph{caractères} 'S', 'M', 'E' (ou \verb|0x534D45|)}
\item[Taille de carte]{ Le premier octet des données représente la largeur de la carte, le second sa hauteur.}
\item[Forme de la carte]{ Chaques cellules de la carte est représenté par un 1 ou un 0. le 1 représente un emplacement libre, un 0 une cellule vide.
La forme de la carte peut alors être répartie sur un nombre indéterminé d'octets.
Nous pouvons déterminer ce nombre grace à
$$\frac{\text{largeur}*\text{hauteur }(+1\text{ si multiple de }8)}{8}$$
en division entière.}
\item[Nombre de pièces]{ L'octet suivant l' (les) octet(s) qui forme(nt) la carte represente le nombre de pièces}
\item[Taille de la piece]{La taille est représentée sur un seul octet sous forme de nibble\footnote{https://en.wikipedia.org/wiki/Nibble}. La première partie du nibble est la largeur. La seconde partie du nibble est la hauteur }
\item[Forme de la pièce]{ Chaques cellules de la piece est représenté par un 1 ou un 0. la manière de le représenter et exactement la même que pour la forme de la carte }
\end{description}
Dans le cas où le fichier sauvegarde l'état de la partie, à la fin, et pour chaques pieces dans le même ordre que l'apparition des pièces:
\begin{description}
\item[Position de la pièce]{2 octets par pieces, 1 octet pour sa position en x et 1 octet pour sa position en y.
Dans le cas où la pièce est flotante (n'est pas placée dans la carte.), les octets contenant les caractères F puis L (0x464C) remplacent les coordonées}
En plus de ce parser, et dans le cas où ce premier parser ne serait pas capable de stocker certaine carte (par exemple si une piece mesure plus de 15x15).
Nous avons également implémenté un parser trés simple en utilisant l'interface \verb|Serialize| de java. Ce parser est implémenté et fonctionnel,
mais n'est pas utilisé dans le projet à l'heure actuelle.
ces deux parseurs implémentent l'interface \verb|FileParser| affin de pouvoir utiliser l'un où l'autre parser.
Finalement, La classe \verb|FileParserFactory| permet une utilisation simple des parseurs. Celle-ci contient deux fonction statique.
\begin{itemize}
\item{Map loadMapFromFile(File)}
permet de retourner la Map d'un fichier chargé.
\item{void saveFileFromMap(File, Map)}
permet de sauvegarder une map dans un fichier.
\end{itemize}
Dans le cas d'une sauvegarde ou d'un chargement, le parser est choisi en fonction de l'extension de fichier ('.level', '.slevel', .'serialized', '.sserialized').
L'avantage de ce system est que nous pouvons facilement ajouter d'autres parser de fichier dans le futurs.
