Ajout des TPs

web/docs/03-tps/01-Correction.md

@@ -0,0 +1,162 @@
+# Correction
+
+## Pondération
+Chaque TP représente 20% de la note final
+
+## Évaluation du projet (Évaluation d’équipe)
+### Fonctionnalités /10 – 5%
+Le projet est excellent.
+Les points énumérés dans l’énoncé ont pratiquement tous été complétés.
+Les fonctionnalités ont été réalisés avec une grande qualité.	Le projet est bien.  
+Les points énumérés dans l’énoncé ont été complétés en majorité et les fonctionnalités ont été réalisés avec une grande qualité.
+Ou les points énumérés dans l’énoncé ont pratiquement tous été complétés, mais le fonctionnement pourrait être mieux.	Le projet est passable.  
+Les points énumérés dans l’énoncé essentiels ont été complétés et les fonctionnalités ont été réalisés avec une grande qualité.
+Ou les points énumérés dans l’énoncé ont été complétés en majorité, mais le fonctionnement pourrait être mieux.	Le projet est très faible.  
+Les points énumérés dans l’énoncé essentiels n’ont pas été complétés.
+Ou la qualité des fonctionnalités était insatisfaisante.
+10 	8 à 9 	6 à 7 	0 à 5 
+
+## Évaluation du travail d'équipe (Évaluation d’équipe)
+### Travail d’équipe et utilisation des outils /10 – 3%
+Points importants pour l’évaluation
+•	DevOps
+o	Les features (US) sont présentes sur DevOps.
+o	Les tâches sont présentes et attribuées aux membres de l’équipe.
+o	Sprint est à jour avec les tâches et les US complétées.
+•	Git
+o	Git est utilisé selon les bons principes (1 branche par feature).
+o	Les commentaires des commits sont présents et descriptifs du changement dans le code.
+•	Déploiement
+o	Le projet est déployé.
+o	Le projet est mis à jour automatiquement.
+
+Le travail d’équipe et l’utilisation des outils sont excellents.
+Les points énumérés ont tous été complétés et sont de grande qualité.	Le travail d’équipe et l’utilisation des outils sont bien.  
+Les points énumérés ont été complétés en majorité avec une grande qualité.
+Ou les points énumérés ont pratiquement tous été complétés, mais la qualité pourrait être mieux.	 Le travail d’équipe et l’utilisation des outils sont passables.
+Les points énumérés essentiels ont été complétés avec une grande qualité.
+Ou les points énumérés ont été complétés en majorité, mais la qualité pourrait être mieux.	Le travail d’équipe et l’utilisation des outils sont très faibles.  
+Les points énumérés essentiels n’ont pas été complétés.
+Ou la qualité était insatisfaisante.
+10 	8 à 9 	6 à 7 	0 à 5 
+
+
+## Évaluation individuelle
+### Correction du code /10 – 12%
+Instructions particulières pour la correction du code
+Durant les 3 sprints vous devrez vous faire corriger 1 fois pour chaque partie (Angular, API et MVC). Vous pouvez choisir la partie que vous voulez pour chaque sprint, mais chaque partie sera corrigée qu’une fois durant la session.
+Exemple, vous vous faire corriger en Angular au sprint 1, pour les sprints 2 et 3, vous devrez vous faire corriger API et MVC.
+Pour la correction, vous devrez remettre une fonctionnalité, pour qu’une fonctionnalité soit considérée suffisante pour la correction, nous demandons qu’elle ait un minimum de validation. Il sera important aussi de valider l’enseignant la fonctionnalité que vous souhaitez vous faire corriger.
+Points importants pour l’évaluation
+
+## Angular
+o	Découplage vue code
+o	Il n'y a pas de traitement dans les vues
+o	Structure du projet client
+o	Appels HTTP regroupés (service)
+o	Structure et noms homogènes et standards
+o	Lisibilité du code (1 fonction < 1 page, etc.)
+o	Stabilité
+o	Crash application
+o	Données toujours à jour
+o	Sécurité
+o	Gestion de l'utilisateur
+o	Utilisation des données du joueur
+o	Manipulation des données de la partie
+o	Interface utilisateur
+o	Messages d'erreur (indique clairement une solution)
+## Web API
+o	Persistance des données
+o	Utilisation d'Entity Framework et des services
+o	Modélisation des données
+o	Gestion des droits d'accès
+o	Accès aux données
+o	Code serveur
+o	Validation des données
+o	Définition d'exceptions appropriées
+o	Tests serveur
+o	Stratégie de test
+o	Couverture complète de la fonctionnalité
+o	Tester les cas limites du type et de la logique
+o	Tester les exceptions
+o	Structure du code / standards
+o	Découpage en couches
+o	Lisibilité du code (1 fonction < 1 page, commentaires etc.)
+o	Structure et noms homogènes et respect des standards
+o	Code factorisé (Réutilisation du code, encapsulation, dépendances minimales)
+o	Utilisation adéquate de l'injection de dépendance
+o	Utilisation appropriée des types abstraits et des interfaces
+## MVC
+o	Persistance des données
+o	Utilisation d'Entity Framework et des services
+o	Gestion des droits d'accès
+o	Code serveur
+o	Validation des données
+o	Définition d'exceptions appropriées
+o	Tests serveur
+o	Stratégie de test
+o	Couverture complète de la fonctionnalité
+o	Tester les cas limites du type et de la logique
+o	Tester les exceptions
+o	Structure du code / standards
+o	Découpage en couches
+o	Cohabitation avec Web API
+o	Lisibilité du code (1 fonction < 1 page, commentaires etc.)
+o	Structure et noms homogènes et respect des standards
+o	Code factorisé (Réutilisation du code, encapsulation, dépendances minimales)
+o	Utilisation adéquate de l'injection de dépendance
+o	Utilisation appropriée des types abstraits et des interfaces
+o	Découplage vue code
+o	Il n'y a pas de traitement dans les vues
+o	Stabilité
+o	Crash application
+o	Données toujours à jour
+o	Interface utilisateur
+o	Messages d'erreur (indique clairement une solution)
+La qualité du code est excellente.
+Les points énumérés ont tous été complétés et sont de grande qualité.	La qualité du code est bien.  
+Les points énumérés ont été complétés en majorité avec une grande qualité.
+Ou les points énumérés ont pratiquement tous été complétés, mais la qualité pourrait être mieux.	La qualité du code est passable.
+Les points énumérés essentiels ont été complétés avec une grande qualité.
+Ou les points énumérés ont été complétés en majorité, mais la qualité pourrait être mieux.	La qualité du code est très faible.  
+Les points énumérés essentiels n’ont pas été complétés.
+Ou la qualité était insatisfaisante.
+10 	8 à 9 	6 à 7 	0 à 5 
+
+
+## Remise du TP
+•	Vous devrez faire 2 remises sur Léa
+•	Une remise par équipe, vous devrez faire un zip avec :
+o	Angular
+o	C#
+o	URLs (frontend et backend) du projet déployé
+•	Vous devrez ajouter votre enseignant à Azure DevOps
+o	[email protected]
+•	Vous devrez également ajouter votre enseignant à vos repos GitHub
+o	[email protected] ou jmnadeau
+•	Une remise individuelle, vous devrez faire un zip avec :
+o	Un document texte avec la description de votre feature, vous devrez dire quelle page ou quel contrôleur vous voulez que votre enseignant corrige.
+o	L’application à corriger (client ou backend), votre application pourrait être différente de la version de l'équipe
+
+Pour la remise individuelle
+Il doit avoir de la validation à votre partie de code pour qu’elle soit suffisante pour la correction.
+Voici quelques exemples de features qui seraient suffisantes pour la correction :
+•	En Angular
+o	Enregistrement et connexion
+o	Consommer les évènements de la partie
+o	Gestion de la boucle de jeu
+	 (Alterner entre le polling pour mettre à jour le match et jouer une carte de sa main)
+•	En Web API
+o	Les combats et la génération des évènements
+o	AccountController, 
+	Si vous faites corriger AccountController, le contrôleur doit également inclure l'initialisation du joueur
+•	MVC
+o	Les outils d’administration
+	(Si vous avez fait une page pour arrêter les parties en cours, voir l’utilisateur en attente d’une partie, etc.)
+o	Gestion des cartes de départ
+
+Tests unitaires
+•	Tester uniquement le backend
+•	Tester uniquement le / les services utilisé par la feature
+	Utiliser une InMemoryDatabase pour réaliser les tests
+•	Les tests doivent couvrir 100% des méthodes utilisées dans les services

