fix(docs): moved sagittarius-pdf into this repo

This commit is contained in:
Laureηt 2022-02-06 16:38:22 +01:00
parent 25f6b42b57
commit 753fa6e580
No known key found for this signature in database
GPG key ID: D88C6B294FD40994
80 changed files with 2576 additions and 0 deletions

11
docs/.gitignore vendored Normal file
View file

@ -0,0 +1,11 @@
*.aux
*.fdb_latexmk
*.fls
*.log
*.out
*.synctex.gz
*.toc
*.synctex(busy)
*_minted*/
.vscode

5
docs/README.md Normal file
View file

@ -0,0 +1,5 @@
Utilisez l'extension vscode suivante pour faciliter le travail : https://marketplace.visualstudio.com/items?itemName=James-Yu.latex-workshop
(évidemment il faut avoir latex installé sur sa machine)
lien vers l'uml : https://lucid.app/lucidchart/9f529a89-f295-48a7-b7eb-d387ade0b86e/edit

BIN
docs/images/Lancement.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 179 KiB

BIN
docs/images/Menu_Tom.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 229 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

BIN
docs/images/Parametres.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/images/Tir.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 43 KiB

BIN
docs/images/UML_libGDX.jpeg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 296 KiB

BIN
docs/images/UML_model.jpeg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 341 KiB

BIN
docs/images/Visee.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 43 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

BIN
docs/images/chess.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

BIN
docs/images/inp_n7.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 63 KiB

BIN
docs/images/logisim.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 53 KiB

BIN
docs/images/menuConfig.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 72 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 72 KiB

BIN
docs/images/menuPause.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 90 KiB

BIN
docs/images/menuPerso.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 73 KiB

BIN
docs/images/pacman.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 238 KiB

BIN
docs/images/sagittarius.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 207 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 151 KiB

BIN
docs/images/uml_Modèle.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 190 KiB

BIN
docs/images/uml_vue.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 170 KiB

Binary file not shown.

View file

