Table of Contents

Design Patterns en action

Voici quelques exercices simples mettant en jeu quelques DPs.

Partie 1

On souhaite modéliser le fonctionnement d’un jeu comportant différents types de personnages : des humains (nom + couleur des yeux), des trolls (nom + nom bière préférée), des orcs(nom + taille des oreilles) et des Taurens (nom + taille de la corne)..

Les personnages savent se battre en utilisant des armes qui peuvent être des dagues, des épées et des boucliers. Une arme a une force d'attaque et une force protectrice 1) Pour l'instant on considère ces forces comme des constantes :

Au début de sa vie un personnage a un coefficient de vitalité de 100. Il est affaibli au cours de sa vie, ce qui réduit son coefficient de vitalité.

L’utilisateur du jeu doit avoir la possibilité d’ordonner à un personnage (A) de se battre contre un autre (B). Celui qui est attaqué (B) voit sa vitalité décroitre d'un coefficient qui correspond à la force de l'attaquant (force de son arme) - sa propre force protectrice (force protectrice de son arme).

A un moment donné du jeu, un personnage ne manipule qu’une seule arme, au moins dans un premier temps. Cependant, il peut changer d’arme plusieurs fois au cours du déroulement du jeu.

On suppose que chaque personnage est associé à une arme par défaut (Orcs : épée ; Troll : dague ; Tauren : bouclier, Humain : épée).

Modélisez, codez et testez vos classes y compris avec le scénario suivant : 

   - Créer un personnage nommé « Diablon » de type « Tauren » avec une corne de 15 cm;
   - Créer un personnage nommé « Azag» de type « Orc » avec des oreilles de 5 cm;
   - L’utilisateur demande à Diablon d'attaquer Azag, cela n'a aucun effet;
   - L’utilisateur demande à Azag d'attaquer Diablon, qui perd 5 points de vitalité;
   - L’utilisateur crée un personnage nommé « ArKor» de type « Troll », bière préférée « Heineken ».
   - etc.

Extensions à ne faire que si les autres parties sont finies

DP Décorateur

Nous n'avons pas vu en cours le DP décorateur. Dans ce qui suit, c'est ce pattern qui semble le plus adapté. Saurez-vous implémenter un DP décorateur ?

En fonction du jeu, il est possible d'améliorer les armes en leur associant un amplificateur ou une force protectrice supplémentaire, de coefficient donné (opération plus). Il est également possible d'enchanter une arme ce qui a pour effet de multiplier la puissance de frappe et protectrice par un coefficient fonction du sortilège. On veut pouvoir ainsi ajouter en fonction des jeux que nous diffuserons différentes manières d'“améliorer” les armes (les rendre invisibles, leur donner une puissance seulement pendant un temps donné, leur puissance dépend de l'état du jeu, etc.)

Ces armes modifiés sont manipulables comme des armes normales.

exemple de scénario :

  1. On modifie l'arme associée à Diablon en la rendant magique avec un coefficient de 2;
  2. Diablon attaque Azag qui perd 5 points de vitalité;
  3. On modifie l'arme associée à Diablon en lui ajoutant un amplificateur de coefficient 3;
  4. Diablon attaque Azag qui perd 8 points de vitalité;
  5. ….

Facultatif : On aimerait à présent que la force d'une arme soit proportionnelle à la vitalité de l'attaquant et la force protectrice proportionnelle à la vitalité de celui qui reçoit le coup.

Remarques :

  • que se passe-t-il si un personnage est attaqué avec une force inférieure à sa capacité à se protéger?
  • quelles sont les conséquences d'un ordre différent d'applications des “décoration” ?

Partie 2

Au fur et à mesure que le jeu est mis sur le marché, pour “créer du hype”, on veut pouvoir ajouter de nouvelles armes, sans modifier l'ensemble du jeu. L'idée est de :

  1. ne pas modifier les classes d'armes définies précédemment;
  2. pouvoir créer des armes à partir de leur type et avec un nom donné (ex: créer une épée de nom excalibur);
  3. retrouver une arme à partir de son nom;

exemple de scenario de test : 

        WeaponFactory wf = new WeaponFactory();
        Weapon w = wf.createWeapon("SWORD","excalibur");

8-o Les Personnages au début sont créés en fonction des classes d'armes prévues. Modifiez votre code pour ne plus dépendre de ces classes d'implémentation.

Question : 1) Est-ce que vous pouvez avoir une fabrique par Joueur? 2) Si une fabrique ne peut pas créer plus qu'un nombre donné d'épées, vous savez le gérer?