web/docs/03-tps/01-tp1.md

@@ -1 +1,46 @@
-# TP1
+# TP1 (Super Cartes Infinies)
+
+## L'application
+
+### Objectifs : 
+- Créer un application web à l’aide d’Angular, Web API et MVC pour faire un jeu de carte.
+- Le site Angular sera utilisé par des membres inscrits. 
+- L’administrateur pourra configurer le contenu de l’application à l’aide de MVC.
+
+### Les règles :
+- Deux joueurs s’affrontent tour à tour et joue une carte chacun par tour. 
+- Chaque carte a une certaine quantité de points d’attaque et une certaine quantité de points de défense.
+- Après avoir joué une carte, toutes les cartes présente du jouer attaque une carte de l’adversaire.
+- Chaque attaque diminue les points défense de la carte ciblée jusqu’à ce que la carte n’ait plus de points de défense.
+- Chaque joueur à un certain nombre de points de vies, lorsque qu’un joueur n’a pas de carte en jeu pour se défendre, il reçoit des dégâts qui font descendre ses points de vie.
+- Le premier joueur à ne plus avoir ne points de vie perds la partie.
+
+## Le détail des sections
+### Section d’administration
+- L’administrateur peut créer, modifier, voir et supprimer une carte.
+- L’administrateur peut modifier les cartes de départ des nouveaux joueurs.
+
+### Carte
+- Une carte doit avoir une valeur d’attaque et une valeur en défense.
+- Les cartes peuvent être triés pour être plus faciles à repérer.
+
+### Utilisateur
+- Un nouvel utilisateur doit obtenir un paquet de carte de départ.
+Partie
+- Un utilisateur peut jouer contre un autre utilisateur présent.
+- Chaque utilisateur doit jouer une carte par tour.
+- Chaque carte en jeu doit attaquer une autre carte à chaque tour et ainsi enlever des points de points de défense à l’autre carte.
+- Une carte n’ayant plus de points de défense doit être retirée du jeu.
+- Si l’adversaire n’a plus de carte en jeu, il se fera attaquer par la carte et il perdra des points de vie.
+- Chaque action des utilisateurs doit être envoyée au serveur pour que l’autre joueur puisse récupérer l’action effectuée.
+
+## Contraintes
+- Le travail doit être effectué en équipes de 4.
+- Vous devrez utiliser Git.
+- Vous devrez utiliser DevOps pour la gestion des tâches.
+- Vous devrez déployer votre application sur Azure.
+- Vous devrez faire une application cliente en Angular.
+- Vous devrez faire une application serveur en ASP.NET Web API.
+- Vous devrez faire une section d’administrateur sur votre serveur en MVC.
+- Vous devrez faire des tests unitaires pour l’utilisation des services.
+- Vous devrez ajuster les tests unitaires du « gameplay » pour qu’il fonctionne.

