Cahier des charges

Je suis en train de penser que le multithreading de l'application, c'est bien sympa, c'est un objet de fantasme et tout (non ? ), mais ça nous posera aussi pas mal de problèmes (ça n'a pas l'air si compliqué au premier abord, mais pourtant...). Par exemple, on ne peut pas lâcher complètement le moteur de jeu dans la nature pendant qu'il calcule des mouvements de l'IA non encore affichés : il y a des cas où l'interface pourrait récupérer une copie des données en retard, et donc carrément sauter l'affichage d'un coup. Ça peut bien sûr se régler, mais ça prendra un temps qu'on ferait mieux de ne pas passer sur du hors-sujet, finalement...

Ce qui est sûr, c'est qu'il faudrait éviter de parler de multithread dans le cahier des charges (un truc qu'on peut potentiellement foirer, c'est pas le top :p). Je pense aussi qu'on ferait mieux, dans un premier temps, de tout faire dans un seul thread, mais en laissant le reste inchangé (donc l'UML aussi). Si on ne sait plus quoi faire à la fin (ce qui m'étonnerait ), on pourra tenter d'ajouter ça (je ne vois pas de problème d'incompatibilité majeur avec ce que l'on aura fait jusque là...)

D'ailleurs, en parlant de cahier des charges, je suis en train d'écrire la partie sur l'architecture. Je la fait à part pour le moment, donc vous pouvez retoucher le cahier des charges existant sans problème (dans le cas où les petites boulettes qu'on avait repéré y seraient toujours).

Un brouillon (la flemme de continuer maintenant) :
___________________________________________________________________

Choix de développement

Outils

Pour ce projet, nous avons opté pour le langage C++, principalement dans le but de nous préparer à ce que seront nos futurs emplois. L'interface du logiciel sera développée en 2D, à l'aide de la librairie SFML (Simple and Fast Multimedia Library). Il s'agit d'une alternative à SDL, aussi facile d'utilisation, mais avec des performances de loin supérieures. Pour la partie artistique, nous nous appuierons sur les images du jeu libre « Battle for Wesnoth ». Cela nous permettra de nous concentrer avant tout sur le principal : la mise au point de l'intelligence artificielle.

Architecture

L'idée de base est de séparer le code relatif aux deux principaux types de responsabilité :
- la gestion du jeu : définir ce qui est permis, ce qui ne l'est pas, ce qu'il se passe lorsqu'une armée en attaque une autre, l'IA, etc.
- Les interactions avec l'utilisateur : il s'agit d'interpréter les actions de l'utilisateur d'une part, et de l'autre d'afficher l'état de la partie.

