XBlast 2016
1 Introduction
Le but du projet de cette année, nommé XBlast 2016, est d'écrire une version simplifiée du jeu XBlast, développé initialement en 1993 par Oliver Vogel et inspiré de Bomberman. Dans les années 90, XBlast était très populaire dans les universités, entre autres à l'EPFL où les étudiants en informatique l'ont passablement amélioré au fil des ans.
XBlast permet à quatre joueurs, contrôlant chacun un personnage distinct, de s'affronter sur un plateau de jeu commun. Pour tenter d'éliminer ses adversaires, un joueur a la possibilité de déposer des bombes. Celles-ci explosent au bout d'un certain temps, provoquant entre autres la mort des éventuels infortunés atteints par l'explosion. Si un joueur réussit à éliminer la totalité de ses adversaires avant la fin des deux minutes réglementaires, il est déclaré victorieux. Sinon, la partie se termine sur un match nul.
La séquence ci-dessous montre une partie en cours. Il est conseillé de la visualiser en plein écran afin d'éviter les moirés désagréables.
2 Vue d'ensemble
La mise en œuvre de XBlast est séparée en deux programmes distincts : le serveur et le client. Lors d'une partie à quatre joueurs, une copie du serveur et quatre copies du client — une par joueur — fonctionnent simultanément, sur quatre — ou, éventuellement, cinq — ordinateurs différents. Chaque client communique avec le serveur via le réseau.
La figure ci-dessous illustre les communications entre le serveur et quatre clients participant à une partie. Le serveur est supposé s'exécuter sur la machine 1, de même que l'un des clients. Les trois autres clients s'exécutent quant à eux sur trois autres machines. A noter que le client de la machine 1 communique avec le serveur exactement comme les trois autres, c-à-d par échange de messages. La seule différence dans ce cas est que ces messages ne transitent pas par le réseau, car il restent sur le même ordinateur.
Le serveur est l'arbitre de la partie. Il gère l'état du jeu, qu'il fait évoluer en fonction des règles du jeu et des actions des différents joueurs, qui lui sont communiquées par les clients. Vingt fois par secondes, il calcule le nouvel état du jeu et l'envoie aux clients pour affichage.
Le client affiche à l'écran chaque état reçu du serveur. De plus, il détecte les actions effectuées par le joueur qu'il représente, p.ex. l'appui sur la touche de dépôt de bombe, et les transmets au serveur pour traitement.
3 Groupes
Le projet se fait par groupes de 2 personnes au maximum. La formation de ces groupes est libre et peut changer au cours du semestre, pour peu que les directives concernant le plagiat soient respectées. En particulier, si deux personnes ayant travaillé en commun se séparent, elles doivent se partager le code et ne peuvent chacune l'emporter en totalité de leur côté.
4 Notation
Un total de 300 points est attribué au projet, ceux-ci étants répartis de la manière suivante :
| Elément | Points |
|---|---|
| Rendus mineurs | 12 |
| Rendu testé | 80 |
| Rendu intermédiaire | 78 |
| Rendu final | 115 |
| Test final | 15 |
| Total | 300 |
Un rendu mineur est un rendu qui n'est ni testé ni évalué par les correcteurs. Pour obtenir les points associés à un tel rendu, il vous faut rendre votre projet via le système de rendu dans le délai imparti, et il faut que celui-ci soit accepté par notre système. Il y a un total de 4 rendus mineurs au cours du semestre, un pour chacune des étapes 2 à 5, chacun d'entre eux valant 3 points.
Le rendu testé est un rendu que nous soumettons à des tests unitaires, pour lequel le nombre de points obtenus dépend du nombre et du poids des tests passés avec succès.
Le rendu intermédiaire et le rendu final sont quant à eux évalués par des correcteurs, et les points attribués en fonction de la qualité de votre programme. L'efficacité, la concision et l'élégance de votre code sont pris en compte dans cette évaluation.
Le test final consiste en un test non automatisé (contrairement aux tests unitaires) du bon fonctionnement de votre projet complet.