web/docs/03-tps/02-tp2.md

@@ -1 +1,94 @@
-# TP2
+# TP2 (Suite de Super Cartes Infinies)
+
+## L’application
+
+### Objectifs : 
+Ajouter des fonctionnalités au jeu de cartes développé lors du Sprint 1.
+
+
+:::info
+
+	Si vous n’avez pas réussi à compléter une partie du TP1, regardez avec votre enseignant pour savoir comment faire le TP2 sans devoir travailler en double.
+:::
+
+### Les nouvelles règles de jeu :
+- Chaque carte prend un tour avec d’être activé (Ce que l’on appelle habituellement le « summoning sickness »).
+    - Cependant, elle peut déjà se défendre dès qu’elle est en jeu.
+- Jouer plusieurs cartes par tour, selon un coût en « Mana ».
+    - Chaque carte à un coût en Mana différent.
+    - Lorsque le Mana n’est pas utilisé, il s’accumule pour le tour d’après.
+    - On doit pouvoir configurer combien de Mana les joueurs reçoivent chaque tour. Il faut ajouter un event GainManaEvent pour que les joueurs recoivent du Mana à chaque tour. Juste avant de piger leur nouvelle carte pour le tour. Optionnel: Vous pouvez donner un peu moins de mana au premier tour du premier joueur pour réduire l’avantage de jouer en premier.
+    - Il faut ajouter un bouton « terminer » qui permet de terminer son tour lorsque l’on ne veut plus jouer de cartes. Il faut également modifier l’action PlayCard sur le serveur et ajouter une action EndTurn qui permet de terminer son tour.
+
+- Ajouter des habilités à certaines cartes. On pourra donc associer une liste d’habiletés à nos cartes en MVC. (On parle ici de la classe Carte). La liste d’habiletés disponible n’a pas besoin d’avoir son propre UI et vous pouvez simplement utiliser un seed. Les habiletés doivent avoir :
+    - Un nom
+    - Une icône
+    - Une valeur entière (optionnelle)
+- Il faut pouvoir voir les habiletés d’une carte sur le client
+- Il faut faire une animation lorsqu’une habileté est utilisé sur le client. Vous pouvez simplement montrer l’icône de l’habileté au-dessus de la carte pour un moment ou faire quelque chose de plus complexe si vous préférez.
+- Mélanger les cartes dans le CardsPile pour ne pas toujours commencer avec les mêmes cartes.
+- Il y a 4 habiletés (Power) que vous devez ajouter et vous devez en créer 2 autres à votre choix.
+    - « First Strike » permet à une carte d’attaquer en « premier » et de ne pas recevoir de dégât si elle tue la carte de l’ennemie. (Fonctionne uniquement à l’attaque, pas à la défense)
+    - « Thorns X» lorsqu’une carte défend, elle inflige X de dégâts AVANT de recevoir des dégâts. Si l’attaquant est tué par ces dégâts, l’attaque s’arrête et le défenseur ne reçoit pas de dégâts.
+    - « Charge » permet à une carte d’être activé le même tour où elle est jouée (donc de faire comme c’était le cas dans le tp1).
+    - « Heal X» soigne les cartes alliées de X incluant elle-même AVANT d’attaquer (mais les cartes ne peuvent pas avoir plus de points de vue qu’au départ.) 
+- Note sur les habiletés à votre choix. Pour l’instant, les pouvoirs proposés ne nécessitent pas de garder un « état ». C’est conseillé de choisir des habiletés sans état pour le TP2. Lors du TP3, nous allons exiger des pouvoirs avec un état. Un exemple d’habiletés avec état, c’est « Poison X » qui inflige des dégâts à chaque tour. Dans ce cas, il faut pouvoir ajouter un état « empoisonné » sur CardInstance. (Si vous n’arrivez pas à trouver des idées d’habiletés simples à ajouter, faites signe à votre prof.)
+
+
+## Le détail des sections
+### Section d’administration
+- L’administrateur peut ajouter et retirer des cartes en ventes au magasin, ainsi que de modifier leur prix.
+- L’administrateur peut choisir le prix rachat des cartes (le prix lorsqu’un joueur vend une carte).
+- L’administrateur peut modifier les contraintes des « Decks ». Il peut configurer le nombre de « Decks » maximum d’un joueur et le nombre de carte dans chaque « Deck ».
+- L’administrateur peut choisir la quantité de monnaie virtuelle du jeu qu’un joueur gagne à chaque partie pour une victoire et pour une défaite.
+### Deck
+- Un utilisateur doit créer au moins un Deck (paquet de cartes).
+- Un deck doit avoir un nom
+- Un utilisateur doit choisir quel Deck il apporte dans la partie. Pour la sélection du deck, utiliser la première carte du Deck comme image en plus du nom.
+- Seul les cartes du Deck sont disponibles lors d’une partie.
+- Une même carte peut faire partie de plusieurs decks.
+### Magasin
+- Les joueurs peuvent acheter et vendre des cartes avec une monnaie virtuelle dans le jeu.
+- Les cartes peuvent être achetées et vendues à l’unité.
+### Partie
+- À chaque partie, un joueur gagne de la monnaie virtuelle du jeu.
+    - Une victoire donnera plus de monnaie qu’une défaite.
+- Il sera possible d’abandonner une partie (Surrender).
+- Il sera possible d’abandonner la file d’attente pour jouer un match. (Mais si la partie avait déjà commencé, c’est trop tard!)
+- Lors de l’abandon, pas besoin de gérer les « race conditions » pour l’instant. Au TP3 on va utiliser des sémaphores pour protéger ce genre de situations.
+
+
+## Contraintes et TDD
+- Il faudra modifier les informations envoyées aux clients (JSON) à propos des parties pour ne pas révéler les cartes qui sont dans la main de notre adversaire.
+- Il faut ajouter des tests unitaires pour les nouveaux services pour la gestion des decks et l’achat et la vente des cartes.
+- Les nouvelles règles devront être programmées avec le principe TDD (Test Driven Development).
+- Les tests doivent être écrit par une personne et l’implémentation de la logique doit être fait par une autre personne. Quand vous allez remettre votre partie pour le TP2, vous pourrez vous faire évaluer pour avoir écrit les tests OU pour avoir écrit la logique de combat!
+- Au Sprint 1, vous aviez déjà les tests présents pour le combat, vous devrez maintenant les réaliser par vous-même. Il faut modifier les 3 tests de combats existants pour supporter les changements de règles.
+- Vous pouvez en ajouter PLUS, mais voici une liste des tests obligatoires :
+    - Impossible de jouer une carte si un joueur n’a pas assez de Mana
+    - Possible de jouer 2 cartes le même tour
+    - Possible de jouer 0 carte pendant un tour
+    - Test de l’habileté First Strike
+    - Test de l’habileté Charge
+    - Test de l’habileté Thorns X
+    - Test de l’habileté Heal X
+    - Test de l’habileté Heal X partiel (pas possible qu’un CardInstance est plus de health que sa Carte)
+    - Test de votre habileté au choix 1
+    - Test de votre habileté au choix 2
+
+## Tâches individuelles
+:::info
+Vous devez choisir une des tâches suivantes qui sera évaluer de façon individuelle. Vous devez écrire vous-même le code, mais vous pouvez collaborer avec vos collègues.
+:::
+
+:::warning
+Vous devez choisir quelque chose de différent du TP1. Donc vous ne pouvez pas reprendre la logique de combat si vous l’aviez déjà fait pour le premier TP, par exemple.
+:::
+
+- Écrire les tests pour le combat TDD. Voir la page précédente pour la liste de tous les tests requis.
+- Implémenter la logique pour le combat. Il faut faire passer tous les tests et valider que tout fait du sens.
+- Achat et vente des cartes Angular.
+- Toute la partie MVC.  Achat et vente des cartes et autres configurations (nombre de cartes par deck, nombre de decks, nombre de monnaie virtuelle à la création du compte, après une partie perdue et une partie gagnée.)
+- Gestion des decks Angular. Incluant la sélection du deck avant de joindre un match.
+- Tous les services. Ajouter les contrôleur, actions et services pour la gestion des decks et la vente et l’achat des cartes.  Avec des tests unitaires.
+- Traitement des évènements Angular. ATTENTION : Évitez de prendre cette option si votre jeu n’est pas déjà dans un très bon état après le TP1.