Le premier aspect est traité par le moteur de jeu, et le second par le moteur graphique. Ces deux composants manipulent les données de l'application, accessibles via un singleton. Afin de réduire au maximum leur couplage, les communications entre eux se font selon le principe du design pattern Observateur :
- La classe abstraite Moteur est à la base de tout objet observable. Mais puisque les moteurs s'observent entre eux, ils jouent également le rôle d'observateur.
- Le moteur de jeu et le moteur graphique sont représentés par des classes dérivant de Moteur.
- Les appels de méthode d'un moteur sur l'autre se font en passant un objet Event en paramètre. Ces objets permettent d'identifier le type d'évènement dont il est question, et encapsulent diverses données au besoin (le chemin que prend une unité pour aller d'un point à un autre par exemple).

Revenons sur les objets Event. Ils sont à la base des « discussions » entre les moteurs, qui pourraient, s'ils étaient humains, ressembler à cela :
(on note « Graph » le moteur graphique, et « Jeu » le moteur de jeu)

Graph à Jeu : « Le joueur a sélectionné le groupe situé en (12,3) »
Jeu à Graph : « Voici les possibilités de déplacement pour ce groupe : (11,3),(12,4)(11,4) »
Graph à Jeu: « Le joueur souhaite que le groupe en (12,3) se déplace en (12,5) »
Jeu à Graph : « Ce déplacement est interdit »
Graph à Jeu : « Le joueur souhaite que le groupe en (12,3) attaque celui situé en (12,2) »
Jeu à Graph : « Permission accordée. L'attaque se fera à la fin du tour »
Graph à Jeu : « Le joueur a fini son tour (il souhaite donc lancer les attaques en attente) »
Jeu à Graph : « Résultat de la bataille : 142 mort chez vous, 112 chez l'autre »
Jeu à Graph : « Le tour est fini »
etc...

L'élaboration du diagramme de classes UML s'est faite en plusieurs étapes :
- Définition la structure de base du programme, indépendante des règles du jeu : les moteurs, le système d'évènement.
- Définition des structures de données.
- Définition des classes auxquelles les moteurs délèguent leur travail.

Le diagramme présent en annexe comprend les deux premières étapes, la troisième dépendant d'algorithmes qu'il nous reste à définir. Il est à noter qu'il n'est pas le reflet de l'implémentation finale : les setters et getters n'ont pas été ajoutés par souci de lisibilité, tout comme la portée des opérations et attributs, et les paramètres des opérations ont aussi été occultés.
___________________________________________________________________

Le diagramme qu'il faudra mettre en annexe : http://xerius.nuxit.net/glouglou/diagramme_classes2.png

En tous cas, ça va vraiment bizarre de parler de code dans un cahier des charges :/

ps : s'il y a quelqu'un de motivé pour arranger les trucs bizarres et mettre ça au propre, je ne lui en voudrait pas du tout

Je me demande même si en presentant ca a Koriche il va pas nous dire de l'enlever...^^'

Je pense, mais Leclere le voudra quand même...

Bah, on le présente à Koriche et on voit. Le pire qui puisse nous arriver, c'est qu'il trouve ça H-S et qu'il nous conseille de l'enlever, et voilà. Rien de grave

Ok, j'ai intégré vos corrections. http://dl.free.fr/oYSiMLlsM

Il reste donc l'organisation des tâches et le planning à mettre en ordre...

Je vais faire le Gantt, mais je ne peux pas avant 23h. Ça vous laisse un peu de temps pour vous décider sur ce que vous voulez faire (il serait un peu bête de devoir choisir à votre place quand même...)

Ah oui, je m'arrête à la mise en place du jeu joueur vs joueur. L'IA sera pour le moment représentée comme un gros bloc prenant tout le temps restant.

Il faudrais enlever les bonus/malus des terrains ds la description des unités maintenant qu'on a une partie spéciale pour ca^^'

Ah oui, mince. Je le fais demain en intégrant le Gantt de Cédric, s'il a la flemme de changer ça ^^

Deux autres trucs pour le cahier des charges :

- Les puces ne sont pas partout les mêmes. Il y a des ronds, des tirets avec et sans retrait...
- Dans ma partie, en parlant de l'UML : "Définition de la structure de base du programme, indépendante des règles du jeu : les moteurs, le système d'évènement.

Oui donc, je parlais de ça parce que je ne vais pas vraiment avoir le temps de finir le rapport maintenant. Par contre, je serai à Montpellier vers 12h00, comme la dernière fois. On pourrait peut-être se retrouver au bât 6 pour voir ensemble s'il reste des dernières choses à modifier (sauf peut-être Quentin, ça le saoulerait pour pas grand chose). Je verrais avec Sébastien tout à l'heure si vous avez répondu oui ^^ (faudra qu'on se passe nos numéros de tel d'ailleurs, ça pourrait servir)

moi je suis censé aller en course ce matin... j'espère que je serais rentrer assez tôt ^^''

Désolé, cette fois je ne pourrai pas être là à 12h. Je vais quand même essayer de regarder tout ça avant le cours de Koriche.

Seb et moi on s'occupe du cahier des charges (eh oui, j'ai pris possession du pc de seb)

odt : http://www.megaupload.com/fr/?d=KQJ6J0DA
pdf : http://www.megaupload.com/fr/?d=3F6YV3ZO

Quelqu'un a une idée pour améliorer la première page, ou on balance ça à Leclere tel quel ?

on peut toujours mettre le titre "Ter M1 : Algorithme min-max dans les jeux de stratégie historiques. Cahier des charges" dans une police de caractère plus jolie que l'Arial ou en 3D, enfin des truc comme ça. Ou ajouter une image de jeux de stratégie historique.

Bah la sobriété c'est pas mal aussi... Ce qui me "dérange" un peu, c'est surtout le fait d'avoir les noms au milieu de nulle part en bas. Mais c'est relatif, l'envoyer tel quel ça me va tout à fait

Bon, j'envoie le mail.