Newer
Older
# Projet tuteuré T2
Les étapes du projet tuteuré T2 sont les suivantes :
1. Consulter le groupe qui vous est attribué dans le document des groupes et le rejoindre.
2. Ecouter la présentation du jeu par les membres du groupe.
3. Dupliquer ce fichier d’évaluation dans leur GIT, en suivant la règle de nommage `Evaluation-T4-Prénom_Nom.md`.
4. Ajouter un lien vers ce fichier dans le document des groupes.
5. Jouer à leur jeu, et proposer des améliorations dans la section ci-dessous.
6. Lire le cahier des charges et faire des observations en utilisant la fonction commentaires.
7. Remplir la grille d'évaluation T4 ci-dessous, et remplir le résultat T4.
8. Faire remplir la grille d'évaluation T2 et le résultat T2 ci-dessous par les membres du T4.
## Grille d'évaluation T2 (à remplir par les membres du groupe T4)
- Procédure
- [x] La procédure a été suivie à la lettre sans le moindre écart.
- [ ] La procédure a été globalement suivie.
- [ ] La procédure n'a pas été bien suivie.
- Propositions d'amélioration du jeu
- [x] Au moins trois propositions d'améliorations pertinente sont faites.
- [ ] Au moins trois propositions d'améliorations sont faites.
- [ ] Moins de trois propositions d'améliorations sont faites.
- Propositions d'amélioration du Cahier des charges
- [x] Au moins cinq propositions d'améliorations pertinente sont faites.
- [ ] Au moins cinq propositions d'améliorations sont faites.
- [ ] Moins de cinq propositions d'améliorations sont faites.
- Grille d'évaluation T4 / critères
- [x] Tous les critères sont remplis avec pertinence et font l'objet d'une justifications concrète.
- [ ] Certain critères ont été remplis un peu à l'arrache.
- Implication
- [ ] L'implication T2 été vraiment été cruciale dans le processus du T4.
- [x] L'implication T2 a permis d'améliorer le T4.
- [ ] Il y a eu un défaut d'implication T2.
### Résultat T2
- Total d'item « Excellent » (2 point) :
- Total d'item « Satisfaisant » (1 point:
- Total d'item « Insatisfaisant » (0 point) :
- Note sur 10 :
# Propositions d'amélioration du jeu
- Rajouter des niveaux de difficultés au jeu. Proposer, par exemple, 3 villes existantes (Exemple: Strasbourg, Paris, Marseille) avec 3 niveaux de difficultés différents, et une démographie différente (par exemple plus de personnes agés dans une ville)
- Faire que les batiments / constructions agissent autours d'eux, et pas sur toute la ville (il n'est pas cohérent qu'un parc agisse sur 5km), et pouvoir visualiser les rayons d'actions des constructions.
- Rajouter une description de chaque batiments avec la démographie cible (permettant donc au joueur de savoir ce qu'il fait).
- Résoudre les quelques bugs (double jump, crashes, ... )
# Propositions d'amélioration du CDC
- Rajouter une description claire de l'organisation attendue du projet.
- MCD ?
- Description plus claire des fonctionnalités du jeu
- Description du système de placement
- Description de l'impact de chaque batiments
- Description du calcul du score et de la population satisfaite / insatisfaite.
- Rajouter les descriptions des scénarios dans le CDC
# Grille d'évaluation T4
## GIT
- Organisation
- [x] Les fichiers sources suivent une organisation et des règles de nommage clairement établie.
- [ ] Les fichiers sources sont tous partagés et organisés.
- [ ] Certains fichiers sources ne sont pas partagés ou leur organisation laisse à désirer.
- Versioning
- [ ] La granularité des commits est pertinente et les commits sont clairement et systématique renseignés.
- [x] La granularité des commits n'est pas pertinente ou les commits ne sont pas clairement et systématiquement renseignés.
- [ ] La granularité des commits n'est pas pertinente et les commits ne sont pas clairement et systématiquement renseignés.
- [x] Julien Gossa a le rôle avec le plus de droits sur le dépôt GIT et ce dépôt est accessible à tous.
- [ ] Julien Gossa a le rôle avec le plus de droits sur le dépôt GIT.
- [ ] Julien Gossa n'a pas le rôle avec le plus de droits sur le dépôt GIT.
- [x] Le README est complet, avec : une présentation du projet, la procédure d'installation et d'exécution, et des captures d'écran du jeu.
- [ ] Le README n'est pas complet.
- [x] Le CDC est conforme au document partagé de travail, et les deux sont liés depuis le README.
- [ ] Le CDC est conforme au document partagé de travail, ou les deux sont liés depuis le README.
- [ ] Le CDC n'est oas conforme au document partagé de travail, et les deux ne sont pas liés depuis le README.
L'organisation des fichiers sources est spécifique à Unity, je n'aime personellement pas cette organisation mais elle a le mérite d'être claire. Il aurait été une bonne idée d'ajouter un gitignore pour ne pas avoir le build dans le projet, et mettre le build à part, en tant que release sur gitlab.
La granularité des commits semble pertinente, mais ils n'ont pas de règle de nommage claire, certains ont des noms brouillons. Les droits d'accès sur le repo ont l'air d'être bien gérés.
Le README semble complet, avec une présentation claire du jeu, et le CDC est complet.
## Prototype
- Installation
- [ ] Le prototype s'installe sans effort.
- [x] Le prototype s'installe en suivant une procédure.
- [ ] Le prototype ne s'installe pas.
- Exécution
- [ ] Le prototype s'exécute en cliquant sur une icône.
- [x] Le prototype s'exécute en suivant une procédure.
- [ ] Le prototype ne s'exécute pas
- Stabilité
- [ ] Le prototype est parfaitement stable
- [ ] Le prototype est rarement instable
- [x] Le prototype est instable
- Affordabilité
- [ ] Toutes les instructions de jeu sont inclues dans le prototype sous forme d'un tutoriel.
- [x] Les instructions de jeu sont sous forme d'un manuel.
- [ ] Les instructions de jeu ne sont pas données.
- Transmission du concept
- [ ] Le prototype permet de parfaitement transmettre le concept-cible au joueur.
- [x] Le prototype permet de transmettre le concept-cible au joueur.
- [ ] Le prototype ne permet pas de transmettre le concept-cible au joueur.
L'installation du prototype (sous linux en tout cas) nécessite l'installation de wine (pas de build linux spécifique), mais le jeu semble fonctionner aussi bien dans wine que sous windows. Le prototype s'execute simplement avec wine. Cepandant, il n'est pas stable :
- Réussi à le faire crash plusieurs fois (notament avec le bouton "fin de partie" ou en modifiant la résolution / fenétré / fullscreen)
- Possibilité de double jump (détail, mais présent quand-même)
- Réussi à me bloquer plusieurs fois dans le mur invisible à gauche de la map
- Quand on perds une game, celles joués après sont obligatoirement perdues (oublie de réinitialiser les états en début de partie ?)
## Cahier des charges
- Modèle de document
- [ ] Le CdC respecte parfaitement le modèle de document.
- [x] Le CdC respecte globalement le modèle de document.
- [ ] Le CdC ne respecte pas le modèle de document.
- Description de l'application
- [ ] La description permet de se faire une idée précise et exhaustive de l'application attendue.
- [x] La description permet de se faire une idée de l'application attendue.
- [ ] La description ne permet pas de se faire une idée de l'application attendue.
- Modèle conceptuel
- [ ] Le modèle conceptuel applicatif (MCD ou digramme de classe) est exhaustif et détaillé.
- [ ] Le modèle conceptuel applicatif (MCD ou digramme de classe) est donné.
- [x] Le modèle conceptuel applicatif (MCD ou digramme de classe) n'est pas donné.
Justifications :
Le CDC permet de se faire une bonne idée du résultat attendu, et respecte globalement le modèle. Je n'ai pas réussi à trouver de MCD sur le git.
### Fonctionnalités
- Entrées / Actions du joueur
- [ ] La description des entrées permet de connaitre parfaitement les interactions avec l'application.
- [x] La description des entrées permet de se faire une première idées des interactions avec l'utilisateur.
- [ ] La description des entrées ne pas permet pas de se faire une première idées des interactions avec l'utilisateur.
- Sorties / Infomations au joueur
- [ ] La description des sorties permet de connaitre parfaitement les interactions avec l'application.
- [x] La description des sorties permet de se faire une première idées des interactions avec l'utilisateur.
- [ ] La description des sorties ne pas permet pas de se faire une première idées des interactions avec l'utilisateur.
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
- Description du moteur interne
- [ ] La description du moteur interne permet de comprendre parfaitement le fonctionnement de l'application.
- [ ] La description du moteur interne permet de comprendre le fonctionnement de l'application.
- [x] La description du moteur interne ne permet pas de comprendre le fonctionnement de l'application.
- Découpage modulaire
- [ ] L'application est couverte par des modules pertinents et pleinement décrits.
- [ ] L'application est découpée en modules pertinents.
- [x] L'application n'est pas découpée en modules pertinents.
- Granularité des fonctionnalités
- [ ] Les fonctionnalités sont très fines.
- [ ] Les fonctionnalités sont fines.
- [x] Les fonctionnalités sont grossières.
- Exhaustivité des fonctionnalités
- [ ] Les fonctionnalités couvrent la totalité de l'application.
- [ ] Les fonctionnalités couvrent globalement l'application.
- [x] Les fonctionnalités ne couvrent pas l'application.
- Description des fonctionnalités
- [ ] Les fonctionnalités sont précisément décrites.
- [ ] Les fonctionnalités sont décrites.
- [x] Les fonctionnalités ne sont pas bien décrites.
- Priorisation des fonctionnalités
- [ ] Les fonctionnalités sont classées par priorités de façon pertinentes.
- [ ] Les fonctionnalités sont classées par priorités.
- [x] Les fonctionnalités ne sont pas classées par priorités.
- Difficulté des fonctionnalités
- [ ] Les fonctionnalités sont annotées par une difficulté pertinente.
- [ ] Les fonctionnalités sont annotées par une difficulté.
- [x] Les fonctionnalités ne sont pas annotées par une difficulté.
Justifications :
La description des E/S permet de se faire une idée de l'intéraction avec le joueur. Cepandant, elle n'est pas assez claire et ne permet pas de bien se représenter le jeu. L'application n'est pas dutout modulaire, et la description des fonctionnalités est absente.
### Scénarios
- Nombre
- [ ] Au moins un scénario est pleinement développé et propose au moins deux alternatives.
- [x] Un scénario est pleinement développé.
- [ ] Un scénario n'est pas pleinement développé.
- Exhaustivité
- [ ] Le scénario développé s'appuie sur toutes les fonctionnalités.
- [x] Le scénario développé s'appuie sur toutes les fonctionnalités principales
- [ ] Le scénario développé ne s'appuie pas sur toutes les fonctionnalités principales.
- Scénarios additionnels
- [ ] Des scénarios additionnels sont proposés, en expliquant leur intérêret.
- [ ] Des scénarios additionnels sont proposés.
- [x] Des scénarios additionnels ne sont pas proposés.
Justifications :
Le scénario principal est pleinement développé, et s'appuie sur les fonctionnalités principales, aucun scénario additionnel n'est proposé. Il aurait été une bonne idée de rajouter, par exemple, des niveaux de difficultés ou différentes villes.
- Total d'item « Insatisfaisant » (0 point) : 9
- Note totale : 19