Introduction

L’objectif de cette étape c’est d’avancer sur les différents composants de votre jeu, sans nécessairement s’atteler à leur intégration au programme final.

C’est l’étape finale de ce premier semestre.

Vous devez travailler en équipe sur :

la logique de jeu et l’interface textuelle utilisateur
- 2 à 4 personnes
l’interface graphique utilisateur
- 2 à 3 personnes
le fonctionnement du joueur en réseau (côté client et serveur)
- 2 à 3 personnes

Pour travailler sur ces composants-là vous devez avoir fini d’écrire l’interface C++ d’un joueur de l’étape précédente. Chaque équipe du groupe doit travailler avec l’exact même fichier IPlayer.hpp.

Si à un moment vous vous rendez compte qu’une donnée nécessaire n’est pas passée par une des fonctions de l’interface IPlayer vous pouvez décider de la modifier, mais tout le groupe doit la modifier et faire conformer ses implémentation à la nouvelle interface.

Notation et évaluation

Chaque équipe aura sa grille d’évaluation. Chaque personne peut faire partie d’une équipe seulement.

La note d’une équipe sera calculée sur 40 points :

18 points pour le livrable de cette équipe ;
18 points pour la moyenne de tous les livrables de toutes les équipes du groupe ;
4 points pour la démonstration et la présentation lors de la soutenance.

Votre note ne se contente pas de récompenser la réussite de votre équipe, mais celle de tout le groupe. Vous devez non-seulement tous avancer sur votre livrable, mais aussi aider les autres dès que vous le pouvez, en particulier si vous pensez avoir fini, étant donné que cela fera aussi monter votre note.

L’évaluation se fait sous forme de soutenance. Pour chacun des critères, chaque équipe doit faire la démonstration de comment il a été respecté. Un critère pour lequel vous ne présentez rien en soutenance ne vous apportera pas de points. Lors de sa soutenance, chaque équipe peut être accompagnée de 2 autres membres du groupe qui ont aidé sur son livrable.

Bien que ça ne soit pas obligatoire, vous pouvez venir avec des diapositives de présentation.

Équipes et livrables

Interface utilisateur graphique

Taille de l’équipe : 2 ~ 3 personnes

Critères	Points
L’état de la partie pour un joueur est affiché (plateaux/joueurs en vie/affections personnelles)	4,5
Le status de la partie est affiché (à qui le tour, qui a gagné ?, un message en texte brut à l’intention du joueur)	4,5
Affichage au joueur comme quoi c’est à lui de jouer (avec une indication sur l’action à faire)	4,5
Sur la fenêtre, on peut cliquer ou sélectionner au clavier l’action que l’on veut faire, et elle devient accessible au `get_move` (ou équivalent)	4,5
Malus : par faute de norme	-0,5
Malus : dépôt sale (fichiers temporaires, binaires, etc.)	-4,5

Joueur réseau (client et serveur)

Taille de l’équipe : 2 ~ 3 personnes

Critères	Points
Serveur : serialisation et envoi de l’état de la partie d’un joueur (plateau/joueurs envie/affections personnelles)	4
Client : reception et dé-sérialisation état de la partie	4
Serveur : sérialisation et envoi de status de la partie (à qui le tout, qui a gagné ?, un message en texte brut à l’intention du joueur)	1,5
Client : reception et dé-sérialisation status	1,5
Serveur : sérialisation et envoi de l’ordre qui indique au joueur que c’est à son tour (avec potentielle précision sur l’action à faire)	1,5
Client : reception et dé-sérialisation ordre de jeu	1,5
Client : sérialisation et envoi de l’action choisie côté joueur	2
Serveur : reception et dé-sérialisation action joueur + mise à disposition dans `get_move` (ou équivalent)	2
Malus : par faute de norme	-0,5
Malus : dépôt sale (fichiers temporaires, binaires, etc.)	-4,5

Logique de jeu et joueur terminal

Taille de l’équipe : 2 ~ 4 personnes

Vous devez implémenter une classe qui peut être construite avec une liste d’instances de IPlayer. Ces IPlayer peuvent être des références ou des adresses en fonction de ce qui vous arrange. Libérez bien la mémoire derrière vous si vous manipulez des adresses. Assurez-vous de ne pas supprimer vos instances originales si vous manipulez des références.

Dans cette classe vous directement implémenter la logique de jeu et lui faire faire le déroulé d’une partie avec les IPlayer reçus à la construction.

Vous pouvez aussi choisir d’avoir une logique de jeu complètement séparée et de la piloter dans cette classe que vous avez codé. Un exemple de classe de jeu indépendante se trouve dans l’exemple de MSGame vu plus tôt. Dans cet exemple vous remarquerez que le pilotage est fait dans le main (mais en réalité il vaut vraiment mieux le faire dans sa propre classe, c’est le propos même de ce sujet).

Enfin, vous devez implémenter une classe qui permet à une personne de jouer depuis un terminal (ou plus simplement un flux). Elle doit implémenter IPlayer et pouvoir être construite avec un std::istream & et un std::ostream &. Pour jouer depuis le terminal il suffit donc de la construire avec en paramètres std::cin et std::cout. Pour faire un faux joueur il suffirait de créer un flux sur un fichier (std::ifstream) ou sur une chaîne de caractères (std::stringstream). Un faux joueur peut fortement vous aider à tester votre logique de jeu.

Sont donc évalués ensemble :

votre logique de jeu et/ou votre coordinateur de jeu ;
votre joueur terminal ;
vos tests (ou plutôt la démonstration que vous ferez en soutenance).

Barème (3 points par critère) :

Envoi de l’état de la partie (au moins l’état initial)
Envoie de l’état de la partie dès que nécessaire (quelqu’un dans le jeu à fait quelque chose qui doit être visible par le joueur qui le reçoit)
Requête à au moins une personne de jouer, vérification de la validité de l’action, et répercussion de l’action sur la partie
Requête à toutes les personnes supposées jouer, vérification de la validité de l’action et répercussion de l’action sur la partie
La partie peut être terminée
Implémentation de IPlayer pour un joueur terminal

Malus :

0,5 points par faute de norme
4,5 points si votre dépôt est sale (fichiers temporaires, binaires, etc.)