Project proposals

Le but de ce projet est de réaliser un jeu de dames (simplifié) en ligne multi-utilisateur.

Description du jeu

On rappelle le principe du jeu de dames

• Deux joueurs, le noir et le blanc, jouent sur un échiquier 10×10.

• Chaque joueur dispose de 20 pions. Les pions ne peuvent être posés que sur les cases noire, ils commencent la partie disposés sur les quatres lignes les plus proches du joueur respectif.

• Les joueurs jouent à tour de rôle, les blancs commencent. Un pion ne peut se déplacer que d’une case, en diagonal vers l’avant (deux choix possibles). Lorsque l’une des deux cases en face d’un pion est occupée par un pion adverse, et qu’il y a une case libre derrière, le joueur peut prendre le pion adverse en le “sautant”, le pion est alors éliminé de l’échiquier.

• Lorsqu’un pion arrive sur la ligne opposée de l’échiquier, il est promu en dame. Une dame se comporte comme un pion, mais en plus elle peut se déplacer en arrière.

• Le joueur qui n’a plus de pions perd la partie.

Description du projet

Vous devez réaliser un jeu en ligne sur le modèle vu en TD. Il doit comporter :

• Une page permettant de s’enregistrer,
• Une page présentant la liste des utilisateurs en ligne, leur nombre de parties gagnées/perdues, et autres informations éventuelles,
• Un mécanisme pour se connecter,
• Un mécanisme permettant de défier un adversaire,
• Une interface permettant de jouer le jeu.

L’interface du jeu doit être réalisée en JavaScript :

• Les pions sont disposés au début la partie, et c’est au blanc de jouer.
• Le joueur sélectionne le pion à jouer en cliquant dessus, puis il clique sur la case où le pion doit se déplacer. Le serveur vérifie que le coup est valide, et prend le pion adverse le cas échéant.
• Lorsqu’un joueur a perdu tous ses pions, ce joueur est déclaré perdant et le jeu se termine.

Ressources

• La page Wikipedia sur le jeu de dames.

Parties optionnelles

• Étendre les règles pour réaliser la version internationale des (voir la page Wikipedia). En particulier, le jeu calcule les prise obligatoires, et les montre au joueur qui doit jouer.

• Tous les points optionnels du TD sur Puissance 4 sont aussi valables pour ce projet.

• Implanter plusieurs systèmes de règles différents, et proposer une interface pour que le joueur qui invite puisse choisir le système.

• Utiliser une base de données No-SQL (par ex., MongoDB) à la place de SQL.

Le but du projet est de créer une application de post-it sociale. Il s’agit tout simplement d’une liste de messages, écrits par des utilisateurs, placés à des coordonnées quelconques sur la page

Description

Notre application est une collection de messages, composés par des auteurs. Un message a au moins :

• un texte,
• une date et heure,
• des coordonnées x et y dans le plan,
• un auteur.

Ces champs sont reflétés dans une table SQL. Une autre table SQL sera utilisée pour stocker les utilisateurs et leurs mots de passe (et d’éventuelles autres données relatives aux utilisateurs).

L’application est composée de deux vues :

• Une page pour enregistrer un nouvel utilisateur. Vous pouvez suivre le modèle déjà utilisé en TD.

• Une page principale, présentant les post-its, et :

  • soit un formulaire de login, si l’utilisateur n’est pas connecté,
  • soit un lien de déconnexion, si l’utilisateur est connecté.

La page principale

La page principale est tout simplement un fond blanc (ou autre couleur), sur lequel sont affichés des post-its créés par les utilisateurs, sous forme d’encadrés jaunes (ou autre).

Lorsque l’utilisateur fait double-clic sur un point quelconque de la page, il a la possibilité de créer un nouveau post-it. Les coordonnées du double-click déterminent l’endroit où le post-it est créé.

Chaque post-it présente son texte, sa date de création, et son auteur. Les post-it plus récents s’affichent par dessus les post-its plus anciens.

Conseil : utilisez la propriété CSS overflow pour éviter de faire apparaître des barres de défilement sur la page.

Ajout d’un nouveau post-it

Uniquement les utilisateurs connectés ont droit de créer un post-it. Lorsque l’utilisateur fait double-clic n’importe où dans la page, un popup s’ouvre, permettant de donner le texte du post-it. Après validation, une requête est envoyée au serveur et le post-it est inséré dans la base de données. Si l’insertion s’effectue avec succès, le nouveau post-it est affiché dans l’interface.

Une interaction de type AJAX et préférable pour cette action.

Suppression d’un évènement

En plus d’afficher les informations décrites ci-dessus, uniquement pour les post-its créés par l’utilisateur connecté, donner un moyen (bouton, lien, croix, …) de supprimer le post-it. Demander confirmation avant de supprimer. Lorsque l’utilisateur confirme, envoyer une requête, mettre à jour la base de données, et actualiser l’affichage en cas de succès.

