Liste des projets du cours PC2R - année 2009/2010

Ces projets sont l'application directe des notions vues en cours de PC2R. Ils demandent d'implanter des applications/applets graphiques et réseau clients/serveurs via des sockets ou en RMI. Les langages d'implantation sont Objective Caml et Java.

Certains projets sont plus rapides à réaliser que d'autres. Il en sera tenu compte a la correction. Sauf indication contraire, chaque projet est à réaliser en binôme. Pour choisir les projets, la règle du bus sera encore une fois utilisée.
Il n'y aura pas plus de 2 groupes sur un même projet, sauf variation des langages d'implantation.

Présentation des projets : mardi 2 novembre 2009
Mise en ligne : mardi 2 novembre 2009
première attribution : 6/11/2009
2ème attribution : 16/11/2009
3ème attribution : 22/11/2009

Pour s'inscrire, envoyez un courrier au responsable du module en cliquant ici et en indiquant dans le corps du message le projet choisi (ou une liste de projets qui vous intéressent) ainsi que les noms et logins des étudiants le réalisant.
Vous pouvez proposer un projet mais il doit être validé par le responsable du module.



Clients et serveurs de services existants

  1. serveur et client Ftp :
    Le protocole FTP (File Transfert Protocol) est décrit dans la RFC (Request For Comments) 959. Il est demandé d'écrire un serveur et un client pour ce protocole. Vous pouvez vous inspirez du serveur décrit au chapitre 8 de l'ouvrage Java et Internet. Le serveur est à écrire en O'Caml.
    Nombre de projets : 2 ou bien 1

