Master d'Informatique, niveau 1, 2010 – 2011
Programmation Concurrente, Réactive et Répartie
(U.E. MI019)

Devoir de Programmation – 2010
« 
Shoot the targets »

1  Description générale

Ce devoir consiste à implanter un jeu vidéo de « tir au pistolet ». Il se divise en deux parties principales : le client graphique et le serveur de jeu.

  1. le client graphique s'occupe de l'interface homme-machine,
  2. le serveur de jeu s'occupe des scores et « guide » le client (donc fait « tous les calculs »).

Chaque partie est à réaliser dans un langage différent de la liste suivante : O'Caml, Java, C, ou dans un autre langage proposé par les étudiants et validé par un enseignant. Il faut donc au moins deux langages distincts pour réaliser ce devoir.

Ce devoir est à réaliser en binôme.

Un rapport obligatoire devra présenter la réalisation du projet.

2  Client graphique

Le client est composé de deux éléments clefs :

  1. l'afficheur : un interprète de langage graphique
  2. le gestionnaire d'événements (i.e. celui qui repère les clics)

2.1  Interprète de langage graphique (Afficheur)

On se donne un mini langage comportant des instructions d'affichage graphique. Une instruction standard tient sur un octet. (Une instruction spéciale tient sur un nombre arbitraire d'octets.) La figure 1 donne les spécifications du langage, et la figure 2 donne un exemple de code. (Les spécifications doivent être respectées mais peuvent être étendues.)


Instructions
 