Routes

Vous êtes libres de structurer la logique de l’application comme vous le souhaitez. Nous proposons ici un exemple de découpage en gestionnaires :

• Route / : présentant la page principale.
• Route /signup : permettant de créer un nouvel utilisateur.
• Route /login : permettant de se connecter. Redirige vers / après un login réussi.
• Route /logout : permettant de se déconnecter. Redirige vers / après un logout réussi.
• Route /ajouter : permettant d’ajouter un post-it.
  • Si AJAX, renvoie un code de succès/erreur.
  • Si non-AJAX, redirige vers / après un ajout réussi.
• Route /effacer : permettant d’éliminer un post-it.
  • Si AJAX, renvoie un code de succès/erreur.
  • Si non-AJAX, redirige vers / après un ajout réussi.
• Route /liste : renvoyant la liste des post-its au format JSON (ou XML, ou autre), pour un traitement chez le client. Uniquement si AJAX.

Vous aurez en plus les routes statiques pour le téléchargement des contenus annexes : feuilles de style, scripts côté client, …

Ressources

Les guides des évènements

• dblclick
• Drag and drop,
• défilement,
• Évènements tactiles.

Parties optionnelles

• Ajouter la possibilité de modifier ses propres post-its.

• Définir quatre niveaux d’accès à l’application : création, modification, effacement, administration. Les administrateurs ont droit de modifier/effacer les post-its de tout le monde. Ajouter une page d’administration, accessible uniquement aux administrateurs, pour donner/enlever ces droits aux utilisateurs.

  Créer un utilisateur spécial guest, qui correspond aux droits des utilisateurs non-connectés.

