Retrait des TPs 2 et 3

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

@@ -1,97 +1,2 @@
 # TP2 (Suite de Super Cartes Infinies)
 
-## L’application
-
-## TODO:
-- Ajouter un diagramme de classes comme livrable
-
-### 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.

web/docs/03-tps/03-tp3.md

@@ -1,111 +1 @@
-# TP3
-
-## L’application
-
-## TODO:
-- Ajouter un diagramme de classes comme livrable
-
-### Objectifs : 
-Ajouter des fonctionnalités au jeu de cartes développé lors des Sprints 1 et 2.
-
-### Note importante :
-	Si vous n’avez pas réussi à compléter une partie du TP2, regardez avec votre enseignant pour savoir comment faire le TP3 sans devoir travailler en double.
-
-### Fonctionnement du 3e Sprint :
-	Pour le 3e Sprint, il n’y aura que 4 tâches à réaliser, chaque tâche devra être à attribuer à un coéquipier et il n’y aura pas d’autre tâche d’équipe supplémentaire.
-
-
-## Le détail des tâches individuelles
-### Achat de paquets de cartes dans le magasin
-- Ajouter une rareté aux cartes. Il doit y avoir 4 niveaux:
-    - Commune (Gris)
-    - Rare (Vert)
-    - Épique (Mauve)
-    - Légendaire (Orange)
-- Ajouter la possibilité de voir et changer la rareté d’une carte en MVC.
-- Sur le client, il faut afficher un code de couleur sur les cartes pour pouvoir voir leur rareté. Une option simple c’est de modifier la couleur de fond du titre.
-- Ajouter 3 paquets de cartes que les joueurs peuvent acheter. Les cartes sont obtenues au hasard, mais en suivant les règles suivantes.
-
-| Type | Rareté par défaut | Nb Cartes | Règles d’obtention des cartes (sinon c’est la rareté par défaut)
-| :--- | :----: | :----: | :----: |
-| Basic | Commune | 3 | 30% de rare
-| Normal | Commune | 4 | 1 carte rare. Pour le reste : 30% rare, 10% épique, 2% légendaire
-| Super	| Rare	| 5	| 1 carte épique. Pour le reste 25% épique, 10% légendaire. (Aucune commune)
-
-- Les paquets ont également un nom, une url d’image et un prix.
-- Sur le client, il faut afficher les différents paquets que le joueur peut acheter. 
-- Lorsque le joueur en achète un, il faut lui afficher les cartes qu’il vient de recevoir dans un Dialog. Il faut également mettre à jour son argent et ses cartes.
-- Le joueur ne peut pas acheter un paquet s’il n’a pas assez d’argent.
-- La configuration des paquets et des probabilités doit être fait dans un seed, ce n’est pas nécessaire de pouvoir les modifier en MVC.
-
-- Voici le pseudo code pour obtenir une liste de raretés pour notre paquet de carte
-
-```
-// Une Probability possède : une value (entre 0 et 1), une rarity et une baseQty
- 
-// Faire une liste de rareté de carte à obtenir
-List<Rarity> GenerateRarities(int nbCards, int defaultRarity, List<Probability> probabilities)
-    rarities = new List<Rarity>
- 
-    // Ajouter la quantité de base pour chaque probability à la liste
-    foreach(probability of probabilities)
-        for probability.baseQty
-            add probability.rarity to rarities
- 
-    // Continuer de remplir la liste jusqu'à atteindre la quantité voulue
-    while(rarities.Count < nbCards)
-        rarity = GetRandomRarity(probabilites)
- 
-        if(rarity == null)
-            add defaultRarity to rarities
-        else
-            add rarity to rarities
- 
-    return rarities
-
- 
-// Cette méthode permet d'obtenir une rareté au hasard
-Rarity? GetRandomRarity(List<Probability> probabilities)
-    X = Random Number Between 0 and 1
- 
-    for each rarity of probabilities:
-        if probability.value < X:
-            return probability.rarity
-        else:
-            X -= probability.value
- 
-    return null
-```
-
-- Une fois que l’on a une liste de rareté, on peut prendre une carte au hasard avec chacune des raretés pour faire notre paquet. Les doublons sont permis. 
-
-
-## Statistiques des joueurs
-- Un joueur aura la possibilité de voir des statistiques à propos de ses decks ou de l’ensemble de ses cartes
-    - Il pourra voir le nombre de victoire et défaites avec ce deck (ou général)
-    - La distribution des cartes (En utilisant des graphs similaires):
-        - Coût
-        - Rareté
-        - Attaque et défense
-    - Vous pouvez utiliser la technologie de graph que vous préférez, mais on propose la suivante : https://canvasjs.com/angular-charts/pie-chart-index-data-label/ 
-Lorsqu’on affiche l’ensemble des cartes:
-TODO: IMAGE DES STATS 1
-
-Lorsque l’on sélectionne un deck
- TODO: IMAGE DES STATS 2
-
-
-### Habilités supplémentaires
-- Il y aura l’ajout d’habilités pour les cartes qui vont modifier un état. 
-    - Poison X, qui ajoute une valeur de poison à la carte attaquée. Le poison diminue ensuite la vie d’une carte de la valeur du poison à la fin de son activation. Si une carte a déjà une valeur de poison et qu’elle est à nouveau attaquée, la valeur de poison est augmentée.
-    - Stunned X, qui empêche une carte d’agir pendant son activation durant X tours. (Mais elle reçoit quand même les dégâts de poison!)
-- Il y aura également l’ajout de cartes qui auront un effet immédiat et qui se déplaceront directement dans le « graveyard » par la suite (On n’attend pas la fin du tour).
-    - Lightning Strike X, fait X dégâts au joueur adverse. (Attention, c’est possible que la partie se termine)
-    - Earthquake X, fait X dégâts à TOUTES les cartes en jeu.
-- Il faut ajouter au moins un test complet pour chacun des pouvoirs. C’est une bonne idée de travailler en Test Driven Development et d’écrire les tests d’abord. Pour simplifier ce TP, le même programmeur va écrire les tests et la logique.
-
-### SignalR
-- Il faudra remplacer toutes les requêtes http du « gameplay » par l’utilisation de SignalR.
-    - Tout doit être remplacé, du polling réalisé pour JoinMatch, jusqu’à la fin de la partie. Le Hub doit donc fournir une méthode pour faire JoinMatch, Cancel, PlayCard, EndTurn et Surrender.
-    - L’action StartMatch, n’est plus nécessaire et peut être exécuté directement dans la méthode de Hub qui gère le JoinMatch.
-- SignalR devra utiliser Identity et Authorize dans le Hub pour restreindre l’accès aux utilisateurs connectés.
+# TP3 (Super suite de Super Cartes Infinies)