codenomarité (taille en octets)argumentsaction
00Color1 (4)couleur RGBAchange la couleur courante
01MoveTo2 (2×2)A, Ochange le point courant
02Dot0 (0)dessine un point au point courant
03LineTo2 (2×2)A, Odessine une ligne jusqu'au point donné
04Ellipse4 (4×2)A, O, RA, ROdessine une ellipse
05FEllipse4 (4×2)A, O, RA, ROdessine une ellipse pleine
06Circle3 (3×2)A, O, Rdessine un cercle
07FCircle3 (3×2)A, O, Rdessine un disque
08Rect4 (4×2)A, O, L, Hdessine un rectangle
09FRect4 (4×2)A, O, L, Hdessine un rectangle plein
0ASquare3 (3×2)A, O, Cdessine un carré
0BFSquare3 (3×2)A, O, Cdessine un carré plein
0CPoly1+n (1+2×n×2)T, n × (A, O)dessine un polygone
0DFPoly1+n (1+2×n×2)T, n × (A, O)dessine un polygone plein
0ERec0 (0)enregistre une macro
0FStore2 (1+n)T, Nstoppe et nomme la macro courante
10Load2 (1+n)T, Ncharge une macro
11LineWidth1 (1)Lchange la largeur des lignes
12Clear0efface la zone de dessin
13Dummy0ne fait rien
 
 
Légende
Aabscisse (horizontal)
Oordonnée (vertical)
RGBAred, green, blue, alpha : 4×8=32 bits
Llargeur
Hhauteur
C(longueur du) côté
Rrayon
Ttaille - 1 (en nombre d'octets)
Nnom (limité à 256 caractères)
RAradius abscisse
ROradius ordonnée
macroséquence d'instructions
Remarques
  • Les nombres sont des entiers non signés (positifs).
  • L'unité de mesure graphique est le pixel.
  • Les nombres sont en représentation décimale, sauf pour la colonne code où ils sont en hexadécimal.
  • L'arité est le nombre d'arguments.
  • Le canal alpha (composante pour la transparence des couleurs) est ignoré sauf pour ceux qui veulent aller plus loin.
  • La taille par défaut pour la fenêtre est 800×600.
  • Le point de coordonnées (0, 0) est en bas à gauche.
Figure 1: Instructions de l'afficheur graphique


Le code suivant
 
en représentation assembleur en représentation hexadécimale en représentation octale
Color(00000000);
FSquare(0000,0000,01FF);
Color(FF000000);
MoveTo(0000,0000);
LineTo(01FF,01FF);
MoveTo(0000,01FF);
LineTo(01FF,0000);
        
ou
00000000000B0000000001FF00
FF00000001000000000301FF01
FF01000001FF0301FF0000
        
ou
000000000000000013000000000
000001377000377000000000001
000000000000003001377001377
001000000001377003001377000
000

dessine un carré noir plein de côté 511 pixels avec ses diagonales en rouge.
Figure 2: Exemple de code

2.2  Guetteur d'événements

La fenêtre graphique une fois dessinée doit guetter les événements du joueur : clic avec la souris ou frappes sur le clavier. En cas de clic avec la souris ou de frappe sur le clavier, il faut envoyer les coordonnées du point cliqué au serveur.


Instructions
 
codenomarité (taille en octets)argumentsaction
00Mouse2 (2×2)A, OTransmet un clic
01Keyb2 (1+n)T, KTransmet un caractère
 
 
 
Légende
 
Aabscisse (horizontal)
Oordonnée (vertical)
Ttaille du caractère
Kcaractère entré au clavier
Remarques
  • La taille des caractères dépend de l'encodage utilisé. Par exemple, en UTF-8, la taille est variable (un ou plusieurs octets) ; en iso-8859-1 ou en ascii, elle est fixée à 8 bits (1 octet).
Figure 3: Transmission des événements

3  Noyau : le serveur de jeu

L'implantation du noyau consiste à implanter un gestionnaire de scores ainsi que le générateur de graphiques.

Lorsqu'un client est connecté au serveur, le serveur doit être capable de connaître le score du client jusqu'à son départ. Comme le client se contente d'afficher naïvement tout ce que demande le serveur, c'est au serveur de se charger des calculs de dessins.

3.1  (Génération ou Gestion des) Cibles

Il faut maintenant s'occuper des cibles. Une cible doit ressembler à une cible (i.e. ne pas être invisible). C'est au serveur de dire au client (par voie d'affichage) si une cible a été touchée ou non.

Remarques :

La complexité minimale de la forme des cibles est un rectangle1. Il sera préférable que la forme des cibles soit au moins circulaire. Cependant il vaut mieux avoir un jeu qui fonctionne avec des cibles simples qu'avoir un programme qui ne fonctionne pas du tout.

Il faut au moins une dizaine de niveaux de difficulté différents. Le niveau peut varier en fonction de nombreux critères, dont la taille des cibles, leurs durées d'apparition, leurs formes, la taille des projectiles, la taille de leurs impacts, etc.

3.2  Gestionnaire de scores

Les règles du jeu (i.e. comment les points sont attribués) devront être décrites en détail dans le rapport. Une brève description de l'implantation devra les accompagner.

3.2.1  Système de tirs et Périphérique de saisie

C'est ici que se joue l'interprétation des événements envoyés par le client au serveur.

On considère que l'interface entre l'utilisateur et la machine comprend une souris qu'on peut utiliser comme périphérique de contrôle du jeu. Cependant, pour ceux qui préfèrent le clavier à la souris, il est possible d'implanter un système de tirs au clavier (voir FAQ en 9.1), voire d'implanter les deux...

 

Tirs rectilignes

Une simplification des trajectoires des tirs consiste à les considérer rectilignes et même (quasi) instantanés. Dans ce cas, il n'y a pas de difficulté à calculer le point d'impact.

 

Tirs (pseudo-)paraboliques

Un système de tir plus réaliste (et plus compliqué) consiste à prendre en compte la gravité, la vitesse du projectile, etc.

4  Communications (entre le client et le serveur)

Le client reçoit les ordres du serveur dans le langage présenté plus haut. Le serveur reçoit les événements perçus par le client dans le second langage présenté plus haut.

Il est trivial de faire une version multi clients individuels.

Faire une version multi joueurs est intéressant, à voir si vous avez le temps.

5  Extensions : aller plus loin en améliorant le jeu

Une extension consiste à rendre le jeu plus attrayant en le dotant davantage de fonctionnalités.

Remarque : La diversité des extensions sera appréciée : évitez au mieux de choisir les mêmes extensions que les groupes voisins.

Voici une liste d'extensions proposées, cette liste n'est pas exhaustive, mais en cas de choix externe à la liste, il faut qu'ils soient intéressants.

6  Structuration

Le projet doit être le plus modulaire possible. Les groupes sont invités à se répartir le travail et mettre en place ensemble une « charte de programmation » qui leur permettra d'avoir un code uniforme (commentaires, dénomination des paramètres, …).

7  Colis et Livraison

Le colis devra être livré avant le 10/12/2010 23h59 (choix du fuseau horaire à votre charge) par courriel en cliquant ici.

Le colis consistera en une archive au format tar gzippé (extension .tar.gz ou .tgz). Le nom de l'archive sera de la forme « numéroÉtudiant1_nom1_prénom1--numéroÉtudiant2_nom2_prénom2.tgz ».

L'archive devra contenir :

Les programmes devront fonctionner sur les machines de la plate-forme pédagogique informatique.

Le non suivi des règles sera pénalisé.

Informations complémentaires

8  Rapport

Le rapport doit contenir les informations permettant de noter convenablement votre projet. Il doit présenter votre travail de manière concise.

À titre indicatif, il ne devrait pas dépasser une dizaine de pages, mais tout dépend du contenu et de la mise en forme. Il est impératif de ne pas tricher sur la mise en forme, sinon ce serait tout gâcher.

Règles de base : Si le rapport fait moins de pages que voulu, inutile d'agrandir la taille de la police de caractères ou de jouer sur les marges, et inversement si le rapport fait plus de pages que voulu. Il est préférable d'une manière générale qu'il n'y ait pas trop de mots sur une même ligne, donc si vos marges sont petites, n'hésitez pas à agrandir un peu les caractères (mais pas au delà de 14pts). Évitez également les polices de caractères illisibles. Rappelons que la forme aide à la lisibilité, tandis que le fond contient les informations. Pensez également à appliquer un correcteur orthographique pour limiter les dégâts...

9  Questions

En cas de problème concernant les objectifs à atteindre, questions diverses, etc., vous pouvez envoyer un mail à Philippe.Wang@lip6.fr

Vérifiez quand même que la réponse n'est pas déjà dans cet énoncé !

9.1  Foire aux Questions

10  Liens


1
qui peut même être réduit à un pixel, mais la « jouabilité » risque d'en prendre un coup

Ce document a été traduit de LATEX par HEVEA + sed