Services de bureautique répartis

  1. PostIt de groupe
    Le but de ce service est de pouvoir avoir un rappel (sous forme d'une fenêtre) d'un événement proche dans le temps (soit en début de journée, soit peu de temps avant cet événement). Un serveur contient une liste de clients autorisés (machine - login) et la liste des PostIt à délivrer. Un client s'enregistre auprès du serveur. Le client ensuite autorise le serveur à lui envoyer des fenêtres de rappel. Les fonctionnalités du client sont :
    Nombre de projets : 2

  2. Planning de salles
    Le but de ce projet est de créer et maintenir un planning de salles commun à différents utilisateurs. Certains utilisateurs peuvent avoir de plus grande priorité par rapport à d'autres. On ne cherche pas à résoudre les différentes contraintes. On ne peut ajouter, ou enlever, des informations que si l'on est propriétaire de celles-ci ou si on a une priorité le permettant. Comme les différents utilisateurs peuvent être sur différentes machines, ils seront considérés comme client d'un serveur planning. Un client pourra demander les informations d'une salle sur une année, ou l'ensemble des salles sur une semaine.

    Nombre de projets : 2

  3. Une mini messagerie
    Réalisation d'une architecture client-serveur pour un petit service de messagerie.

    Le serveur doit tenir à jour une liste d'abonnés au service et, pour chacun d'eux la liste des messages qui leur sont destinés. Les clients peuvent abonner un nouvel utilisateur, consulter et maintenir (i.e. faire le ménage dans) la liste de ses messages et envoyer un message vers un ou plusieurs autres abonnés.

    Les transactions entre un client et le serveur concernent toujours un seul abonné (i.e. un client n'a accès qu'a ses propres messages).

    Nombre de projets : 2

  4. Dessin en groupe Réalisation d'une architecture client-serveur pour un petit logiciel coopératif de dessins avec sauvegarde
    Nombre de projets : 1

Serveurs de jeux de réflexion

  1. Isketch : jeu de dessin multi-joueurs ( site iSketch)
    Nombre de projets : 3

  2. Implantation d'un billard Nicolas à 4 joueurs ( site wikipedia).
    Nombre de projets : 3

  3. Jeu de dominos

    À la connexion, les joueurs s'inscrivent (par nom) et recoivent 7 dominos (un domino (x,y) code par 10*x +y, (y,x) =10*y + x; x et y de 1 a 7=blanc). La grille est nxn n>=20 ; pour indiquer un positionnement du coup, le joueur indique 2 cases adjacentes (dont l'une est adjacente au jeu déjà pose). il peut "passer" ou "piocher (le serveur lui renvoie un domino non encore attribué). Les clients reçoivent le nom du prochain joueur, le coup précédent (domino posé et sa position ou passe). Le client peut donc mettre à jour sa copie de la grille de jeu. Une requête incorrecte est renvoyée à son émetteur. Seule une requête du "prochain joueur" peut être prise en compte. Le jeu se termine lorsqu'un joueur a épuisé tous ses dominos. L'affichage graphique de la grille de jeu est un plus (mais peut-etre un tableau d'entiers). Le serveur limite ses connexions à 5.

    Nombre de projets 2
    :

  4. jeu de cartes Blacjack (voir site wikipediahttp://fr.wikipedia.org/wiki/Blackjack

    Pour 1 à n joueurs

    Nombre de projets 2
    :

  5. même sujet que le BlackJack pour le Poker (voir site wikipediahttp://fr.wikipedia.org/wiki/Poker

    Pour 1 à n joueurs

    Nombre de projets 2
    :

  6. même sujet que le BlackJack pour le Uno (voir site wikipediahttp://fr.wikipedia.org/wiki/Uno

    Pour 1 à n joueurs

    Nombre de projets 2
    :

  7. jeu d'échec Nombre de projets 2 :

Serveurs de jeux de stratégie et de simulation

Cette sous-section comprend différents réalisation autour des jeux de stratégie. Un jeu de stratégie en ligne permet à plusieurs (dizaines, centaines, milliers) de joueurs de s'affronter dans un monde particulier. Par exemple le jeu Travian crée un univers antique mellant romains, gaulois et teutons; le jeu Ogame a un univers de science-fiction. En règle générale il y a une gestion des ressources qui permettent d'apporter des évolutions du point de vue économique, militaire ou autre.
  1. à la manière de Travian ou Ogame, gérer la production locale, l'envoi d'éléments sur d'autres destinations, la résolution des conflits sans gestion d'alliances. Pour chaque variante (Ogame ou Travian) : Nombre de projets 4 :

Calcul distribué

  1. Queue de travail réseau
    Le but de ce projet est de fournir la mécanique de base pour un calcul réalisé par plusieurs machines. Un serveur construit une queue de travail. Un client qui se connecte à ce serveur lui indique qu'il est prêt à effectuer une partie du travail et récupère une des taches à effectuer. Une fois le calcul fini sur le client, il renvoie le résultat au serveur et peut prendre une autre tache.

    Pour simplifier la communication clients/serveurs, les taches sont représentées par des fermetures. Elles sont envoyées du serveur vers le client en sérialisant (voir le modufle Marshal) la fermeture. Pour que cela puisse se réaliser, il est nécessaire que le client possède cette fermeture, en particulier le pointeur de code. La seule manière possible de la faire en O'Caml est que le programme client soit le même que le programme serveur. Ainsi le code de la fermeture sera à la bonne adresse. On discrimenera le serveur du client sur le nom de la commande :
    serveur.exe port&
    client.exe machine port&
    
    serveur.exe et client.exe sont les mêmes exécutables/

    Voici un exemple d'utilisation du module Marshall :
    module type ST =
      sig type t val to_string : t -> string val from_string : string -> t end
    ;;
    
    module G = 
      struct 
         type t = {x:float; y:float}
         let to_string (x:t) = Marshal.to_string x [Marshal.Closures] 
         let from_string s =  ((Marshal.from_string  s 0) : t)
      end;;
    
    module F (P:ST) = struct
      module L = P
    end;;
    
    module H = F (G);;
    # let u = {G.x = 3.14; G.y = 88.9};;
    val u : G.t = {G.x=3.14; G.y=88.9}
    # let s =  H.L.to_string u;;
    val s : string =
      "\132\149\166\190\000\000\000\018\000\000\000\001\000\000\... "
    # let v = H.L.from_string s;;
    val v : H.L.t = {G.x=3.14; G.y=88.9}
    
    
    Il est demandé d'écrire :
    Nombre de projets :

Coopération et Concurrence : Robots dans la cour de récréation

Cette sous-section comprend différents sujets de simulation d'une cour de récréation où les robots jouent à un des jeux classiques suivants. Ces projets comportent une partie affichage graphique sur les clients, les serveurs jouant le rôle d'arbitre. Une extension possible est d'introduire un client humain qui contrôle au moins un joueur et peut changer de joueurs pour les jeux d'équipe. Si vous implantez cette extension vous pouvez passer de 2 à 3 pour l'équipe de développement, en séparant bien les parties réalisées par chacun.
  1. Balle au priso
    La zone de jeu est découpée en 2 parties. Chaque partie comprend la zone où évolue l'équipe et à l'arrière une zone de prisonniers. Le jeu démarre avec la balle dans un camps. Le but est d'atteindre les joueurs de l'autre équipe avec la balle, sans qui l'attrape. Pour cela chaque robot regarde dans toutes les directions. Un robot rattrape une balle s'il regarde dans la direction d'où vient la balle, à + ou - 10 degrés, et est touché dans les autres cas. Si un joueur attrape la balle il a 3 secondes pour la relancer. Si un joueur est touché, il s'en va rejoindre les prisonniers de son équipe, le ballon est alors relancé par son équipe. Si la balle atteind l'enclos des prisonniers, ceux-ci peuvent renvoyer la balle sur l'équipe adverse avec les mêmes règles. Si un prisonnier touche un adversaire, alors il est libéré et rejoint son camp.
    Différents lancers de balle peuvent être programmés : lob, tir, ...et différents robots aussi selon des caractéristiques de vitesse de déplacement, force de tir, ....

    Nombre de projets : 3


  2. Renards, Poules, Vipères
    La zone de jeu comprend 3 bases, une par équipe. Chaque équipe doit attraper les joueurs d'une autre équipe et peut se faire attraper par la dernière équipe. Un renard chassera une poule, qui chasse une vipère qui attrape un renard. Chaque équipe comprend plusieurs joueurs. Le jeu s'arrête dès qu'une équipe n'a plus de joueur. Le gagnant étant l'équipe restante possédant le plus grand nombre de joueurs actifs.
    Un joueur attrapé doit rejoindre par ses propres moyens la base de l'équipe qui l'a attrapé. Il restera en contact avec cette base ou en contact avec un autre joueur déjà attrapé formant ainsi une chaîne. Cette chaîne peut être libérée par un joueur de sa propre équipe au contact.
    Nombre de projets : 3

  3. l'Épervier
    La zone de jeu comprend est un rectangle où règne un épervier. À un signal donné, les joueurs partent d'un bord et doivent rejoindre le bord opposé sans se faire prendre par l'épervier. Ceux qui sont pris, deviennent éperviers ce qui augmente au fur et à mesure de la partie leur nombre. La partie s'arrête quand tous les joueurs sont pris. Le dernier attrapé devient épervier pour la partie suivante.
    Nombre de projets : 3

jeux d'action rapide

  1. Tank Attack

    Implantation du jeu Tank attack : des petits tank (caracteres ascii) evoluent au sein d'une aire de jeu de taille variable comprise en 80x80 et 240x240 des obstacles apparaissent aleatoirement sur l'aire de jeu. Chaque tank peu tirer pour degager son chemin. L'objectif est de rester le dernier tank.

    Nombre de projets : 2


  2. Tron

    Ce jeu est une variante du ver de terre, inspiré du film Tron (1982, Steven Lisberger ). Le but du est de rester le plus longtemps possible dans l'arene. Chaque joueur se déplace constamment et ne peut décider que de la direction. Il laisse sur son passage une trace durable partout ou il passe. Un joueur qui rencontre les bords de l'arene ou une trace (la sienne ou celle d'un autre joueur) a perdu. Le vainqueur est le dernier en jeu. En réseau, chaque joueur est dirigé par un client différent et interagit avec les autres par le serveur.

    Nombre de projets : 3


  3. Course de voitures

    On reprend le thème de la course de voitures sur des feuilles petits carreaux. Les voitures sont placées sur la ligne de départ (il peut avoir plusieurs lignes si le nombre de voitures est important). Chaque voiture à un instant donné peut augmenter ou réduire sa vitesse d'un carreau et/ou réduire ou augmenter son angle d'un carreau. Une voiture connaît tout le circuit et peut en partie construire une stratégie par rapport aux autres voitures.

    C'est une application client/serveur où le serveur accepte les inscriptions pour le départ, indique le départ de la course et valide les mouvements des voitures. Les clients donnent leurs intentions de mouvement, les envoient au serveur qui soit accepte le mouvement qui est alors répercuté aux autres clients, soit le refuse car il y a un accident. Un accident handicape pendant un léger temps la ou les voitures fautives.

    Là aussi il y a 2 types de clients : le client joueur humain et le client dirigé par un programme.

    Nombre de projets : 3

Un jeu d'action rapide complètement spécifié

proposé par Philippe Wang

Ce projet proposé par Philippe Wang 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 >>).

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)
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
 
code nom arité (taille en octets) arguments action
00 Color 1 (4) couleur RGBA change la couleur courante
01 MoveTo 2 (2×2) A, O change le point courant
02 Dot 0 (0) dessine un point au point courant
03 LineTo 2 (2×2) A, O dessine une ligne jusqu'au point donné
04 Rect 4 (4×2) A, O, L, H dessine un rectangle
05 FRect 4 (4×2) A, O, L, H dessine un rectangle plein
06 Square 3 (3×2) A, O, C dessine un carré
07 FSquare 3 (3×2) A, O, C dessine un carré plein
08 Ellipse 4 (4×2) A, O, RA, RO dessine une ellipse
09 FEllipse 4 (4×2) A, O, RA, RO dessine une ellipse pleine
0A Circle 3 (3×2) A, O, R dessine un cercle
0B FCircle 3 (3×2) A, O, R dessine un disque
0C Poly 1+n (1+2×n×2) T, n × (A, O) dessine un polygone
0D FPoly 1+n (1+2×n×2) T, n × (A, O) dessine un polygone plein
0E Rec 0 (0) enregistre une macro
0F Store 2 (1+n) T, N stoppe et nomme la macro courante
10 Load 2 (1+n) T, N charge une macro
11 LineWidth 1 (1) L change la largeur des lignes
12 Clear 0 efface la zone de dessin
13 Dummy 0 ne fait rien
 
 
Légende
A abscisse (horizontal)
O ordonnée (vertical)
RGBA red, green, blue, alpha : 4×8=32 bits
L largeur
H hauteur
C (longueur du) côté
R rayon
T taille - 1 (en nombre d'octets)
N nom (limité à 256 caractères)
RA radius abscisse
RO radius ordonnée
macro sé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
 
en représentation assembleur : Color(00000000); FSquare(0000,0000,01FF); Color(FF000000); MoveTo(0000,0000); LineTo(01FF,01FF); MoveTo(0000,01FF); LineTo(01FF,0000); ou en représentation hexadécimale :
0000000000070000000001FF00 FF00000001000000000301FF01 FF01000001FF0301FF0000


dessine un carré noir plein de côté 511 pixels avec ses diagonales en rouge.

Figure 2: Exemple de code



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.

L'attente d'événements avec Graphics peut être implantée, par exemple, à l'aide de http://caml.inria.fr/pub/docs/manual-ocaml/libref/Graphics.html#6_Mouseandkeyboardevents.

Instructions
 
code nom arité (taille en octets) arguments action
00 Mouse 2 (2×2) A, O Transmet un clic
01 Keyb 2 (1+n) T, K Transmet un caractère
 
 
 
Légende
 
A abscisse (horizontal)
O ordonnée (vertical)
T taille du caractère
K caractè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



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.

(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 rectangle. 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.

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.

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, 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.

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.

Nombre de projets : 4

Autres propositions

jeu de réflexion

Un jeu de réflexion et de mémoire se jouant à deux. On dispose d'un plateau composé de 16 cases (4 x 4). Chaque joueur possède trois piles de 4 gobelets chacunes. Un joueur possède des gobelets blancs et l'autre des gobelets noirs. Dans chacunes des piles, les quatres gobelets sont emboités : un petit, un moyen, un grand et un très grand.
Au début de la partie, tous les gobelets sont empilés 4 par 4 en dehors du plateau. À tour de rôle, chaque joueur doit, soit poser un de ses gobelets sur le plateau, soit déplacer un de ses gobelets qui est déjà sur le plateau. Le but est d'aligner sur le plateau 4 de ses goblets. Ceci doit se faire en respectant certaines règles : Nombre de projets : 1

Rendu de projet

Vous rendrez :

directement par courrier électronique ( en cliquant sur ce lien ) un rapport contenant une brève description générale du problème, une description de la hiérarchie de classes ou des modules utilisés, des principaux algorithmes et des protocoles de communications, un listing commenté, un petit manuel d'utilisateur et des jeux d'essai. Pour pouvoir tester votre programme il est demandé d'installer, dans un catalogue de votre compte sur les machines Linux de l'UFR,les binaires et les sources du projet.


Ce document a été traduit de LATEX par HEVEA