Partie 3

On désire pouvoir manipuler des personnages individuels et également des groupes tels que des armées, des bataillons ou des hordes.

La force d'une attaque

  1. par une horde est la somme des forces de chacun des personnages qui constituent la horde, multipliée par 0.75.
  2. par un bataillon est la somme des forces de chacun des personnages qui constituent le bataillon, multipliée par 1,5.
  3. par une armée est la somme des forces de chacun des éléments qui constituent l'armée. Une armée est composée de généraux (personnages individuels) et de bataillons.

De même pour la puissance protectrice.

Attention, ceci n'est qu'un début dans le futur nous associerons aux groupes des véhicules (chars, …) qui auront leur propre force.

Partie 4

Un personnage peut passer par différents états.

Il est vivant. Au début tous les personnages sont vivants. Un personnage passe dans un état faible lorsqu'il n'a plus qu'une force de 25 points de vitalité. Il est mort lorsque ses points de vitalité sont à 0.

Un personnage faible lorsqu'il est attaqué, voit sa force protectrice réduite de (1-1/points de vitalité). Ainsi si un personnage faible est attaqué il perdra : <force de l'arme de l'attaquant> - (<sa force protectrice> (1-1 / <sa propre vitalité> ))

Si le personnage est mort et qu'il est attaqué, il ne se passe rien.

exemple : Personnage de vitalité 20 de protection 5 (il est donc faible) s'il est attaqué par une arme de force 10, il perdra : 10 - (5 *(1-5/20) donc 5,25. Ainsi plus il est faible plus il perd de points.

Extension : Un personnage peut passer dans un état invincible pour un temps donné. Dans ce cas, il ne perd aucun point de vitalité quand il est attaqué.

Partie 5 facultative

On veut pouvoir créer des personnages et des groupes automatiquement, sans modifier les personnages définis précédemment. Un joueur a en début de partie 50 points, qu'il dépense en créant des personnages et/ou des groupes.

  1. La création d'un personnage a un coût : Humain : 10; Troll : 5; Tauren: 2; etc.
    • * Ainsi create(“Humain”, “Arthur”,Joueur) (i) retourne un personnage “Humain”, (ii) associe ce personnage au Joueur, et (iii) décrémente la bourse du joueur de la somme correspondante.
  2. La coût de création d'un groupe dépend du type de groupe :
    1. pour une Horde, c'est la somme du coût des personnages qui la composent, multipliée par 0.75.
      • CreateGroup(“Horde”, “Hunts”, joueur, “Troll”, 50) crée une horde de 50 Trolls dont le coût pour le joueur est de (50*5)*0.75 = 187.5. Des noms différents sont donnés par défaut à chacun des membres de la Horde.
    2. pour un bataillon, c'est la somme du coût des personnages qui la composent
      • CreateGroup(“Bataillon”, “57Rima”, joueur, “Tauren”, 50) crée un bataillon de 50 Tauren dont le coût pour le joueur est de (50*2)= 100. Des noms différents sont donnés par défaut à chacun des membres du bataillon.
    3. Créer une armée est un peu plus complexe.
      • CreateGroup(“Armee”,“ArmeeNapoleon”,joueur,“Humain”) crée une armée dont le général est un humain, qui est crée avec un nom par défaut. Son coût est alors du coût de l'humain multiplié par 1.2 soit 12. Il est ensuite possible de créer un nouveau bataillon ou autre et de les lui ajouter sans coût supplémentaire.

Bien sûr, les personnages se déplacent, les groupes aussi, etc. mais ce sera pour une autre année.

Rendu

  1. un diagramme UML qui visualise uniquement les classes/interfaces dont votre code dépend directement.
    • le diagramme vise à visualiser l'architecture de votre solution
      • les différents patterns apparaissent sous forme d'annotations
    • le diagramme peut être obtenu par reverse-engineering mais doit être adapté pour répondre aux points précédents.
  2. les codes sources des classes que vous avez créées ou modifiées exclusivement.
  3. la couverture de tests

La date du rendu au plus tard lundi 17/12 à 12h pour les S3T et pour les S3A, le lundi 28 janvier à 9h : Sur Jalon avec comme nom pour l'archive : Gr <numeroGroupe> + Nom des étudiants dans le groupe

1)
Elle a d'autres propriétés que nous ne discutons pas ici, mais une épée n'est pas manipuler de la même manière qu'un bouclier, etc. Donc en fonction du fait qu'il s'agit d'une épée ou d'un bouclier, on aura des comportements différents, mais c'est une autre “histoire”.