@ -0,0 +1,193 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{color}
\usepackage[french]{babel}
\usepackage[hidelinks]{hyperref}
\usepackage{mathtools}
\usepackage[nottoc, numbib]{tocbibind}
\usepackage{lipsum}
\usepackage{minted}
\newminted{bash}{numbersep=6pt}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\graphicspath{
{../images/}
}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Manuel Utilisateur \\
Itération n°1
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1}
\vspace{2mm} \\
Fainsin Laurent \\
Guillemin Johan \\
Guillotin Damien \\
Heurtebise Tom \\
Jourdan Pierre-eliot \\
Kirupananthan Nadesan
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
\tableofcontents
\newpage
\section{Présentation}
% inclure photo ici
Sagittarius est un jeu type arcade tour par tour pouvant être joué de 2 à 5 joueurs. Le but d'un joueur est d'éliminer ses adversaires grâce à un arc, des flèches et, la mécanique principale du jeu, la gravité !
% écrire plus ?
\section{Lancer l'application}
L'application est fournie dans un fichier .jar, celui contient l'ensemble des éléments nécéssaires au bon fonctionnement du jeu vidéo. Avant de pouvoir éxecuter l'application il vous faut d'abord vérifier dans un premier temps que Java soit installé sur votre ordinateur. Ensuite pour lancer le jeu, il vous faut entrer dans un terminal:
\begin{center}
\textit{java -jar sagittarius.jar}
\end{center}
\section{Menu principal}
Ce menu est le menu principal qui s'affiche lors du lancement du jeu. Depuis celui-ci l'utilisateur pourra choisir de lancer une partie rapide (bouton play), d'accéder aux paramètres généraux du jeu, de configurer une partie, de voir les crédits du jeu ou bien de quitter l'application. \\
Pour cette itération seulement les sous-menus partie rapide (play), paramètres généraux (settings) et quitter (exit) ont été développés.
\begin{figure}[h]
\centering
\includegraphics[width=18cm]{Menu_principal.png}
\caption{Menu Principal de l'itération 1}
\end{figure}
\begin{figure}[h]
\centering
\includegraphics[width=14cm]{MenuPrincipalFinal.png}
\caption{Menu Principal esperé pour la fin du projet}
\end{figure}
\section{Configuration d'une partie}
\textit{(Cette option n'apparaît pas encore pour cette itération et est encore en cours d'implémentation)}
Depuis ce menu, les joueurs peuvent choisir les différentes caractéristiques de la partie et ainsi modifier la manière de jouer.
Diverses sections devraient apparaitres au cours des prochaines versions, regroupées dans plusieurs catégories:
\begin{itemize}
\item Une catégorie Mode de jeu (qui incluera un mode solo si le temps nous permet de le développer) dans laquelle le joueur pourra changer le nombre de joueurs, le nombre d'équipe etc...
\item Une catégorie Joueurs dans laquelle l'utilisateur pourra changer le nom et la couleur des joueurs.
\end{itemize}
D'autres paramètres pourront aussi êtres changés, tel que la constante de gravitation G, le temps de vie maximale d'une flèche, la taille de la carte, la densité de planètes par joueur dans l'univers, le nombre de lunes maximales...
\begin{figure}[h]
\centering
\includegraphics[width=14cm]{menuConfig.png}
\caption{Paramètres de configuration d'une partie, menu espéré}
\end{figure}
\newpage
\section{Paramètres généraux}
\textit{(Cette option n'apparaît pas encore pour cette itération et est encore en cours d'implémentation)}
Depuis ce menu, l'utilisateur pourra choisir de changer la résolution de la fenêtre de jeu, le nombre d'images par secondes souhaités (FPS), la quantité de détails présent à l'écran (décors et particules), le volume sonore de la musique et des effets... \\
Le joueur aura aussi la possibilité de changer ses contrôles, voire même d'utiliser une manette au lieu du clavier et de la souris (si le temps le permet). \\
En l'état actuel le joueur peut seulement activer le mode debug et changer la constante gravitationnelle G.
\begin{figure}[h]
\centering
\includegraphics[width=14cm]{Parametres.png}
\caption{Menu paramètres actuel}
\end{figure}
\begin{figure}[h]
\centering
\includegraphics[width=14cm]{menuParamGeneraux.png}
\caption{Menu paramètres esperé}
\end{figure}
\newpage
\section{Partie}
\textit{(En l'état actuel des choses les joueurs sont représentés par des rectangles simples, les forces d'attraction sont affichées, il n'y a aucun arrière plan, les flèches sont des traits et les planètes des ronds. Tout ceci devrait évoluer...)}
Une fois la partie lancée, l'utilisateur tombe sur l'écran ci-dessous.
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{Lancement.png}
\caption{Exemple d'écran au lancement d'une partie (version debug)}
\end{figure}
Ce joueur peut alors commencer la partie. Il peut choisir de se déplacer en suivant le contour de la planète ou de tirer. Pour se déplacer il utilise les flèches du clavier (ou d'autres boutons de son choix si les controles ont été personnalisés).
Une fois bien positionné, pour tirer le joueur clique sur un endroit de l'écran et maintient le clic pour ainsi choisir la direction et la puissance de la flèche (cf figure pour un exemple de l'affichage actuel).
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{Visee.png}
\caption{Exemple du système de visée actuel}
\end{figure}
En relachant le clic de la souris la flèche est lancée, celle-ci à une durée de vie de 20 secondes. Si au delà de ce temps la flèche n'a pas touché de joueur ou d'objets celestes, elle disparait. Si la flèche touche un joueur, celui-ci perd un point de vie, une fois le compteur de vie (non affiché pour le moment) d'un joueur à zéro, celui-ci meurt. Au cours d'un tour un joueur ne peut tirer qu'une flèche, après cela c'est au tour du joueur suivant.
Vous avez ci-dessous un exemple de tir par un joueur.
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{Tir.png}
\caption{Exemple d'un tir de joueur (version debug)}
\end{figure}
\section{Menu pause}
\textit{(Cette option n'apparaît pas encore pour cette itération et est encore en cours d'implémentation)}
Lors d'une partie, si l'utilisateur appuie sur la touche "Échap", un menu apparaitra au dessus de l'écran de la partie. Depuis ce menu vous avez le choix de retourner au jeu, de sauvegarde la partie, d'aller dans le menu des paramètres généraux, de quitter la partie.
\begin{figure}[H]
\centering
\includegraphics[width=16cm]{menuPause.png}
\caption{Menu pause espéré}
\end{figure}
\end{document}

Binary file not shown.

Binary file not shown.

View file

@ -0,0 +1,67 @@
\documentclass[a4paper, 12pt]{memoir}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsfonts}
\usepackage{color}
\usepackage[french]{babel}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{
\uline{\phantom{#1}}
\llap{\contour{white}{#1}}
}
\graphicspath{
{../images/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Rapport Individuel \\
Itération n°1
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1}
\vspace{2mm} \\
Fainsin Laurent \\
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
\begin{vplace}
Lors de cette première itération je me suis personnellement forcé à étudier la librairie libGDX, pour pouvoir la comprendre, produire quelques exemples de test, et ensuite en informer mes camarades pour que l'on puisse mettre en oeuvre le planning que nous nous étions fixé (voir l'UML en rapport avec libGDX dans le rapport). Suite à différents imprévus nous avons pris du retard dans le développement de cette itération, mais nous avons tout de même produit un exemple fonctionnel.
Lors de cette itération j'étais chargé d'utiliser le modèle physique, créé par les autres élèves, pour l'afficher via libGDX. Je n'ai pas réussi à totalement séparer la vue et le modèle dans des fichiers bien distincts, puisque les méthodes d'affichage (draw, drawDebug) utilisées par libGDX se situent dans les mêmes fichiers qui codent le modèle. Il nous est donc par exemple compliqué pour l'instant de totalement remplacer libGDX par Swing si l'on le souhaite, sans modification majeure du code.
\end{vplace}
\end{document}

Binary file not shown.

Binary file not shown.

Binary file not shown.

View file

@ -0,0 +1,144 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{color}
\usepackage[french]{babel}
\usepackage[hidelinks]{hyperref}
\usepackage{mathtools}
\usepackage[nottoc, numbib]{tocbibind}
\usepackage{lipsum}
\usepackage{lscape}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\graphicspath{
{../images/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Rapport général \\
Itération n°1
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1}
\vspace{2mm} \\
Fainsin Laurent \\
Guillemin Johan \\
Guillotin Damien \\
Heurtebise Tom \\
Jourdan Pierre-eliot \\
Kirupananthan Nadesan
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
%\setcounter{tocdepth}{1}
\tableofcontents
\newpage
\section{Rappel du projet}
Sagittarius est un jeu type arcade tour par tour pouvant être joué de 2 à 5 joueurs. Le but d'un joueur est d'éliminer ses adversaires grâce à un arc, des flèches et, la mécanique principale du jeu, la gravité !
\\Ce projet a pour but de recréer ce jeu existant tout en l'améliorant par divers ajouts/fonctionnalités. Nous n'en revendiquons pas la propriété intelectuelle même si nous n'avons pas consulté le code source pour élaborer notre projet !
\section{Principales fonctionnalités}
La fonctionnalité principale de l'application est de pouvoir jouer à une ou plusieurs parties (sans remdémarrer le jeu).
Par le biais d'un menu dédié, l'utilisateur a aussi la possibilité de pousser la personnalisation d'une partie tel que les caractéristiques visuelles et physiques. Ceci inclus la sélection par les joueurs de la couleur de leur archer et leur noms. Notons au passage que si deux joueurs choisissent la même couleur, ceux-si sont considérés comme dans la même équipe.
Un autre menu permet de mettre la partie qui était en cours en pause. L'utilisateur peut alors au choix reprendre, sauvegarder la partie ou alors quitter pour revenir au menu principal.
Enfin un dernier menu permet de régler les paramètres généraux du jeu tel que la résolution, le nombre d'image par secondes, le vsync, le niveau de détails...
\section{Gestion Agile du projet avec Vision de l'application}
Durant les séances dédiées à l'applicaton des méthodes de projet Agile nous avons pu découper notre application en fonctionnalités elle même redécoupées et ainsi de suite jusqu'à obtenir des "Users stories". Sur la page suivante vous pourrez retrouver le découpage que nous avons effectué.
\newpage
\begin{landscape}
\begin{figure}[h]
\centering
\includegraphics[width=28cm]{vision1.png}
\caption{Découpage de la vision du projet jusqu'au Users Stories (voir Méthodes Agiles pour le détail des termes)}
\end{figure}
\end{landscape}
\newpage
Pour la première itération nous avons du poser les bases du projet en nous attaquant aux Users stories "Viser", "Tirer" et "Se déplacer". Nous avons aussi traiter des aspects lié à la génération de l'environnement du jeu (ce qui en soit ne fait pas partie des users stories). Pour le moment les points d'efforts nous semblent plutôt bien réparti puisque nous sommes parvenus à terminer ces deux premières Users Stories avec un affichage relativement sommaire mais un affichage tout de même et la possibilité de jouer. Par la suite nous allons nous attaquer à améliorer cet affichage et géré au mieux la partie conifguration de partie dans laquelle nous avons diverses users stories.
\section{Découpage de lapplication et application du MVC (Modèle Vue Contrôleur)}
Le jeu est actuellement divisé en deux parties, le modèle physique du jeu, et la partie visuelle du jeu. Nous avons fait ce choix pour rendre le jeu le plus indépendant possible d'une interface graphique. Ainsi, bien que nous utilisions la bibliothèque spécialisée dans la création de jeux vidéo 2D libGDX, il est possible de l'interchanger avec une bibliothèque plus traditionnelle telle que Swing. Notons toutefois qu'après discussion entre nous il nous a paru relativement difficile de séparer complètement la partie modèle physique du jeu de libGDX qui apport des fonctionnalités permettant d'améliorer les performances et qui offre un panel de possibilités plus large que si nous réécrivions toutes ces méthodes.
\\ Pour ce qui est du respect strict du MVC nous avons eu beaucoup de difficultés à séparer le moteur du Jeu de sa vue et nous n'y sommes pas parvenu de façon totale. Cependant dans la mesure ou il s'agit d'un jeu dont la vocation n'est pas de changer d'interface graphique souvent cela ne nous semble pas complètement abberrant non plus.
\\ ENfin notons que la partie contrôleur du jeu est celle qui est permise par libGDX, elle ressemble très fortement à celle de Swing mais offre plus de possibilités.
\newpage
\section{Diagrammes de classe}
Voici des diagrammes UML pour vous aider lors de la lecture du code.
\begin{center}
\includegraphics[width=17.25cm]{UML_model.jpeg}
\end{center}
\begin{center}
\includegraphics[width=17.25cm]{UML_libGDX.jpeg}
\end{center}
\newpage
\section{Choix de conception et réalisation}
Un choix de conception important que nous avons du réalisé et qui ne respecte pas bien le principe du MVC et le fait que nous ayons inclus des méthodes draw dans la classe entité. Ceci est dû essentiellement à l'utilisation de la librairie dont nous avons déjà fait mention et dont vous pourrez retrouver le principe dans le diagramme UML ci-dessus. Notons toutefois que cette méthode n'impacte pas ce que le modèle physique réalise, le MVC est donc en partie respecté.
\\ Un point qui peut être délicat est la façon dont nous calculons la trajectoire d'une flèche. Nous avons d'abord pensé à générer une carte comportant les champs d'attraction mais cela nous a paru peu efficace en terme d'implémentation, de temps de calcul et de stockage (puisque recalculer cette carte si on y inclue des objets mobiles tels que des lunes est très lourd). Après quelques recherches nous avons trouvé une méthode d'intégration physique qui permet de déterminer la trajectoire de particules qui sont soumises à différentes forces. Nous nous sommes appuyés sur diverses ressources dont celle-ci : https://www.compphy.com/verlet-algorithm/.
\section{Points à améliorer pour la prochaine itération}
Lors de la réalisation de la deuxième version sur Swing que nous implémentant à titre de démonstration seulement, nous nous sommes aperçus de plusieurs défauts de conception. Le premier a déjà été évoqué, il s'agit du lien trop fort entre vue et modèle qui est induit par la bibliothèque déjà mentionnée.
\\ Un autre défaut de cinception est la trop forte encapsulation des paramètres de partie. Par exemple la constante G se trouve dans la classe Game alors que le TTL des flèches se trouve dans la classe flèche. Même si cela nous a paru logique au moment de l'élaboration du diagramme UML, il s'avère que modifier ces paramètres depuis un menu relève du casse-tête.
\section{Explications supplémentaires}
Nous avons préféré utiliser certains outils comme Visual Code et GitLab qui permettent un travail collaboratif plus facile qu'Eclipse et svn. Nous allons continuer à procéder de la sorte.
\end{document}

View file

@ -0,0 +1,269 @@
<html>
<style>
table {
border-collapse: separate;
border-spacing: .5em .5em;
}
th, td {
border: 1px solid black;
padding: 1em .5em ;
position: relative;
text-align: center;
}
span.valeur {
position: absolute;
left: 0;
top: 0;
background: #a5d6a7;
}
span.effort {
position: absolute;
right: 0;
top: 0;
background: #90caf9;
}
</style>
<table>
<thead>
<tr>
<th colspan="23">
Sagittarius : jeu d'arcade tour par tour
<span class="valeur">valeur</span>
<span class="effort">effort</span>
</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="15">
Partie
<span class="valeur">2500</span>
</td>
<td colspan="8">
Paramètres
<span class="valeur">500</span>
</td>
</tr>
<tr>
<td colspan="12">
Configurer Partie
<span class="valeur">1000</span>
</td>
<td colspan="3">
Jouer
<span class="valeur">1500</span>
</td>
<td colspan="4">
Graphiques
<span class="valeur">200</span>
</td>
<td colspan="2">
Audio
<span class="valeur">150</span>
</td>
<td colspan="2">
Contrôles
<span class="valeur">150</span>
</td>
</tr>
<tr>
<td colspan="5">
Mode de jeu
<span class="valeur">400</span>
</td>
<td colspan="2">
Joueurs
<span class="valeur">300</span>
</td>
<td colspan="5">
Environnement
<span class="valeur">300</span>
</td>
<td colspan="2">
Tirer une flèche
<span class="valeur">900</span>
</td>
<td>
Se déplacer
<span class="valeur">600</span>
<span class="effort">2</span>
</td>
<td colspan="2">
Écran
<span class="valeur">100</span>
</td>
<td colspan="2">
Niveau de détails
<span class="valeur">100</span>
</td>
<td>
Musique
<span class="valeur">75</span>
<span class="effort">1</span>
</td>
<td>
Bruitages
<span class="valeur">75</span>
<span class="effort">1</span>
</td>
<td>
Sensibilité
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Raccourcis
<span class="valeur">100</span>
<span class="effort">3</span>
</td>
</tr>
<tr>
<td colspan="3">
Multijoueur
<span class="valeur">300</span>
</td>
<td colspan="2">
Solo
<span class="valeur">100</span>
</td>
<td>
Nom
<span class="valeur">100</span>
<span class="effort">2</span>
</td>
<td>
Couleur
<span class="valeur">200</span>
<span class="effort">2</span>
</td>
<td colspan="3">
Planètes
<span class="valeur">220</span>
</td>
<td colspan="2">
Autres
<span class="valeur">80</span>
</td>
<td>
Viser
<span class="valeur">500</span>
<span class="effort">3</span>
</td>
<td>
Puissance
<span class="valeur">400</span>
<span class="effort">2</span>
</td>
<td style="visibility: hidden;"></td>
<td>
FPS
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Résolution
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Décors
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Particules
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
</tr>
<tr>
<td>
Nombre de joueurs
<span class="valeur">120</span>
<span class="effort">2</span>
</td>
<td>
Nombre d'équipes
<span class="valeur">120</span>
<span class="effort">2</span>
</td>
<td>
Tir alliés
<span class="valeur">60</span>
<span class="effort">1</span>
</td>
<td>
Timer
<span class="valeur">50</span>
<span class="effort">1</span>
</td>
<td>
Objectifs
<span class="valeur">50</span>
<span class="effort">5</span>
</td>
<td colspan="2" style="visibility: hidden;"></td>
<td>
Densité
<span class="valeur">80</span>
<span class="effort">1</span>
</td>
<td>
Taille
<span class="valeur">80</span>
<span class="effort">2</span>
</td>
<td>
Lunes
<span class="valeur">60</span>
<span class="effort">3</span>
</td>
<td>
Astérodïdes
<span class="valeur">40</span>
<span class="effort">5</span>
</td>
<td>
Gadgets
<span class="valeur">40</span>
<span class="effort">5</span>
</td>
</tr>
</tbody>
</table>
</html>

BIN
docs/iteration1/vision1.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 61 KiB

View file

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 81 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 110 KiB

View file

@ -0,0 +1,193 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{color}
\usepackage[french]{babel}
\usepackage[hidelinks]{hyperref}
\usepackage{mathtools}
\usepackage[nottoc, numbib]{tocbibind}
\usepackage{lipsum}
\usepackage{minted}
\newminted{bash}{numbersep=6pt}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\graphicspath{
{../images/}
{../screenshots/}
}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Manuel Utilisateur \\
Itération n°2
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1}
\vspace{2mm} \\
Fainsin Laurent \\
Guillemin Johan \\
Guillotin Damien \\
Heurtebise Tom \\
Jourdan Pierre-eliot \\
Kirupananthan Nadesan
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
\tableofcontents
\newpage
\section{Présentation}
% inclure photo ici
Sagittarius est un jeu type arcade tour par tour pouvant être joué de 2 à 5 joueurs. Le but d'un joueur est d'éliminer ses adversaires grâce à un arc, des flèches et, la mécanique principale du jeu, la gravité !
% écrire plus ?
\section{Lancer l'application}
L'application est fournie dans un fichier .jar, celui contient l'ensemble des éléments nécéssaires au bon fonctionnement du jeu vidéo. Avant de pouvoir éxecuter l'application il vous faut d'abord vérifier dans un premier temps que Java (préciser version?) soit installé sur votre ordinateur. Ensuite pour lancer le jeu, il vous faut entrer dans un terminal:\\
\begin{center}
\textit{java -jar sagittarius.jar}
\end{center}
\textbf{Le jeu est basé sur openJDK 8 et libGDX, pour le lancer il vous faut la version correspondante du JDK\\
Nous vous recommandons aussi de le lancer avec Visual Studio Code en pressant Ctrl + F5}
\section{Menu principal}
Ce menu est le menu principal qui s'affiche lors du lancement du jeu. Depuis celui-ci l'utilisateur pourra choisir de lancer une partie rapide (bouton play), d'accéder aux paramètres généraux du jeu, de configurer une partie, de voir les crédits du jeu ou bien de quitter l'application.
\\Pour cette itération tous les menus sont proposés SAUF le mnu de configuration de parties. Notez aussi que les crédits sont vides pour le moment.
\begin{figure}[H]
\centering
\includegraphics[width=20cm]{MenuPrincipal.png}
\caption{Menu Principal de l'itération 2}
\end{figure}
\section{Configuration d'une partie}
\textit{(Cette option n'apparaît pas encore pour cette itération et est encore en cours d'implémentation)}
Depuis ce menu, les joueurs peuvent choisir les différentes caractéristiques de la partie et ainsi modifier la manière de jouer.
Diverses sections devraient apparaître au cours des prochaines versions regroupées dans plusieurs catégories.
\\ Une catégorie Mode de jeu (qui incluera un mode solo si le temps nous permet de le développer) dans laquelle le joueur pourra changer le nombre de joueurs, le nombre d'équipe etc...
\\ Une catégorie Joueurs dans laquelle l'utilisateur pourra changer le nom/ la couleur de chaque joueur. Enfin il devrait y avoir une catégorie poussant les paramètres de la partie. En effet, les joueurs pourront changer la constante de gravitation G, changer le temps de vie maximale d'une flèche, changer la taille de la carte, la densité de planètes par joueur dans l'univers, le nombre de lunes ...
\begin{figure}[h]
\centering
\includegraphics[width=14cm]{menuConfig.png}
\caption{Paramètres de configuration d'une partie, menu espéré}
\end{figure}
\newpage
\section{Paramètres généraux}
Depuis ce menu, l'utilisateur pourra choisir de changer la résolution de la fenêtre de jeu , le nombre d'images par secondes souhaité (FPS), la quantité de détails présent à l'écran (décor et particules), le volume sonore de la musique et des effets. Le joueur aura aussi la possibilité de changer les contrôles pour jouer.
\\ En l'état actuel le joueur peut seulement lancer le mode debug, changer la constante gravitationnelle G et intervenir sur les paramètres audios.
\begin{figure}[h]
\centering
\includegraphics[width=14cm]{menu_parametre.png}
\caption{Menu paramètres actuel}
\end{figure}
\newpage
\section{Partie}
Une fois la partie lancée, si l'utilisateur lance le mode debug, il tombe sur l'écran ci dessous.
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{mode_debug.png}
\caption{Exemple d'ecran au lancement d'une partie (version debug)}
\end{figure}
Dans ce mode il peut alors observer toutes les trajectoires ainsi que les forces d'attraction comme ci-dessous :
\begin{figure}[H]
\centering
\includegraphics[width=16cm]{trajectoire_debug.png}
\caption{Exemple d''un tir (version debug)}
\end{figure}
Dans une partie normale, l'utilisateur tombe plutôt sur un écran qui ressemble à celui-ci (si on excepte les flèches plantées dans la planète) :
\begin{figure}[H]
\centering
\includegraphics[width=16cm]{fleche_plantee.png}
\caption{Exemple d'un lancement normal de partie}
\end{figure}
En dézoomant (avec les flèches directionnelles haut et bas) il peut alors jouer avec la caméra et se rendre compte de la position de ses ennemis. Evidemment, s'agissant d'un jeu au tour par tour, chaque participant choisit une couleur et joue uniquement le personnage correspondant. \\
Ainsi dans notre exemple, le joueur jaune commence. Il peut choisir de se déplacer en suivant le contour de la planète ou de tirer. Pour se déplacer il utilise les flèches du clavier.Une fois bien positionné, pour tirer, le joueur clique sur un endroit de l'écran et maintient le clic pour choisir la direction et la puissance de la flèche. En mode de jeu normal cette information n'est pas affichée pour le moment. Elle le sera dans la prochaine version.\\
En relachant le clic de la souris la flèche est lancée, celle-ci à une durée de vie de 20 secondes. Si au delà de ce temps la flèche n'a pas touché de joueur ou d'objets celeste elle disparait. Si la flèche touche un joueur, celui-ci perd un point de vie, une fois le compteur de vie (non affiché et égal à 1 pour le moment) d'un joueur à zéro, celui-ci meurt. Au cours d'un tour un joueur ne peut tirer qu'une flèche, après cela c'est au tour du joueur suivant.
Vous avez ci-dessous un exemple de tir par un joueur.
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{Tir_fleche.png}
\caption{Exemple d'un tir de joueur}
\end{figure}
\section{Menu pause}
Lors d'une partie, si l'utilisateur appuie sur la touche "Échap", un menu apparait. Depuis ce menu, le joueur peut retourner au jeu, changer quelques paramètres généraux ou revenir au menu princiapl.
\begin{figure}[H]
\centering
\includegraphics[width=16cm]{menu_pause.png}
\caption{Menu pause }
\end{figure}
\end{document}

Binary file not shown.

Binary file not shown.

Binary file not shown.

View file

@ -0,0 +1,70 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsfonts}
\usepackage{color}
\usepackage[french]{babel}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\graphicspath{
{../images/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Rapport Individuel \\
Itération n°2
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1} \\
\vspace{2mm}
Fainsin Laurent
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
\hspace{0pt}
\vfill
Lors de cette deuxième itération, je me suis penché sur la gestion de la caméra dans le jeu. J'ai donc réussi à créer un système assez simple qui permet à la caméra de suivre un joueur ou bien une flèche. De même il est désormais possible de varier le zoom de la caméra, permettant ainsi d'observer une plus grande partie de la carte si nécessaire.
De nombreuses petites améliorations ont aussi été appliquées au modèle physique. Par exemple il est désormais possible d'annuler le tir d'une flèche, les planètes tournent sur elles-mêmes, les flèches ne tuent pas instantanément leur tireur...
\vfill
\hspace{0pt}
\end{document}

Binary file not shown.

Binary file not shown.

View file

@ -0,0 +1,166 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{float}
\usepackage{color}
\usepackage[french]{babel}
\usepackage[hidelinks]{hyperref}
\usepackage{mathtools}
\usepackage[nottoc, numbib]{tocbibind}
\usepackage{lipsum}
\usepackage{lscape}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\graphicspath{
{../images/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Rapport général \\
Itération n°é
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1}
\vspace{2mm} \\
Fainsin Laurent \\
Guillemin Johan \\
Guillotin Damien \\
Heurtebise Tom \\
Jourdan Pierre-eliot \\
Kirupananthan Nadesan
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
%\setcounter{tocdepth}{1}
\tableofcontents
\newpage
\section{Rappel du projet}
\textit{cette section est identique au premier rapport}
\\
Sagittarius est un jeu type arcade tour par tour pouvant être joué de 2 à 5 joueurs. Le but d'un joueur est d'éliminer ses adversaires grâce à un arc, des flèches et, la mécanique principale du jeu, la gravité !
\\Ce projet a pour but de recréer ce jeu existant tout en l'améliorant par divers ajouts/fonctionnalités. Nous n'en revendiquons pas la propriété intellectuelle et nous n'avons pas consulté le code source pour élaborer notre projet !
\section{Principales fonctionnalités}
\textit{cette section est identique au premier rapport}
\\
La fonctionnalité principale de l'application est de pouvoir jouer à une ou plusieurs parties (sans remdémarrer le jeu).
Par le biais d'un menu dédié, l'utilisateur a aussi la possibilité de pousser la personnalisation d'une partie tel que les caractéristiques visuelles et physiques. Ceci inclus la sélection par les joueurs de la couleur de leur archer et leur noms. Notons au passage que si deux joueurs choisissent la même couleur, ceux-si sont considérés comme dans la même équipe (fonctionnalité non implantée pour le moment).
Un autre menu permet de mettre la partie qui était en cours en pause. L'utilisateur peut alors au choix reprendre, changer quelques paramètres comme la musique ou alors quitter pour revenir au menu principal.
Enfin un dernier menu permet de régler les paramètres généraux du jeu tel que la résolution, le nombre d'image par secondes, le vsync, le niveau de détails... Notez que en l'état actuel des choses tous ces paramètres ne sont pas encore modifiables.
\section{Gestion Agile du projet avec Vision de l'application}
Durant les séances dédiées à l'applicaton des méthodes de projet Agile nous avons pu découper notre application en fonctionnalités elle même redécoupées et ainsi de suite jusqu'à obtenir des "Users stories". Sur la page suivante vous pourrez retrouver le découpage que nous avons effectué.
\newpage
\begin{landscape}
\begin{figure}[h]
\centering
\includegraphics[width=28cm]{vision2.png}
\caption{Découpage de la vision du projet jusqu'au Users Stories (voir Méthodes Agiles pour le détail des termes)}
\end{figure}
\end{landscape}
\newpage
Pour la deuxième itération, puisque nous avions posé les bases du projets et que nous avions pu obtenir un rendu preléminaire à l'aspect "débugage", nous nous sommes concentrés sur les aspects esthétiques du projet. Dans le cadre du MVC nous pourrions dire que nous nous sommes attachés à améliorer la vue pendant cette itération. Ainsi nous sommes passés de ce rendu :
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{Lancement.png}
\caption{Premier version du jeu, aspect debug}
\end{figure}
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{fleche_plantee.png}
\caption{Deuxième bersion, aspect debug}
\end{figure}
au rendu ci-dessus.
\section{Découpage de lapplication et application du MVC (Modèle Vue Contrôleur)}
\textit{cette section est presque identique au premier rapport}
\\
Le jeu est actuellement divisé en deux parties, le modèle physique du jeu, et la partie visuelle du jeu. Nous avons fait ce choix pour rendre le jeu le plus indépendant possible d'une interface graphique. Vous noterez toutefois une très forte dépendance entre le modèle physique et la bibliothèque LIBGDX. En effet, il nous a paru relativement difficile de séparer complètement la partie modèle physique du jeu de libGDX qui apporte des fonctionnalités permettant d'améliorer les performances et qui offre un panel de possibilités plus large que si nous réécrivions toutes ces méthodes.
\\ Pour ce qui est du respect strict du MVC nous avons eu beaucoup de difficultés à séparer le moteur du Jeu de sa vue et nous n'y sommes pas parvenu de façon totale. Cependant dans la mesure ou il s'agit d'un jeu dont la vocation n'est pas de changer d'interface graphique souvent cela ne nous semble pas complètement abberrant non plus.
\\ Enfin notons que la partie contrôleur du jeu est celle qui est permise par libGDX, elle ressemble très fortement à celle de Swing mais offre plus de possibilités en se rapporchant plus de l'aspect bas niveau (possibilité d'interagir directement avec le processeur par exemple).
\newpage
\section{Diagrammes de classe}
Voici des diagrammes UML pour vous aider lors de la lecture du code.
\begin{center}
\includegraphics[width=17.25cm]{UML_model.jpeg}
\end{center}
\begin{center}
\includegraphics[width=17.25cm]{UML_libGDX.jpeg}
\end{center}
\newpage
\section{Choix de conception et réalisation}
Un choix de conception important que nous avons du réalisé et qui ne respecte pas bien le principe du MVC est le fait que nous ayons inclus de nombreuses méthodes de LIBGDX dans la plupart de nos classes. Nous avons déjà abordé ce point dans le rapport précédent.
\\ Au cours de cette itération nous avons d'avantage développée la vue et nous nous sommes aperçu qu'il est très difficile dans la rendre indépendante du modèle physique. En effet prenons l'exemple du "skin" des personnages. Il parait contreintuitif de ne pas placer associer la tenue d'un joueur au joueur lui-même. C'est pour cette raison que la gestion de l'affichage des tenues se fait dans la clasee Player. Nous aurions très bien pu placer cette gestion dans une classe à part mais le problème restera le même : il est impossible de séparer totalement vue et modèle dans notre cas. \\
Un autre exemple qui vient illustrer cette idée est l'utilisation des musiques. En effet leur implantation est disséminée un peu dans toutes les classes du projet. Vous en retrouverez dans les classes associées aux menus (dans la partie vue) mais aussi dans certaines classes qui réalisent des actions spécifiques (comme les joueurs). Ce choix a été fait (et n'est pas définitifà afin de ne pas multiplier de façon exponentielle le nombre de classes et le nombre de Listener. De plus concernant les musiques, notez que changer de moteur graphique ne pose pas de souci puisqu'il est possible de les désactiver par un booléen dans la classe SagittariusGame.java.
\section{Points à améliorer pour la prochaine itération}
Il semble que dans certaines classes des redondances apparaissent. On peut citer l'exemple de la gestion de la musique qui se retrouve un peu partout et avec un code relativement similaire ou encore les deux menus qui gèrent les paramètres dont la ressemblance est asse frappante. A ce stade là il nous faudrait faire un bilan du diagramme UML pour voir ce qui peut être réifier.
\end{document}

Binary file not shown.

Binary file not shown.

View file

@ -0,0 +1,269 @@
<html>
<style>
table {
border-collapse: separate;
border-spacing: .5em .5em;
}
th, td {
border: 1px solid black;
padding: 1em .5em ;
position: relative;
text-align: center;
}
span.valeur {
position: absolute;
left: 0;
top: 0;
background: #a5d6a7;
}
span.effort {
position: absolute;
right: 0;
top: 0;
background: #90caf9;
}
</style>
<table>
<thead>
<tr>
<th colspan="23">
Sagittarius : jeu d'arcade tour par tour
<span class="valeur">valeur</span>
<span class="effort">effort</span>
</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="15">
Partie
<span class="valeur">2500</span>
</td>
<td colspan="8">
Paramètres
<span class="valeur">500</span>
</td>
</tr>
<tr>
<td colspan="12">
Configurer Partie
<span class="valeur">1000</span>
</td>
<td colspan="3">
Jouer
<span class="valeur">1500</span>
</td>
<td colspan="4">
Graphiques
<span class="valeur">200</span>
</td>
<td colspan="2">
Audio
<span class="valeur">150</span>
</td>
<td colspan="2">
Contrôles
<span class="valeur">150</span>
</td>
</tr>
<tr>
<td colspan="5">
Mode de jeu
<span class="valeur">400</span>
</td>
<td colspan="2">
Joueurs
<span class="valeur">300</span>
</td>
<td colspan="5">
Environnement
<span class="valeur">300</span>
</td>
<td colspan="2">
Tirer une flèche
<span class="valeur">900</span>
</td>
<td>
Se déplacer
<span class="valeur">600</span>
<span class="effort">2</span>
</td>
<td colspan="2">
Écran
<span class="valeur">100</span>
</td>
<td colspan="2">
Niveau de détails
<span class="valeur">100</span>
</td>
<td>
Musique
<span class="valeur">75</span>
<span class="effort">1</span>
</td>
<td>
Bruitages
<span class="valeur">75</span>
<span class="effort">1</span>
</td>
<td>
Sensibilité
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Raccourcis
<span class="valeur">100</span>
<span class="effort">3</span>
</td>
</tr>
<tr>
<td colspan="3">
Multijoueur
<span class="valeur">300</span>
</td>
<td colspan="2">
Solo
<span class="valeur">100</span>
</td>
<td>
Nom
<span class="valeur">100</span>
<span class="effort">2</span>
</td>
<td>
Couleur
<span class="valeur">200</span>
<span class="effort">2</span>
</td>
<td colspan="3">
Planètes
<span class="valeur">220</span>
</td>
<td colspan="2">
Autres
<span class="valeur">80</span>
</td>
<td>
Viser
<span class="valeur">500</span>
<span class="effort">3</span>
</td>
<td>
Puissance
<span class="valeur">400</span>
<span class="effort">2</span>
</td>
<td style="visibility: hidden;"></td>
<td>
FPS
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Résolution
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Décors
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Particules
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
</tr>
<tr>
<td>
Nombre de joueurs
<span class="valeur">120</span>
<span class="effort">2</span>
</td>
<td>
Nombre d'équipes
<span class="valeur">120</span>
<span class="effort">2</span>
</td>
<td>
Tir alliés
<span class="valeur">60</span>
<span class="effort">1</span>
</td>
<td>
Timer
<span class="valeur">50</span>
<span class="effort">1</span>
</td>
<td>
Objectifs
<span class="valeur">50</span>
<span class="effort">5</span>
</td>
<td colspan="2" style="visibility: hidden;"></td>
<td>
Densité
<span class="valeur">80</span>
<span class="effort">1</span>
</td>
<td>
Taille
<span class="valeur">80</span>
<span class="effort">2</span>
</td>
<td>
Lunes
<span class="valeur">60</span>
<span class="effort">3</span>
</td>
<td>
Astérodïdes
<span class="valeur">40</span>
<span class="effort">5</span>
</td>
<td>
Gadgets
<span class="valeur">40</span>
<span class="effort">5</span>
</td>
</tr>
</tbody>
</table>
</html>

BIN
docs/iteration2/vision2.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 68 KiB

View file

@ -0,0 +1,23 @@
En tant qu'utilisateur je souhaite pouvoir sélectionner le nombre de joueurs dans une partie pour jouer à plusieurs.
En tant qu'utilisateur je souhaite pouvoir sélectionner le nombre d'équipes pour coopérer avec d'autres joueurs.
En tant qu'utilisateur je souhaite pouvoir activer le tir alliés pour trahir mes coéquipiers.
En tant qu'utilisateur je souhaite pouvoir limiter la durée d'une partie pour ne pas passer trop de temps sur une seule partie.
En tant tant que joueur je souhaite avoir un objectif pour finir une partie solo.
En tant que joueur je souhaite pouvoir choisir mon nom pour me distinguer.
En tant que joueur je souhaite pouvoir choisir mon nom pour me distinguer et choisir mon équipe.
En tant qu'utilisateur je souhaite pouvoir choisir la densité de planètes par joueurs dans une partie.
En tant qu'utilisateur je souhaite pouvoir choisir la taille moyenne des planètes.
En tant qu'utilisateur je souhaite pouvoir choisir la probabilité qu'une planète possède une lune.
En tant qu'utilisateur je souhaite pouvoir activer l'apparition d'astéroïdes pour aciver la mort subite.
En tant qu'utilisateur je souhaite pouvoir activer l'apparition de bonus pour pouvoir modifier les caractéritiques de mes flèches
En tant que joueur je souhaite pouvoir choisir l'angle de ma flèche quand je la tire.
En tant que joueur je souhaite pouvoir choisir la piuissance fournie à ma flèche quand je la tire.
En tant que joueur je souhaite pouvoir me déplacer autour de ma planète.
En tant qu'utilisateur je veux pouvoir indiquer le nombre d'FPS espérés.
En tant qu'utilisateur je veux pouvoir indiquer la résolution de la fenètre de jeu.
En tant qu'utilisateur je souhaite activer la génération de décors dans le jeu.
En tant qu'utilisateur je souhaite pouvoir afficher les particules à l'écran ou non.
En tant qu'utilisateur je souhaite pouvoir activer et choisir le volume de la musique.
En tant qu'utilisateur je souhaite pouvoir activer et choisir le volume des effets sonores.
En tant qu'utilisateur je souhaite pouvoir choisir la sensibilité de la souris.
En tant qu'utilisateur je souhaite pouvoir choisir les controles associés aux actions dans le jeu.

View file

@ -0,0 +1,168 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{float}
\usepackage{color}
\usepackage[french]{babel}
\usepackage[hidelinks]{hyperref}
\usepackage{mathtools}
\usepackage[nottoc, numbib]{tocbibind}
\usepackage{lipsum}
\usepackage{lscape}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\graphicspath{
{../images/}
{../iteration1/}
{../iteration2/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Rapport général \\
Itération n°é
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1}
\vspace{2mm} \\
Fainsin Laurent \\
Guillemin Johan \\
Guillotin Damien \\
Heurtebise Tom \\
Jourdan Pierre-eliot \\
Kirupananthan Nadesan
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
%\setcounter{tocdepth}{1}
\tableofcontents
\newpage
\section{Rappel du projet}
\textit{cette section est identique au premier rapport}
\\
Sagittarius est un jeu type arcade tour par tour pouvant être joué de 2 à 5 joueurs. Le but d'un joueur est d'éliminer ses adversaires grâce à un arc, des flèches et, la mécanique principale du jeu, la gravité !
\\Ce projet a pour but de recréer ce jeu existant tout en l'améliorant par divers ajouts/fonctionnalités. Nous n'en revendiquons pas la propriété intellectuelle et nous n'avons pas consulté le code source pour élaborer notre projet !
\section{Principales fonctionnalités}
\textit{cette section est identique au premier rapport}
\\
La fonctionnalité principale de l'application est de pouvoir jouer à une ou plusieurs parties (sans remdémarrer le jeu).
Par le biais d'un menu dédié, l'utilisateur a aussi la possibilité de pousser la personnalisation d'une partie tel que les caractéristiques visuelles et physiques. Ceci inclus la sélection par les joueurs de la couleur de leur archer et leur noms. Notons au passage que si deux joueurs choisissent la même couleur, ceux-si sont considérés comme dans la même équipe (fonctionnalité non implantée pour le moment).
Un autre menu permet de mettre la partie qui était en cours en pause. L'utilisateur peut alors au choix reprendre, changer quelques paramètres comme la musique ou alors quitter pour revenir au menu principal.
Enfin un dernier menu permet de régler les paramètres généraux du jeu tel que la résolution, le nombre d'image par secondes, le vsync, le niveau de détails... Notez que en l'état actuel des choses tous ces paramètres ne sont pas encore modifiables.
\section{Gestion Agile du projet avec Vision de l'application}
Durant les séances dédiées à l'applicaton des méthodes de projet Agile nous avons pu découper notre application en fonctionnalités elle même redécoupées et ainsi de suite jusqu'à obtenir des "Users stories". Sur la page suivante vous pourrez retrouver le découpage que nous avons effectué.
\newpage
\begin{landscape}
\begin{figure}[h]
\centering
\includegraphics[width=28cm]{vision2.png}
\caption{Découpage de la vision du projet jusqu'au Users Stories (voir Méthodes Agiles pour le détail des termes)}
\end{figure}
\end{landscape}
\newpage
Pour la deuxième itération, puisque nous avions posé les bases du projets et que nous avions pu obtenir un rendu preléminaire à l'aspect "débugage", nous nous sommes concentrés sur les aspects esthétiques du projet. Dans le cadre du MVC nous pourrions dire que nous nous sommes attachés à améliorer la vue pendant cette itération. Ainsi nous sommes passés de ce rendu :
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{Lancement.png}
\caption{Premier version du jeu, aspect debug}
\end{figure}
\begin{figure}[H]
\centering
\includegraphics[width=18cm]{fleche_plantee.png}
\caption{Deuxième bersion, aspect debug}
\end{figure}
au rendu ci-dessus.
\section{Découpage de lapplication et application du MVC (Modèle Vue Contrôleur)}
\textit{cette section est presque identique au premier rapport}
\\
Le jeu est actuellement divisé en deux parties, le modèle physique du jeu, et la partie visuelle du jeu. Nous avons fait ce choix pour rendre le jeu le plus indépendant possible d'une interface graphique. Vous noterez toutefois une très forte dépendance entre le modèle physique et la bibliothèque LIBGDX. En effet, il nous a paru relativement difficile de séparer complètement la partie modèle physique du jeu de libGDX qui apporte des fonctionnalités permettant d'améliorer les performances et qui offre un panel de possibilités plus large que si nous réécrivions toutes ces méthodes.
\\ Pour ce qui est du respect strict du MVC nous avons eu beaucoup de difficultés à séparer le moteur du Jeu de sa vue et nous n'y sommes pas parvenu de façon totale. Cependant dans la mesure ou il s'agit d'un jeu dont la vocation n'est pas de changer d'interface graphique souvent cela ne nous semble pas complètement abberrant non plus.
\\ Enfin notons que la partie contrôleur du jeu est celle qui est permise par libGDX, elle ressemble très fortement à celle de Swing mais offre plus de possibilités en se rapporchant plus de l'aspect bas niveau (possibilité d'interagir directement avec le processeur par exemple).
\newpage
\section{Diagrammes de classe}
Voici des diagrammes UML pour vous aider lors de la lecture du code.
\begin{center}
\includegraphics[width=17.25cm]{UML_model.jpeg}
\end{center}
\begin{center}
\includegraphics[width=17.25cm]{UML_libGDX.jpeg}
\end{center}
\newpage
\section{Choix de conception et réalisation}
Un choix de conception important que nous avons du réalisé et qui ne respecte pas bien le principe du MVC est le fait que nous ayons inclus de nombreuses méthodes de LIBGDX dans la plupart de nos classes. Nous avons déjà abordé ce point dans le rapport précédent.
\\ Au cours de cette itération nous avons d'avantage développée la vue et nous nous sommes aperçu qu'il est très difficile dans la rendre indépendante du modèle physique. En effet prenons l'exemple du "skin" des personnages. Il parait contreintuitif de ne pas placer associer la tenue d'un joueur au joueur lui-même. C'est pour cette raison que la gestion de l'affichage des tenues se fait dans la clasee Player. Nous aurions très bien pu placer cette gestion dans une classe à part mais le problème restera le même : il est impossible de séparer totalement vue et modèle dans notre cas. \\
Un autre exemple qui vient illustrer cette idée est l'utilisation des musiques. En effet leur implantation est disséminée un peu dans toutes les classes du projet. Vous en retrouverez dans les classes associées aux menus (dans la partie vue) mais aussi dans certaines classes qui réalisent des actions spécifiques (comme les joueurs). Ce choix a été fait (et n'est pas définitifà afin de ne pas multiplier de façon exponentielle le nombre de classes et le nombre de Listener. De plus concernant les musiques, notez que changer de moteur graphique ne pose pas de souci puisqu'il est possible de les désactiver par un booléen dans la classe SagittariusGame.java.
\section{Points à améliorer pour la prochaine itération}
Il semble que dans certaines classes des redondances apparaissent. On peut citer l'exemple de la gestion de la musique qui se retrouve un peu partout et avec un code relativement similaire ou encore les deux menus qui gèrent les paramètres dont la ressemblance est asse frappante. A ce stade là il nous faudrait faire un bilan du diagramme UML pour voir ce qui peut être réifier.
\end{document}

BIN
docs/iteration3/diapos.odp Normal file

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View file

@ -0,0 +1,70 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsfonts}
\usepackage{color}
\usepackage[french]{babel}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\graphicspath{
{../images/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Rapport Individuel \\
Itération n°3
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1} \\
\vspace{2mm}
Fainsin Laurent
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
\hspace{0pt}
\vfill
Lors de cette troisième itération, je me suis penché sur la gestion des contrôles dans le jeu. Avant que celui-ci ne soit implémenté, les contrôles étaient prédéfinis dans le code du jeu. Désormais lorsque l'on accède au menu des paramètres, nous avons à notre disposition 5 boutons nous permettant de sélectionner les touches pour que le joueur se déplace vers la gauche, vers la droite, pour qu'il tire, pour zoomer et dézoomer la caméra.
Sinon plusieurs petites améliorations et corrections de bugs ont aussi été effectuées.
\vfill
\hspace{0pt}
\end{document}

Binary file not shown.

Binary file not shown.

View file

@ -0,0 +1,175 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{float}
\usepackage{color}
\usepackage[french]{babel}
\usepackage[hidelinks]{hyperref}
\usepackage{mathtools}
\usepackage[nottoc, numbib]{tocbibind}
\usepackage{lipsum}
\usepackage{lscape}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\graphicspath{
{../images/}
{../iteration1/}
{../iteration2/}
{../iteration2/Screen/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\setlength{\parindent}{0pt}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Rapport général \\
Itération n°3
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1}
\vspace{2mm} \\
Fainsin Laurent \\
Guillemin Johan \\
Guillotin Damien \\
Heurtebise Tom \\
Jourdan Pierre-eliot \\
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
%\setcounter{tocdepth}{1}
\tableofcontents
\newpage
\section{Rappel du projet}
Sagittarius est un jeu type arcade tour par tour pouvant être joué de 2 à 5 joueurs. Le but d'un joueur est d'éliminer ses adversaires grâce à un arc, des flèches et, la mécanique principale du jeu, la gravité ! \\
Ce projet a pour but de recréer ce jeu existant tout en l'améliorant par divers ajouts/fonctionnalités. Nous n'en revendiquons pas la propriété intellectuelle et nous n'avons pas consulté le code source pour élaborer notre projet !
\section{Principales fonctionnalités}
La fonctionnalité principale de lapplication est de pouvoir jouer à une ou plusieurs parties. Le joueur doit donc pouvoir tirer, ce qui prend en compte langle de tire ainsi que la puissance du tire, et il doit pouvoir se déplacer. \\
Il est également important que le joueur puisse régler les paramètres qui vont directement impacter sa partie tel que le nombre de joueurs et donc le nombre de planètes. Cependant, nous navons pas eu le temps dimplanter de mode solo ni de mode équipe. Chaque joueur est désigné par une couleur, cependant il na pas moyen de la choisir par lui-même, sa couleur lui est assignée aléatoirement.
Pour la génération de lenvironnement (ce qui comprend en compte la position, la taille et la masse des planètes), lutilisateur ne peut pas changer les paramètres avancés mais elle reste tout de même différente à chaque partie.
Au niveau des paramètres audiovisuel, l'utilisateur peut par exemple retirer les sons et musiques. De plus, il peut changer les touches de contrôle.
Toutes ces fonctionnalités sont rangées dans des menus tels que le menu settings situé dans le menu principal ou dans le menu pause. A tout moment, il est tout à fait possible de quitter le jeu, quitter une partie ou en recommencer une.
\section{Gestion Agile du projet avec Vision de l'application}
Durant les séances dédiées à l'application des méthodes de projet Agile nous avons pu découper notre application en fonctionnalités elle même redécoupées et ainsi de suite jusqu'à obtenir des "Users stories". Sur la page suivante vous pourrez retrouver le découpage que nous avons effectué.
\newpage
\begin{landscape}
\begin{figure}[ht!]
\centering
\includegraphics[width=28cm]{vision2.png}
\caption{Découpage de la vision du projet jusqu'au Users Stories (voir Méthodes Agiles pour le détail des termes)}
\end{figure}
\end{landscape}
\newpage
\section{Découpage de lapplication en sous-systèmes (en paquetages)}
Le jeu est actuellement divisé en deux paquets, un paquet pour toutes les classes du modèle physique du jeu, et un deuxième paquet regroupant les écrans du jeu. \\
Nous avons utilisé le sous-paquet scene2D de libGDX, mais celui-ci ne respecte pas le template MVC. S'obstiner à appliquer le MVC impliquait de contourner les systèmes mis en place par scene2D ou bien à réécrire la totalité de libraire nous même, nous avons donc choisi de ne pas appliquer le MVC. À noter tout de même que le modèle MVC est peu adapté à des jeux plus dynamiques d'un puissance 4 ou un tic-tac-toe, comme le nôtre. Nous avons tout de même essayé de créer une version compatible avec swing mais, les deux moteurs graphiques étant incompatibles, lors de l'ajout d'une nouvelle fonctionnalité au jeu, résoudre les problèmes de compatibilité était trop chronophage. De même la granularité des contrôles des entrées que proposait Swing n'était pas comparable avec celle de libGDX, surtout pour un jeu en temps réel comme le nôtre. Après quelques recherches il semble que le patron de conception le plus couramment utilisé pour des jeux en temps réel soit l'ECS. Scene2D ne propose pas un système de composant pour les entitées, mais seulement des entitées (appelées ici Actors).
\section{Diagramme de classe et architecture de l'application}
Dans cette section nous allons vous présenter l'architecture de l'application sous la forme de deux diagrammes UML. Le premier présente l'architecture du modèle physique et le deuxième l'architecture de la vue du jeu. \\
Voici d'abord le moteur physique du jeu :
\begin{landscape}
\begin{figure}[ht!]
\centering
\includegraphics[width=24cm]{trim_uml_model.png}
\caption{Diagramme UML simplifié du moteur physique du jeu}
\end{figure}
\end{landscape}
La classe initiale de tout le projet est SagittariusGame.java. On le constate aisément sur l'UML puisqu'elle agrège d'autres classes. Du point de vue du code, c'est elle qui initie tout le jeu en construisant l'écran de démarrage situé dans la vue (StartScreen.java). Cet écran fait lui-même appel à la construction de l'écran d'une partie (cf classe GameScreen.java) qui va lancer tous les constructeurs du modèle physique. Ainsi c'est dans la classe GameScreen que toutes les "entités" sont générées et que l'on crée donc les joueurs, les planètes, l'arc et les flèches. Il s'agit vraisemblablement de la classe centrale du projet puisque c'est elle qui s'occupe de la gestion et de la destruction de tous ces objets (un joueur tué est supprimé de la partie par GameScreen). \\
A notre sens la classe centrale du modèle physique est néanmoins Arrow.java puisque c'est cette classe qui est la plus technique avec le calcul de trajectoire par exemple.
A présent, abordons le diagramme UML de la vue. Sur celui-ci vous retrouverez de nombreux éléments issus de libGDX puisque nous nous sommes largement appuyés sur le framework proposé par cette librairie. Ainsi comme vous pourrez le noter sur le diagramme la vue proposée par libgdx est organisée sous forme de "scènes" (cad des écrans) sur lesquelles figurent des acteurs. Les classes que nous avons développées pour la vue sont celles dont le suffixe est *Screen.java. Dans chacune de ces classes vous trouverez notamment les méthodes initiales et update qui se chargent respectivement de la création des écrans et de leur rafraîchissement perpétuels (avec la prise en compte des évènements comme la mort d'un joueur par exemple). Le code important se trouve dans les méthodes update pour les écrans et pour les acteurs ils se trouvent dans les méthodes act.
\begin{landscape}
\begin{figure}[ht!]
\centering
\includegraphics[width=24cm]{trim_uml_vue.png}
\caption{Diagramme UML simplifié de la vue du jeu}
\end{figure}
\end{landscape}
\newpage
\section{Choix de conception et réalisation}
Un choix de conception important que nous avons dû réaliser et qui ne respecte pas bien le principe du MVC est le fait que nous ayons utilisé de nombreuses méthodes de LIBGDX dans la plupart de nos classes. Nous avons déjà abordé ce point dans les sections et dans les rapports précédents. \\
Pour une classe donnée, par exemple Player.java, l'ensemble des éléments en rapport avec lui sont contenus dans celle-ci (en partie à cause de la manière dont est écrit scene2D). Ainsi la classe Player.java gère son modèle physique, sa vue, le lancement d'effets sonores, la gestion des contrôles en rapport avec son déplacement, sa destruction...
Ce patron de conception va à l'encontre du MVC, mais de cette manière toutes les entités sont bien séparées.
\section{Organisation de l'équipe}
Nous avons choisi d'utiliser le git de l'enseeiht (git.inpt.fr) pour notre gestionnaire de version.
Laurent s'est occupé de créer une base avec libGDX pour que nous puissions tous commencer à programmer dessus. Il s'est aussi globalement occupé du modèle physique, du tracking de la caméra et du menu permettant de gérer les contrôles. \\
Damien s'est occupé de l'affichage des textures, de la génération de la carte, de la gestion des joueurs (système de tours)... \\
Pierre-Eliot s'est chargé avec Damien de la réalisation des textures du jeu, mais aussi du modèle physique avec Laurent (classes Entity, Player, Planet...). \\
Tom s'est principalement occupé de la création des menus et du système permettant de naviguer entre les menus. De même, il s'est occupé de la gestion de la musique et des effets sonores.
Globalement, nous avons toujours respecté ce que nous avions planifié à chaque itération.
\section{Points à améliorer}
Par manque de temps, nous n'avons pas eu l'occasion d'implémenter certaines fonctionnalités. Ainsi il manque actuellement un système d'équipe ainsi qu'un mode de jeu solo. Certains menus pourraient être mieux désignés, mais ceux-ci remplissent tout de même leur rôle. Le code peut évidemment être optimisé à certains endroits, de même quelques classes/fonctions pourraient être factorisé/réifié.
\section{Conclusion}
Nous avons trouvé ce projet intéressant puisqu'il nous a permis de découvrir pour la première fois ce qu'était la collaboration sur un projet ambitieux. De plus, il nous a fallu nous organiser entre nous et apprendre à utiliser des outils tels que git qui devraient nous être utiles dans notre future vie professionnelle.
\end{document}

Binary file not shown.

View file

@ -0,0 +1,6 @@
Laurent FAINSIN : 2 points
Damien GUILLOTIN : 1 point
Pierre-Eliot JOURDAN : 1 point
Tom HEURTEBISE : 1 point
Johan GUILLEMIN : 0 point

View file

@ -0,0 +1,269 @@
<html>
<style>
table {
border-collapse: separate;
border-spacing: .5em .5em;
}
th, td {
border: 1px solid black;
padding: 1em .5em ;
position: relative;
text-align: center;
}
span.valeur {
position: absolute;
left: 0;
top: 0;
background: #a5d6a7;
}
span.effort {
position: absolute;
right: 0;
top: 0;
background: #90caf9;
}
</style>
<table>
<thead>
<tr>
<th colspan="23">
Sagittarius : jeu d'arcade tour par tour
<span class="valeur">valeur</span>
<span class="effort">effort</span>
</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="15">
Partie
<span class="valeur">2500</span>
</td>
<td colspan="8">
Paramètres
<span class="valeur">500</span>
</td>
</tr>
<tr>
<td colspan="12">
Configurer Partie
<span class="valeur">1000</span>
</td>
<td colspan="3">
Jouer
<span class="valeur">1500</span>
</td>
<td colspan="4">
Graphiques
<span class="valeur">200</span>
</td>
<td colspan="2">
Audio
<span class="valeur">150</span>
</td>
<td colspan="2">
Contrôles
<span class="valeur">150</span>
</td>
</tr>
<tr>
<td colspan="5">
Mode de jeu
<span class="valeur">400</span>
</td>
<td colspan="2">
Joueurs
<span class="valeur">300</span>
</td>
<td colspan="5">
Environnement
<span class="valeur">300</span>
</td>
<td colspan="2">
Tirer une flèche
<span class="valeur">900</span>
</td>
<td>
Se déplacer
<span class="valeur">600</span>
<span class="effort">2</span>
</td>
<td colspan="2">
Écran
<span class="valeur">100</span>
</td>
<td colspan="2">
Niveau de détails
<span class="valeur">100</span>
</td>
<td>
Musique
<span class="valeur">75</span>
<span class="effort">5</span>
</td>
<td>
Bruitages
<span class="valeur">75</span>
<span class="effort">5</span>
</td>
<td>
Sensibilité
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Raccourcis
<span class="valeur">100</span>
<span class="effort">7</span>
</td>
</tr>
<tr>
<td colspan="3">
Multijoueur
<span class="valeur">300</span>
</td>
<td colspan="2">
Solo
<span class="valeur">100</span>
</td>
<td>
Nom
<span class="valeur">100</span>
<span class="effort">2</span>
</td>
<td>
Couleur
<span class="valeur">200</span>
<span class="effort">2</span>
</td>
<td colspan="3">
Planètes
<span class="valeur">220</span>
</td>
<td colspan="2">
Autres
<span class="valeur">80</span>
</td>
<td>
Viser
<span class="valeur">500</span>
<span class="effort">3</span>
</td>
<td>
Puissance
<span class="valeur">400</span>
<span class="effort">2</span>
</td>
<td style="visibility: hidden;"></td>
<td>
FPS
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Résolution
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Décors
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
<td>
Particules
<span class="valeur">50</span>
<span class="effort">2</span>
</td>
</tr>
<tr>
<td>
Nombre de joueurs
<span class="valeur">120</span>
<span class="effort">2</span>
</td>
<td>
Nombre d'équipes
<span class="valeur">120</span>
<span class="effort">2</span>
</td>
<td>
Tir alliés
<span class="valeur">60</span>
<span class="effort">1</span>
</td>
<td>
Timer
<span class="valeur">50</span>
<span class="effort">1</span>
</td>
<td>
Objectifs
<span class="valeur">50</span>
<span class="effort">5</span>
</td>
<td colspan="2" style="visibility: hidden;"></td>
<td>
Densité
<span class="valeur">80</span>
<span class="effort">1</span>
</td>
<td>
Taille
<span class="valeur">80</span>
<span class="effort">2</span>
</td>
<td>
Lunes
<span class="valeur">60</span>
<span class="effort">3</span>
</td>
<td>
Astérodïdes
<span class="valeur">40</span>
<span class="effort">5</span>
</td>
<td>
Gadgets
<span class="valeur">40</span>
<span class="effort">5</span>
</td>
</tr>
</tbody>
</table>
</html>

BIN
docs/iteration3/vision3.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 59 KiB

Binary file not shown.

View file

@ -0,0 +1,279 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{color}
\usepackage[french]{babel}
\usepackage[hidelinks]{hyperref}
\usepackage{mathtools}
\usepackage[nottoc, numbib]{tocbibind}
\usepackage{lipsum}
\usepackage{contour}
\usepackage{ulem}
\renewcommand{\ULdepth}{1.8pt}
\contourlength{0.8pt}
\newcommand{\myuline}[1]{%
\uline{\phantom{#1}}%
\llap{\contour{white}{#1}}%
}
\graphicspath{
{../images/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Fonctionnalités de lapplication \\
Sagittarius
\vspace{2cm}
}
\author{
\myuline{Groupe IJ-1}
\vspace{2mm} \\
Fainsin Laurent \\
Guillemin Johan \\
Guillotin Damien \\
Heurtebise Tom \\
Jourdan Pierre-eliot \\
Kirupananthan Nadesan
}
\date{
\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021
}
\maketitle
\newpage
%\setcounter{tocdepth}{1}
\tableofcontents
\newpage
\begin{figure}[ht!]
\centering
\includegraphics[width=7cm]{sagittarius.png}
\end{figure}
Nous envisageons de créer un programme permettant de jouer à Sagittarius \cite{sagittarius}, un jeu tour par tour donc l'unique but est de tirer avec un arc et des flèches sur les autres joueurs et où le mécanisme principal est la gravité !
\section{Objectif général du projet}
L'objectif principal de ce programme est de pouvoir jouer à autant de parties de Sagittarius que l'on souhaite. Lors de la création d'une partie, il se génère aléatoirement un environnement céleste dans lequel des joueurs seront placés. Une partie pourra se jouer de 2 à 4 joueurs. Avant le début des hostilités, les utilisateurs auront le choix de leur couleur, mais aussi des paramètres de la partie. Lors de la partie, les joueurs peuvent se déplacer librement sur leur planète avant de tirer. La partie se déroule tour par tour, cependant ceux-ci seront limités à 30 secondes (par défaut) pour ne pas ralentir le jeu. Une partie se finit lorsquil ne reste qu'un seul joueur encore en vie.
\section{Fonctionnalités}
\subsection{Génération du terrain} %Damien
La génération du terrain se fera aléatoirement. Cependant, les planètes générées devront être suffisamment espacées et en nombre raisonnable (il faudra au moins autant de planètes que de joueurs). Les joueurs seront aléatoirement associés à une planète et avec une position aléatoire sur celle-ci.
\subsection{Tirer des flèches} %Laurent
Grâce aux entrées (souris et/ou clavier) les joueurs pourront choisir la direction initiale de la flèche ainsi que sa vitesse initiale. La flèche décrira ensuite une trajectoire, calculée à partir des forces que les planètes exercent sur elle.
\subsection{Mourir} %Tom
Une fonctionnalité qui peut paraître incongrue et qui pourtant est la base même de notre jeu est la possibilité pour le joueur de mourir. Par mourir nous entendons que si jamais le joueur est frappé par une flèche adverse son avatar disparaît de la planète sur laquelle il se trouvait et il perd la partie. Il faudra donc implémenter la disparition des avatars et donc la mort des joueurs. A ceci nous ajouterons la possibilité pour un joueur d'abandonner pour ne plus prendre part à la partie en cours. Cette option se modélisera par une flèche tirée au-dessus de lui qui fera disparaître le joueur.
\subsection{Se déplacer} %johan
Les joueurs doivent pouvoir se déplacer sur la surface de leur planète, vers la gauche et la droite (contrôles avec les flèches). Ils doivent ainsi pouvoir faire le tour de leur planète.
\subsection{Choisir le nombre de joueurs} %pe
Lors du lancement dune partie, il est nécessaire de définir le nombre de joueurs. Le nombre de joueurs pour une même partie pourra aller de 1 (mode solo) à 4.
\subsection{Personnaliser son pseudo/couleur} %pe
Létape suivante (plus secondaire) du lancement dune partie, sera daffecter à chaque joueur un nom et une couleur. Chaque joueur pourra ainsi définir le nom quil souhaite et choisir sa couleur (qui sera aussi celle de sa planète).
\subsection{Nombre de vies} %Laurent
Lors de la sélection des paramètres de la partie, les utilisateurs auront la possibilité de choisir le nombre de flèche nécessaire à lélimination dun joueur.
\subsection{(Visualiser la trajectoire des flèches)} %Damien
Pour faciliter la visée (et le debug), loption daffichage de la prévision de la trajectoire pourra être activée. Le tracé de la trajectoire de la flèche sera dessiné avant même que la flèche ne soit lancée.
\subsection{(Tableau des scores)} %Tom
Une autre fonctionnalité qui pourra être implanté si le temps le permet est l'affichage des scores et de certaines données. On pourra ainsi afficher le taux de précision de chaque joueur, le nombre d'autres joueurs touchés ainsi que la place obtenue.
\subsection{(Densité de planètes)} %pe
Lors de linitialisation de la partie, chaque joueur aura la possibilité de choisir la taille et la densité de sa planète de départ. Les autres planètes seront réparties de manière aléatoire (avec une densité aléatoirement associée) lors de la génération du terrain.
\subsection{(Taille de la carte)} %Laurent
Lors de la création de la partie, un paramètre permettra de sélectionner la taille de la carte. Plus celle-ci sera grande, plus la distance séparant deux joueurs/planète sera élevée.
\subsection{(Planète/Lunes mobiles)} % Laurent
Lors de la création de la partie, un paramètre permettra de sélectionner si des planètes/lunes mobiles (en orbite) seront présentes dans la partie. Celles-ci viendront ajouter un niveau de difficulté à la partie.
\subsection{(Caméra mobile)} %johan
Déplacement du point de vue, soit si la carte est trop petite, soit pour avoir une meilleure vision pour le tir et ainsi pour viser plus facilement.
\subsection{(Gadget)} %Damien
Lorsque le joueur touche un objet spécial avec sa flèche, il obtient un bonus/malus.
\subsection{(Mode par équipe)} %Tom
Dans ce mode, la survie ne se fait plus individuellement mais par équipes. Ainsi les joueurs peuvent choisir leur couleur qui définit leur équipe. La dernière couleur en vie remporte la partie.
\subsection{(Changer de planète)} %Tom
Une fonctionnalité optionnelle est la possibilité pour un joueur de changer de planète. Évidemment ce dernier ne peut changer que pour une planète non occupée par un joueur. Cette possibilité lui sera offerte s'il parvient à se débarrasser d'un de ses adversaires et uniquement dans ce cas-là. Au tour qui suivra le « kill », le joueur survivant aura la possibilité de changer de planète pour celle de sa victime. Cette action vient se substituer à la capacité de tirer pour le tour en cours.
\subsection{(Aimbot)} %Damien
Le mode aimbot a pour but de déterminer le meilleur angle et la meilleure puissance de tir afin datteindre une cible. Il permettra dimplanter des ordinateurs pour jouer en solo, mais pourra aussi être utilisé par des joueurs mal intentionnés.
\subsection{(IA)} %Laurent
Lors de la création des parties, les archers peuvent être pilotés par une intelligence artificielle dont le niveau de difficulté définit leur précision.
\subsection{(Mort subite)} %pe
Pour éviter que la partie ne séternise, on définit un temps (ayant une valeur par défaut mais pouvant être changé au moment de linitialisation dune partie) à partir duquel des astéroïdes/météorites apparaissent, de manière régulière, avec des trajectoires aléatoires sur le terrain, susceptibles de tuer un joueur s'ils le touchent.
\subsection{(Sauter)} %pe
Si nous avons suffisamment de temps pour le faire, nous souhaitons implanter une fonctionnalité qui permettrait au joueur, en plus de se déplacer sur la planète, deffectuer des sauts pour éviter les flèches envoyées.
\subsection{(Mode solo)} %Tom
Dans ce mode, un unique joueur humain peut sexercer au travers de niveau dans lesquels il y a différentes cibles qui sont des PNJ (Personnages Non Joueurs). Pour passer au niveau daprès le joueur doit atteindre toutes les cibles. Nous nous réservons le droit dajouter une fonctionnalité dans laquelle le joueur dispose dun nombre limité de flèches avant de recommencer le niveau et une fonctionnalité dans laquelle ce nombre est illimité.
\section{Interfaces utilisateur}
Voici de \textit{magnifiques} esquisses/exemples d'interfaces que le jeu utilisera.
\subsection{Menu principal} %pe
\begin{center}
\includegraphics[width=12cm]{menuPrincipal.png}
\end{center}
\subsection{Menu pause} %Damien
\begin{center}
\includegraphics[width=12cm]{menuPause.png}
\end{center}
\subsection{Menu customisation archer} %johan
\begin{center}
\includegraphics[width=12cm]{menuPerso.png}
\end{center}
\subsection{Menu option} %Tom
\begin{center}
\includegraphics[width=12cm]{MenuParametre.png}
\end{center}
\subsection{Menu paramètres de la partie} %Tom
\begin{center}
\includegraphics[width=12cm]{Menu_Tom.png}
\end{center}
\subsection{Affichage de la map} %Laurent
\begin{center}
\includegraphics[width=12cm]{affichage_map.png}
\end{center}
\section{Scénarios} %Tom
Les scénarios pour tester le jeu sont multiples. Cette section sera sûrement à compléter par la suite mais en voici un premier jet.
\subsection{Scénario n°1}
Tout d'abord dans le premier scénario nous testerons si le jeu se lance bien et surtout si le mode classique (le mode de 2 à 4 joueurs humains) est fonctionnel. Aucun test automatique ne sera possible puisqu'il s'agira d'interagir avec le jeu directement. Dans l'exécution de ce scénario il faudra donc lancer le programme principal qui affiche l'interface graphique, (le lancement en ligne de commande ou par le biais d'un autre type d'IHM sera à notre convenance. Une fois lancé le menu des paramètres nous vérifierons que le menu principal nous amène bien dans chacun des modes (mode solo, mode à plusieurs, etc…). À chaque fois nous reviendrons au menu principal. Suite à cela nous entrerons dans le mode solo. Le test de ce mode se fera suivant un nombre quelconque de joueurs (4 par exemple) et avec des noms/couleurs aussi quelconques. Une fois la partie lancée nous constaterons que lensemble des fonctionnalités prévues pour de ce mode fonctionnent (avec une attention particulière sur les trajectoires de chaque flèche, les déplacements des personnages et leur décès). Nous conclurons ce test par une victoire rapide dun des joueurs pour vérifier la présence de lécran de fin et la possibilité de rejouer/revenir au menu principal.
\subsection{Scénario n°2}
Le deuxième scénario envisagé concerne le mode solo (si implanté) dans lequel le joueur doit abattre des cibles fixes qui seront des PNJ (cf ce qui précède). Si les deux options de ce mode sont implantées il faudra lancer une partie avec le nombre de flèches limité et une deuxième avec le nombre de flèche illimitée. À ce moment il sera opportun de tester le menu de pause pour interrompre la partie qui peut durer indéfiniment.
\subsection{Scénario n°3}
Un troisième scénario qui pourra être testé est celui qui concerne le mode par équipes. Classiquement nous lancerons le jeu et ce mode en particulier en créant deux équipes de joueurs, (léquipe rouge et léquipe bleue par exemple). Pour ce scénario nous essaierons dabord loption “tir allié désactivé en faisant tirer le joueur bleu sur son coéquipier. Si tout se passe bien, ce dernier naura aucun dégât. Nous terminerons la partie par la victoire de léquipe rouge suivie dune deuxième dans laquelle le tir allié sera activé. Le bleu devrait cette fois mourir face au tir de son coéquipier.
\subsection{Scénario n°4}
Un quatrième scénario pourra nous permettre de tester des fonctionnalités plus avancées comme le mode “plusieurs vies” dans lequel il faut plusieurs flèches pour abattre un ennemi. Ce sera aussi loccasion de tester lutilisation dobjets ou encore la possibilité de changer de planètes. Toutes ces options devront être cochées au moment de la création de la partie.
\subsection{Scénario n°5}
Un dernier scénario devrait nous permettre de tester les fonctionnalités les plus avancées si elles ont pu être implémentées. Nous pourrons ainsi tenter de jouer sur une carte dont les paramètres comme le nombre de planètes et leur taille sont choisis par lutilisateur. Ce sera aussi loccasion de tester des modes expérimentaux comme le “aimbot” et éventuellement le jeu contre des Intelligence Artificielle.
\section{Difficultés}
\subsection{Moteur Graphique} %johan
Laffichage graphique sera la partie la plus cruciale du projet car sans affichage pas de jeu, cependant elle va être difficile car nous allons devoir utiliser des librairies annexes \cite{libGDX, swing} que nous ne maîtrisons pas forcément. Cela va donc nous demander un apprentissage il y a le risque de ne pas obtenir le rendu espéré.
\subsection{Moteur physique} %Damien
La trajectoire des flèches est un élément très important du projet. Toute la physique des flèches et donc du gameplay en dépendra. Il faudra trouver un moyen de calculer les trajectoires de manière efficace afin que le jeu reste fluide \cite{verlet}. Il faudra également trouver un compromis entre réalisme des trajectoires et expérience de jeu.
\subsection{Risque que rien ne marche} %Laurent
Comme dit précédemment, la création dun “moteur physique” ainsi que lutilisation dun “moteur graphique” sont des tâches assez difficiles séparément, il y a donc un risque non négligeable que rien ne fonctionne si lune des deux parties ne fonctionne pas.
\newpage
\begin{thebibliography}{9}
\bibitem{sagittarius}
Itch.io, Sagittarius, George Prosser \\
\href{https://gprosser.itch.io/sagittarius}{https://gprosser.itch.io/sagittarius} \\
\bibitem{n_body}
Wikipedia, n-body problem \\
\href{https://en.wikipedia.org/wiki/N-body\_problem}{https://en.wikipedia.org/wiki/N-body\_problem} \\
\href{https://en.wikipedia.org/wiki/Three-body\_problem}{https://en.wikipedia.org/wiki/Three-body\_problem} \\
\bibitem{verlet}
Wikipedia, Verlet integration \\
\href{https://en.wikipedia.org/wiki/Verlet\_integration}{https://en.wikipedia.org/wiki/Verlet\_integration}\\
\href{https://gamedev.stackexchange.com/a/41917}{https://gamedev.stackexchange.com/a/41917} \\
\bibitem{swing}
Swing \\
\href{https://en.wikipedia.org/wiki/Swing\_(Java)}{https://en.wikipedia.org/wiki/Swing\_(Java)} \\
\href{https://docs.oracle.com/javase/8/docs/technotes/guides/swing/}{https://docs.oracle.com/javase/8/docs/technotes/guides/swing/} \\
\bibitem{libGDX}
libGDX \\
\href{https://libgdx.com/}{https://libgdx.com/} \\
\end{thebibliography}
\end{document}

BIN
docs/prelude/sujets.pdf Normal file

Binary file not shown.

199
docs/prelude/sujets.tex Normal file
View file

@ -0,0 +1,199 @@
\documentclass[a4paper, 12pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{color}
\usepackage[french]{babel}
\usepackage[hidelinks]{hyperref}
\usepackage{mathtools}
\usepackage[nottoc, numbib]{tocbibind}
\graphicspath{
{../images/}
}
\usepackage[
top=1.5cm,
bottom=1.5cm,
left=1.5cm,
right=1.5cm
]{geometry}
\setlength{\parskip}{0.2cm}
\begin{document}
\begin{figure}[t]
\centering
\includegraphics[width=5cm]{inp_n7.jpg}
\end{figure}
\title{
\vspace{4cm}
\textbf{Projet long de Technologie Objet} \\
Liste des sujets envisagés
\vspace{2cm}
}
\author{Fainsin Laurent \\
Guillemin Johan \\
Guillotin Damien \\
Heurtebise Tom \\
Jourdan Pierre-eliot \\
Kirupananthan Nadesan}
\date{\vspace{7cm} Département Sciences du Numérique \\
Première année \\
2020 — 2021 }
\maketitle
\newpage
\setcounter{tocdepth}{1}
\tableofcontents
\newpage
\section{Sagittarius}
\begin{figure}[ht!]
\centering
\includegraphics[width=7cm]{sagittarius.png}
\end{figure}
Nous envisageons de créer un programme permettant de jouer à Sagittarius \cite{sagittarius}, un jeu tour par tour donc l'unique but est de tirer avec un arc et des flêches sur les autres joueurs et où le mécanisme principal est la gravité !
\subsection{Objectifs et intérêts}
L'objectif principal est d'obtenir un jeu jouable et qui donne envie aux utilisateur de jouer. Comme la mécanique de ce jeu s'appuie fortement sur la gravité, il nous faudra trouver un moyen de simuler celle-ci. Pour calculer la trajectoire d'une flêche dans un système à N corps \cite{n_body}, nous avons le choix de le faire en temps réel (i.e. à chaque nouvelle image \cite{rt_calc}), ou bien par calcul la trajectoire entière de la flêche (via RK4 \cite{rk4} par exemple).
L'intérêt de choisir un jeu est que cela nécéssite généralement la bonne compréhension et utilisation de la technologie des objets. Il est assez facile de voir que nous aurons besoin d'objets pour les joueurs, les planètes, les flèches, les particules...
\subsection{Difficultés}
L'obstacle majeur à la réalisation de ce jeu est l'outil graphique que nous allons devoir utiliser. En effet, nous apprendrons à utiliser Swing lors du dernier cours de Technologie Objet, cependant il est peu probable que cet environnement graphique soit adapté à ce projet. Il nous faudra alors trouver une alternative, cela implique qu'une partie du dévelopement soit alloué à l'apprentissage (basique) d'une librairie.
\newpage
\section{Le jeu des échecs}
\begin{figure}[ht!]
\centering
\includegraphics[width=7cm]{chess.jpg}
\end{figure}
Ce projet vise à créer un programme de jeu déchecs classique. Deux joueurs saffrontent selon deux types de parties possibles : les parties dites “rapides” (où un temps sera fixé au début de la partie et le premier joueur le dépassant perdra) ou des parties dites “longues” (où il ny aura pas de limite de temps global mais où on pourra définir une limite de temps entre chaque coup). Le joueur qui commence est celui qui possède les pièces blanches, puis cest au tour du joueur possédant les pièces noires etc...
\subsection{But du projet et intérêts}
Il sera dabord nécessaire de définir la manière la plus efficace et la moins coûteuse avec laquelle nous représenterons la table de jeu (à savoir une grille carrée de 8 cases de côté soit 64 cases). Il est possible dutiliser un tableau, des listes chaînées…
Lutilisation de la technologie objet sera utile pour manipuler les différentes pièces du jeu (pions(8 x2), tours(2 x2), fous(2 x2), cavaliers(2 x2), roi (x2), reine (x2) …) en définissant par exemple des classes pour chaque catégorie de pièces et même des héritages (on peut imaginer que la classe Reine hérite de la classe Roi).
Il nous faudra aussi définir les différents déplacements et coups existants (roque…) ainsi que les issues possibles (echec et mat, pat…).
Les possibilités de mouvement de chaque joueur devront être calculées à chaque tour en fonction de la pièce considéré et de sa position sur le plateau, cest pourquoi il est nécessaire de mettre à jour la position de chaque pion à chaque étape du jeu en lui affectant, par exemple, des coordonnées, dans un plan quon définirait par défaut. Seront aussi à définir par défaut le type de jeu et la durée. Enfin lattribution de la couleur des pièces (blanc ou noir) sera déterminée arbitrairement avec un tirage au sort au début du programme.
\subsection{Difficultés}
Le risque dans la programmation dun jeu d'échecs est le coût de chaque opération (calcul de la trajectoire et des coups) qui risque de rendre un peu long lexécution du programme et pouvant donner une complexité très grande si elles ne sont pas optimisées. \\
Enfin il y a toujours une difficulté concernant linterface graphique que nous devrons utiliser pour modéliser le jeu (avec éventuellement, si le temps le permet, la création dun chat ou autre interface interactive pour que les deux joueurs puissent communiquer entre eux).
\newpage
\section{Pac-Man}
\begin{figure}[ht!]
\centering
\includegraphics[width=7cm]{pacman.jpg}
\end{figure}
Pac-Man est un jeu darcade ou le but du joueur est de récupérer tous les points situés sur la carte avant de se faire attraper par les fantômes.
Le premier objectif de ce projet serait de créer le jeu avec ses principales fonctionnalités.
Un second objectif pourra être de permettre à un utilisateur de créer un bot qui remplacera les contrôles lutilisateur.
\subsection{Règles}
Pac-Man peut se déplacer comme bon lui semble sur la carte sans sortir des chemins. Les quatre fantômes peuvent également se déplacer sur toute la carte mais ils nont pas le droit de faire de demi-tours. Ils ont chacun leurs propres méthodes dattaques.
Blinky (rouge) est le fantôme qui poursuit simplement Pac-Man. Pinky (rose) cible quatre unités de distance devant Pac-Man. Inky (cyan) cible la localisation opposée à Blinky par rapport à celle de Pac-Man. Le dernier, Clyde (orange) cible Pac-Man mais lorsquil est trop près de ce dernier, il fuit vers son coin.
Sur la carte, y sont disposé quatre super Pac-Gomme. Lorsque Pac-Man en mange une, les fantômes passent en mode panique. Ce mode panique les fait prendre des directions aléatoires pendant quelques secondes ou jusquà ce quils se fassent manger par Pac-Man. Dans ce cas, il retourne à leur zone dapparition pour finalement réattaquer Pac-Man.
\subsection{Intérêts}
Dans ce projet, il va falloir générer le plateau de jeu et veiller à ce que les différentes entités respect bien les la forme du plateau.
Il faudra créer deux types dentités mais aussi des sous-types pour les fantômes. La création dun algorithme de path-finding sera nécessaire pour générer les déplacements des fantômes.
\newpage
\section{Simulateur graphique de circuits logiques}
\begin{figure}[ht!]
\centering
\includegraphics[width=7cm]{logisim.png}
\end{figure}
Ce projet vise à créer un programme permettant de simuler un circuit logique dont la construction se ferait graphiquement. Dans le style de Logisim \cite{logisim} l'utilisateur aurait à sa disposition une boite à outil pour poser des portes logiques et un outil pour tracer les liaisons.
\subsection{Objectifs et intérêts}
Lutilisation de la technologie objet se prête bien à ce projet pour définir et utiliser les différentes portes logiques. Par exemple, chaque porte aura plusieurs entrée et sorties, celles-ci pourrons être représentées en code par des attributs associés à des objets "liaison".
\subsection{Difficultés}
La première difficulté provient de l'interface graphique, puisque l'utilisateur doit avoir la possibilité de placer sur un plan de travail n'importe quel type de portes logiques (drag and drop). De même il devra pouvoir piloter des entrées manuelement, mais aussi pouvoir paramétrer des horloges, de la RAM/ROM\dots
\newpage
\section{Outil d'aide à la prise de décision dans le cadre de l'épidémie de COVID-19}
Le but d'un tel outil serait de générer, à partir de données actuelles sur l'épidémie de coronavirus (extraites sous la forme d'un fichier json), un rapport concis synthétisant ces données et étudiant plusieurs scénarios possibles. Il pourrait alors être intéressant d'envisager la formulation d'un conseil sur les mesures à prendre parmi un panel d'options (couvre-feu, aucune mesure ou encore confinement strict) .
\subsection{Jalons du projet}
Il est à noter qu'un tel projet nécessite des connaissances importantes en modélisation ainsi qu'en épidémiologie et peut paraître très ambitieux. Une première phase sera alors dédiée à la recherche. Une deuxième phase sera la définition du modèle à employer avec une première version utilisant des hypothèses simplificatrices. Ainsi nous envisagerons par exemple le fait que deux individus se rencontrent de façon aléatoire (alors qu'un individu choisit évidemment ses fréquentations), le fait que les distanciations sociales sont parfaitement respectées ou encore la non prise en compte des variants du virus existants. D'autres hypothèses pourront être formulées par la suite.
Une troisième phase du projet sera de supprimer les hypothèses formulées pour avoir un modèle plus proche de la réalité.
\subsection{Description du modèle}
Afin que notre modèle soit le plus représentatif possible de la réalité nous pourrons adopter des modèles déjà existants comme celui du SIR (Suspectible Infectious Recovered) dans lequel la population est divisée en 3 catégories. La première peut être contaminée, la deuxième est infectée et la troisième est guérie. Ce modèle prend aussi en compte le taux de propagation du virus appelé Radius, plus celui-ci est élevé et plus un individu a de chances de transmettre le virus à une autre personne.
Pour un modèle plus complexe il faudra considérer le cas des personnes asymptomatiques pour faire une quatrième catégorie au sein de la population et prendre en compte d'autres paramètres comme le non respect de la distanciation par exemple.
\subsection{Scénario a étudier}
Une fonctionnalité à implémenter sera la mise en quarantaine des individus (contaminés ou non) pour pouvoir étudier les effets de différentes mesures déjà évoquées. Cette fonctionnalité pourra être développée de façon incrémentale en envisageant des périodes de plus en plus éloignées (si possible) tel que J+1, J+7 et J+ 10 par exemple.
\subsection{Réserves sur le projet}
Ce projet bien que très intéressant nous paraît assez ambitieux même avec une équipe de 6 dans la mesure ou nous manquons de connaissances en modélisation de population et de phénomènes.
\newpage
\begin{thebibliography}{9}
\bibitem{sagittarius}
Itch.io, Sagittarius, George Prosser \\
\href{https://gprosser.itch.io/sagittarius}{https://gprosser.itch.io/sagittarius}
\bibitem{n_body}
Wikipedia, n-body problem \\
\href{https://en.wikipedia.org/wiki/N-body\_problem}{https://en.wikipedia.org/wiki/N-body\_problem} \\
\href{https://en.wikipedia.org/wiki/Three-body\_problem}{https://en.wikipedia.org/wiki/Three-body\_problem}
\bibitem{rt_calc}
Wikipedia, Verlet integration \\
\href{https://en.wikipedia.org/wiki/Verlet\_integration}{https://en.wikipedia.org/wiki/Verlet\_integration}\\
\href{https://gamedev.stackexchange.com/a/41917}{https://gamedev.stackexchange.com/a/41917}
\bibitem{rk4}
Wikipedia, Runge Kutta methods \\
\href{https://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods}{https://en.wikipedia.org/wiki/Runge-Kutta\_methods}
\bibitem{logisim}
Logisim \\
\href{http://www.cburch.com/logisim/}{http://www.cburch.com/logisim/}
\end{thebibliography}
\end{document}

0
gradlew vendored Executable file → Normal file
View file