Differences

This shows you the differences between two versions of the page.

--- 2016_2017:s3:concprogobjet:td:td7 [2016/11/06 14:11]
blay [Jeu]
+++ 2016_2017:s3:concprogobjet:td:td7 [2016/11/22 21:32]
blay [Rendu]
@@ Line 2: / Line 2: @@
-voici quelques exercices simples mettant en jeu des DP
+voici quelques exercices simples mettant en jeu deux DPs.
-===== Jeu =====
+===== Partie 1 =====
 /* decorateur
 */
@@ Line 46: / Line 46: @@
 //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?
-<! Fabrique
+===== Partie 2 =====
-!>
+/* Fabrique
+*/
+Au fur et à mesure que le jeu est mis sur le marché, pour "créer du hype", on veut pouvoir ajouter de nouvelles armes, y compris des extensions, sans modifier l'ensemble du jeu.
+L'idée est de :
+  - ne pas modifier les classes d'armes définies précédemment;
+  - pouvoir créer des armes à partir de leur type et avec un nom donné (ex: créer une épée de nom //excalibur//);
+  - retrouver une arme à partir de son nom;
+  - améliorer des armes (ex : amplifier excalibur d'un comportement magique de force 10).
+exemple de scenario de test :
+<code java>
+        WeaponFactory wf = new WeaponFactory();
+        Weapon w = wf.createWeapon("SWORD","excalibur");
+        w = wf.improve("AMPLIFIED","excalibur", 5);
+        assertEquals(30,w.strength());
+        assertEquals(5,w.protection());
+        w = wf.improve("Magic","excalibur", 10);
+        assertEquals(300,w.strength());
+        assertEquals(50,w.protection());
+</code>
+Les Personnages au début sont créés en fonction des classes d'armes prévues. Modifier votre code pour ne plus dépendre de ces classes d'implémentation.
+===== Rendu =====
+    - 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 attributs faisant référence à des classes/interfaces sont uniquement représentés sous la forme d'associations (rôle, cardinalité, orientée)
+                    * pas de getter et setter
+                    * pas de classes non directement utilisées par exemple.
+                    * 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.
+    - les codes sources des classes que vous avez créées ou modifiées exclusivement.
+La date du rendu au plus tard : xxx à 23h45
+Sur [[http://jalon.unice.fr/cours/blay/Cours-blay-20150930110548/BoiteDepot-blay-20161122213044309075?mode_etudiant=false|Jalon]] avec comme nom pour l'archive :  Gr <numeroGroupe> + Nom des étudiants dans le groupe
-La construction des personnages dépend des classes d'armes identifiées au début.
-Cependant, au fur et à mesure que le jeu est mis sur le marché, on aimerait pouvoir améliorer cette logique : à la création d'un personnage, l'arme qui lui est associé et déterminé en fonction du prix mis par le joueur (nombre de points).
-De plus, maintenant que les armes ont un coût on veut pouvoir associer une arme à un joueur...

Cours au département INFO - IUT - UNS

User Tools

Site Tools

Differences

Page Tools