COMPTE RENDU N°1
DE TER :
Combat de magiciens
LUROIS Frédéric
GRATIEN Xavier
FOSSATI Jean Christophe
Ce document présente les différents choix que nous avons fait jusqu'à ce jour en ce qui concerne le TER du combat des magiciens.
Pour la suite de la conception du logiciel, nous avons considéré les hypothèses
suivantes :
Ø Il peut y avoir des obstacles sur l’arène de combat (nous avons donc pris des pouvoirs en conséquence tel que la téléportation ou la désolidification par exemple).
Ø Un magicien possède par défaut une ligne de vision de 10 hexagones de rayon. Cette ligne ne peut augmenter au cours du jeu, mais peut diminuer (dans le cas d’une attaque flash).
Ø Un magicien touché par une attaque flash reste ébloui un certain nombre de phase, pas de segment ou de tour…
Ø Un même modificateur peut être appliqué à plusieurs effets de base d'un même sort, mais ne peut être appliqué plusieurs fois sur le même effet de base d'un sort.
Ø Deux magiciens ne peuvent être sur une même case
Ø Un magicien à la possibilité de récupérer lorsqu’il se trouve sur un de ses segments d’action (cf. manuel utilisateur).
Nous avons étudié tous les effets et tous les modificateurs présents dans les règles du
jeu et nous avons décidé de faire une sorte de melting-pot des sorts (cf. manuel utilisateur) en prenant, par exemple au moins une attaque de chaque type (énergétique, flash, visant à tuer et mentale). De la même manière, et pour ne pas créer trop de désavantages lors d’un combat, nous avons conservé au moins un pouvoir défensif contre chaque type d’attaque. A cela nous avons ajouté les pouvoirs de type « annulation, dissipation, et transfert », qui permettent d’une part d’avoir une défense contre les sorts a effet continu et d’autres part, de satisfaire tous les types de joueurs (aussi bien les joueurs offensifs que défensifs).
En ce qui concerne les modificateurs, nous avons sélectionné tous les avantages de la liste fournie, ainsi que tous les désavantages, excepté « les effets secondaires », qui nous semblaient trop compliqués à gérer (puisque nous devions fixer quels étaient les effets secondaires), ainsi que « concentration » qui ne nous semblait pas très utile.
Nous n’avons pas fixé de limitation à la combinaison des effets de base et des sorts. Par exemple, il est possible de combiner une attaque flash à aire d’effet avec un contrôle mental à aire d’effet, même si cela n’est pas très utile ou réaliste…
Il n’y a pas eu de véritable répartition du travail au sein de notre groupe. Les
différents diagrammes ainsi que le manuel utilisateur ont été conçus en trinôme. Nous pensons qu’il y aura une véritable répartition des taches dans au cours de la phase de codage…
La principale difficulté que nous avons rencontrée durant cette phase d’analyse fut la gestion du temps. En effet au cours de cette étape, nous devions déjà avoir une idée précise de nos différentes interfaces, et de la façon dont nous allions gérer et implémenter nos classes, alors que certains points du sujet restaient encore obscurs pour nous. Le temps que nous avons passé à éclaircir ces points, nous l’avons perdu pour l’analyse.
La seconde fut la gestion de la frontière Analyse – Codage. En effet, pour effectuer une bonne analyse, il faut bien avoir en tête les phases de conception et de codage. La difficulté pour nous a été de représenter de façon formelle (sous forme de diagramme) les idées que nous avions déjà pour le code. Certains éléments qui nous paraissaient assez simple au niveau du code, ce sont avérés difficiles à schématiser.
La dernière fut l’exhaustivité des informations. Nous sommes conscients que nous avons du oublié certains éléments lors de cette phase d’analyse, éléments qui vont apparaîtrent lors de la conception et de codage…
La version du logiciel actuellement développée ne permet que l’affrontement de deux magiciens sur un même écran. Si le temps le permet, nous développerons une version réseau du jeu, autorisant les combats de plus de deux magiciens, afin de rendre son utilisation plus pratique et plus conviviale.