• Gérer plusieurs tableaux de post-its : dans ce cas, chaque tableau a un identifiant (par exemple toto, et sera accessible à l’adresse http://serveur-postits/toto).

• Gérer le drag ‘n drop: les utilisateurs ont droit de déplacer leurs propres post-its. Déplacer un post-it le remet en avant par rapport aux autres.

• Vérifier que votre affichage est adapté à tous les écrans, notamment aux écrans mobiles. Ajouter de la gestion d’évènements tactiles, et tester avec un téléphone ou tablette.

• Utiliser la roue de la souris pour zoommer et dézoommer sur le tableau.

• Placer les post-its dans un espace à 3 dimensions, plutôt que sur un tableau plat.

• Utiliser une base de données No-SQL (par exemple MongoDB) à la place de SQL.

• Faire en sorte qu’à chaque ajout/suppression/modification d’un post-it, tous les navigateurs qui affichent le même tableau soient mis à jour automatiquement.

Le but du projet est de développer une application permettant de créer des présentations sous forme de diapositives. L’application permettra également de faire défiler les diapositives grâce à un téléphone (ce dernier servant alors de “pointeur”).

Vous pourrez présenter votre projet en utilisant l’application que vous avez développée.

Les données

On peut envisager deux tables : une table pour les utilisateurs, et une table pour les présentations.

Une présentation comprend :

• un titre,
• un créateur,
• une liste de diapositves.

Trois modèles de diapositives seront proposés à l’utilisateur :

• “titre” : l’utilisateur peut uniquement rentrer un court texte (par exemple pour séparer des sections de la présentation),
• “texte + image” : l’utilisateur peut rentrer un texte et spécifier l’URL d’une image déjà présente sur le Web,
• “texte + code” : l’utilisateur peut rentrer un texte et un code source informatique (par exemple pour expliquer une suite d’instructions).

Dans un premier temps, l’utilisateur n’a pas le choix de la disposition du texte par rapport à l’image, ni de la police.

Ces données seront stockées dans une table SQL avec 3 colonnes :

• titre (de type texte),
• créateur (clef étrangère vers la table utilisateur),
• charge utile (de type texte, encondant la liste des diapositives en format JSON).

Les actions possibles

Comme dans le TD, donner la possibilité aux utilisateurs de créer un compte et de s’enregistrer.

Un fois enregistré, l’utilisateur peut:

• créer une nouvelle présentation,
• voir la liste des présentations qu’il a créées et les modifier,
• lancer une présentation en mode “visionnage” (en utilisant l’ordinateur relié au vidéo projecteur par exemple),
• prendre le contrôle d’une de ses présentations (en utilisant son téléphone par exemple), c’est à dire pouvoir faire défiler les diapositives en avant ou en arrière.

Remarque : il est envisageable que le mode “visionnage” soit accessible à n’importe qui. Cependant, le mode “contrôle” doit être uniquement accessible par le propriétaire de la présentation.

Côté technique :

• au lancement d’une présentation, le navigateur ouvre une websocket vers le serveur pour recevoir des ordres comme “avancer/reculer” (c’est à peu près le seul endroit où une websocket est indispensable);
• depuis le téléphone contrôlant la présentation, lorsque l’utilisateur fait avancer les diapositives, une requête est envoyée au serveur, qui transfère l’ordre au navigateur via la websocket.

Parties optionnelles

• Utiliser l’API “Touch Event” pour gérer le contrôle de la présentation (par exemple, un glissement vers la droite fait avancer d’une diapositive).

• Utiliser une base de données NO-SQL (comme MongoDB) au lieu d’une base SQL.

• Ajouter la possibilité au présentateur de pointer des choses sur l’écran en agissant sur son téléphone (par exemple pour surligner un bout de texte ou une image…).

• Permettre aux personnes du public, mêmes si elles n’ont pas de compte, de suivre la présentation en mode visionnage (sur leur téléphone ou ordinateur). À tout moment, tous les visionneurs doivent voir le même transparent, peu importe à quel moment ils ont commencé à suivre la présentation.

• Dans le cadre de la question précédente, afficher au début de la présentation, un code QR encodant l’URL de la présentation. Flasher le code amène à la présentation en mode visionnage. Vous pouvez vous servir d’une bibliothèque.

• Permettre également au public de poser des questions pendant la présentation. Les questions seront affichées à la fin de la présentation.

• Ajouter la possibilité d’inclure des images directement dans la présentation, sans besoin de pointer vers un serveur externe. Le plus simple est d’encoder les images en base64. Alternativement vous pouvez téléverser les images et les stocker dans la base de données.

• Améliorer l’interface d’édition des diapositives. Par exemple, en permettant à l’utilisateur de créer des blocs déplaçables à la souris (on pourra utiliser des <div> avec comme propriété CSS position; absolute et modifier les propriétés left et top en écoutant les événements mousedown et mousemove).

Le but de ce projet est de développer un jeu de Tron (snake) multi-joueurs en temps réel.

Description du jeu

Dans un jeu de Tron, deux joueurs contrôlent un “serpent” (un scoot laser, en théorie) qui se déplace sur une grille n×n qui occupe tout l’écran. La tête du serpent peut être orientée dans les quatres directions haut, bas, gauche, droite, et à intervales réguliers (relativement rapides) le serpent avance d’une case.

Les serpents laissent derrière eux une trace, qui ne peut être franchie ni par l’autre joueur ni par eux mêmes: lorsqu’un serpent rencontre une trace, il est éliminé.

Cette vidéo illustre bien le principe.

Description du projet

Vous devez réaliser un jeu en ligne sur le modèle vu en TD. Il doit comporter :

• Une page permettant de s’enregistrer,
• Une page présentant la liste des utilisateurs en ligne, leur nombre de parties gagnées/perdues, et autres informations éventuelles,
• Un mécanisme pour se connecter,
• Un mécanisme permettant de défier un adversaire,
• Une interface permettant de jouer le jeu.

L’interface du jeu sera réalisée en JavaScript, le contrôle du serpent pouvant se faire au clavier.

Soyez attentifs avec la gestion de l’état du jeux: Tron nécessite d’un horloge interne qui régit l’avancement des serpents. Si les clients étaient les seuls responsables du maintient de l’horloge, ils se désynchroniseraient très facilement, ou, pire, il serait facile de tricher.

Ressources

• Pour la communication entre clients, préférez les WebSockets. Vous êtes libres d’utiliser votre bibliothèque WebSocket préférée.

• Pour dessiner la scène de jeu, vous avez le choix parmi ces techniques:

  • Une table HTML,
  • Un layout en grille CSS,
  • Une balise <svg>, possiblement à l’aide d’une bibliothèque,
  • Une balise <canvas>, voir ce tutoriel.

Parties Optionnelles

• Permettre de jouer à plus que deux joueurs (typiquement 4).

• Ajouter des difficultés au jeu, par exemple :

  • Des obstacles additionnels apparaissent au hasard ;
  • Des bonus apparaissent au hasard, donnant des pouvoirs aux serpents (par ex., casser une trace) ;
  • La grille de jeu est torique, c.-à-d. les serpents qui sortent par la gauche rentrent par la droite, et vice-versa ; même chose pour haut-bas ;
  • La vitesse des serpents augment avec le temps ;
  • …

• Utiliser une base de données No-SQL (par exemple MongoDB) à la place de MySQL.

• Permettre de contrôler le personnage avec un gamepad ou un joystick (voir la Gamepad API).

• Adapter le jeux aux petits touch screens (par ex., un smartphone), avec les Touch gestures.

• Transformer le jeu en 3D (déplacement dans un cube, vue en subjectif) en utilisant la technologie WebGL, par exemple avec la bibliothèque three.js.