Aller au contenu principal

Guerre des Pixels

Ce projet est librement inspiré de l'expérimentation réalisée par reddit en 2022.

PixelWar

Création de la partie client pour la "Guerre des Pixels" en utilisant une API existante

Introduction : Dans ce projet, vous allez créer la partie client d'un jeu appelé la "Guerre des Pixels". L'objectif est de permettre aux utilisateurs de se connecter à une API existante qui gère un tableau de pixels en ligne et de jouer à ce jeu en temps réel avec d'autres joueurs. L'API fournit différentes fonctionnalités telles que la modification des pixels, le choix d'équipe, etc. Vous utiliserez cette API pour créer une interface utilisateur interactive et conviviale pour le jeu.

Objectifs :

  1. Analyse de l'API existante : Étudiez la documentation de l'API existante fournie avec Swagger. Comprenez les différentes routes disponibles, les paramètres acceptés et les réponses renvoyées par l'API.

  2. Conception de l'interface utilisateur : Concevez une interface utilisateur attrayante et conviviale pour le jeu. Utilisez des technologies HTML, CSS et JavaScript pour créer les éléments de l'interface, tels que le tableau de pixels, les boutons pour choisir l'équipe, etc.

  3. Intégration de l'API : Intégrez l'API dans votre application client. Utilisez des requêtes HTTP (GET, PUT, etc.) pour interagir avec l'API et mettre à jour le tableau de pixels en fonction des actions des joueurs.

  4. Test et débogage : Testez votre application pour vous assurer que toutes les fonctionnalités fonctionnent comme prévu. Déboguez les erreurs et les problèmes éventuels pour garantir une expérience de jeu optimale.

  5. Documentation et présentation : Documentez votre travail. A minima votre projet doit inclure une JSDoc pour chaque fonction créée. Il doit aussi contenir un fichier README.md contenant les informations importantes.

  6. Proposer de nouvelles fonctionnalités: L'interface telle que vous pouvez la voir sur la vidéo possède (volontairement) plusieurs défauts. C'est à vous d'être créatifs en codant de nouvelles fonctionnalités (ou en améliorant celles existantes).

Détails des fonctionnalités attendues

La vidéo suivante illustre le fonctionnement du jeu avec un seul joueur.

  • Si l'utilisateur ne saisit pas un UID (ou qu'il est inconnu du serveur), il est impossible de modifier un pixel. L'utilisateur en est donc averti.
  • Il est possible de choisir une couleur (blanc par défaut)
  • Si l'UID est correct, il faut obligatoirement choisir une équipe, sinon il est impossible de modifier un pixel. L'utilisateur en est donc averti.
  • Si toutes les informations sont correctement saisies, alors le tableau de pixels est mis à jour et les informations dans le tableau de gauche sont mises à jour.
  • Après modification du pixel, un décompte démarre indiquant à l'utilisateur le temps qu'il doit attendre pour modifier le prochain pixel. S'il n'attend pas suffisamment, un message lui indique le problème.
  • Même chose avec le changement d'équipe, il faut attendre un délai prédéfini par le serveur pour avoir le droit de changer d'équipe. L'utilisateur en est donc averti.
  • Si on tente de spammer le serveur en cliquant un grand nombre de fois, l'utilisateur est banni pour un certain temps. L'utilisateur en est donc averti.
  • Si on attend trop de temps entre deux modifications de pixels, le serveur nous retire de l'équipe dans laquelle nous étions (les 4 boutons sont donc gris)

La vidéo suivante illustre le fonctionnement du jeu avec deux joueurs. Il est important que la partie "client" soit toujours synchronisée afin de voir les modifications opérées par les autres joueurs. Dans la vidéo, on voit que les modifications faites par un joueur se voient sur la page de l'autre joueur.

API disponible

La documentation de l'API du projet est disponible ici.

Description

L'API déployée permet d'interagir de plusieurs manières avec le serveur

  • GET
    • /tableau : Retourne le tableau de pixels de couleurs.
    • /temps-attente : Retourne le temps d'attente pour l'utilisateur spécifié
    • /equipe-utilisateur : Retourne le numéro d'équipe d'un utilisateur
    • /liste-joueurs : Retourne la liste des joueurs ayant récemment joué
  • PUT
    • /choisir-equipe : permet, pour un utilisateur identifié, de choisir son équipe
    • /modifier-case : permet, pour un utilisateur identifié, de modifier la couleur d'un pixel

Swagger

Ce mini-projet est l'occasion de découvrir un outil professionnel Swagger. Il permet de comprendre une API :

  • en lisant la documentation
  • en testant les routes directement depuis une page web.

Par exemple, voici la documentation de la route /liste-joueurs

SWAGGER

La documentation nous indique que

  • c'est une route GET qui requière un string (l'UID)
  • Cette route ne peut retourner que deux choses
    • code 200 avec un tableau d'objets contenant les informations des joueurs récents
    • code 403 avec un message (formatJSON) indiquant que l'utilisateur est inconnu.

Cette documentation doit vous permettre de comprendre :

  • comment interroger le serveur (via fetch)
  • comment coder côté client pour afficher les informations retournées par le serveur
astuce

Si vous cliquez sur "try out" puis "execute ", vous pourrez tester l'API directement depuis la page. On voit sur l'image ci-dessous :

  • le CURL qui a été réalisé (vous pouvez le copier/coller dans un terminal)
  • l'URL qui a été testée
  • le code de la réponse (200 ici) et la réponse associée (une liste de deux joueurs)
  • les entêtes de la requête.

Vous pouvez, par exemple, mettre un UID différent. Vous observerez que la réponse sera un conde 403.

SWAGGER

IMPORTANT

Il est important de passer du temps à lire l'API avant de coder quoi que ce soit.

FAILLE DE SECURITÉ

SWAGGER

ATTENTION, lorsque vous faites une requête il faut bien avoir en tête que si le serveur que vous interrogez est en http alors c'est une énorme faille de sécurité. En effet, les données partent en clair. Cela veut dire que n'importe quelle personne sur le réseau (entre vous et le serveur) peut voir partir cette trame et vous voler vos données (par exemple ici l'UID).

Ici le serveur est en https, cela garantit donc que les données sont bien chiffrées.

Rendu

modalités de rendu

  • Ce projet est à rendre sur la page moodle du cours (adresse à venir)
  • Vous devrez déposer (au format tar ou zip) une archive contenant votre code source (dont un README)
  • Projet à rendre pour le 13 mai 2024

notation

Partie 1 (8 points)

Dans cette partie nous ne regardons pas le code. Nous notons uniquement les aspects fonctionnels.

  • affichage du tableau de pixels : 1 point
  • modification du tableau de pixels 3 points
  • affichage du temps restant : 1 point
  • gestion du tableau de joueurs : 2 points
  • affichage des messages du serveur 1 point

Dans cette partie nous notons votre code.

Partie 2 (8 points)

  • gestion des fetch : 3 points
  • gestion du dom : 3 points
  • qualité générale du code 2 points : architecture en fichiers, fonctions, qualité du JS, présence d'un README

partie 3 (4 points)

Vous êtes notés également sur votre capacité à faire évoluer le projet tel qu'il est présenté dans les vidéos.

Faites mieux que moi

Plusieurs choses ne sont (volontairement) pas parfaites dans ce que vous pouvez voir sur les vidéos. Voici quelques pistes d'amélioration :

  • L'uid est une donnée critique. Pourtant, il est visible sur l'écran. Il est donc simple de vous voler votre UID juste en regardant par-dessus votre épaule.
  • Il est pénible d'avoir à saisir l'UID à chaque fois que votre page se recharge. Regardez du côté du localStorage ou des cookies ce qui est faisable.
  • Le tableau donnant des informations n'est pas très lisible. Explorer plusieurs pistes pour le rendre plus utile à une grande bataille de pixels
  • Les messages retournés par le serveur ne sont pas très bien mis en valeur sur le site. On différencie difficilement les retours de type erreur des retours qui indiquent que tout s'est bien passé.
  • Si vous regardez bien l'API, la version du jeu de la vidéo semble ne pas exploiter toutes les informations retournées par le serveur sur certaines routes.

Toutes ces idées ne sont pas à coder.

Une peut suffire.

Vous pouvez aussi coder vos propres idées.

Proposez des idées, et écrivez-les dans le readme

Comment est calculée votre moyenne ?

La note finale de ce module est calculée de la manière suivante :

1/3 * (noteProjet * 1 + noteDevoirMachine * 2)