Propositions de projet

Le but de ce projet est de développer une version simplifiée du jeu multi-joueurs Curiosity.

Description du jeu

Curiosity était un jeu vidéo expérimental, ainsi qu’une expérience sociale consistant en un pavage cubique composé d’environ 69 milliards de petits cubes, formant un grand cube d’environ 4000 cubes de côté.

Il existe un unique grand cube dans le jeu, et son état est stocké sur le serveur. Les joueurs agissent tous en parallèle sur l’état global, en cliquant les petits cubes, ce qui les fait disparaître. Le but du jeu est de casser tous les cubes, une couche à la fois, jusqu’à révéler le noyau du cube. Les joueurs gagnent des points au fur et à mesure qu’ils détruisent les petits cubes; les points accumulés peuvent être dépensés en upgrades variés. Le premier joueur à atteindre le noyau est déclaré le gagnant.

Dans ce projet nous allons développer une version simplifiée du jeu, ne comportant pas d’éléments 3D. L’état du serveur consiste en une tour de n étages, chaque étage étant pavé par une grillé m×m de pavés. Le but des joueurs est de casser la tour, pavé par pavé, un étage à la fois, jusqu’à arriver au sol. Les joueurs gagnent un point pour chaque pavé cassé, mais dans cette version simplifiée ils n’auront pas d’upgrades pour les dépenser. Le premier joueur qui atteint le sol a gagné.

Description du projet

Vous devez réaliser le jeu de Curiosity simplifié, en vous inspirant du modèle vu en TD. Notez bien que tous les joueurs jouent en parallèle sur la même tour (tower), et qu’il n’y a pas de concept de tour (turn) de jeu, contrairement à Puissance 4. Vous devrez être particulièrement vigilants à ce que deux jouers cliquant sur un même pavé en même temps ne gagnent pas tous les deux le point. Pour que l’interface soit intuitive les mises à jour de l’affichage doivent se faire le plus vite possible.

Votre application doit comporter :

• Une page permettant de s’enregistrer,
• Une page présentant la liste des utilisateurs en ligne, leur score actuel, et autres informations éventuelles,
• Un mécanisme pour se connecter,
• Une interface permettant de jouer le jeu.

L’interface du jeu doit être réalisée en JavaScript. Les mises à jours doivent se faire en temps réel (WebSocket ou EventSource avec Node.js), ou quasi-réel (polling avec PHP, remarquez que ceci devient très lourd dès qu’il y a beaucoup de joueurs).

Ressources

• Pour la communication entre clients, vous avez le choix entre les deux technologies de communication bidirectionnelle :

  • EventSource,
  • WebSockets,

  ou à défaut du polling avec XMLHttpRequest.

• Pour le dessin de l’interface de jeux vous avez deux choix :

  • Une interface minimaliste, avec une grille de jeux représentée par un tableau HTML ou similaire. Ceci est assez similaire à ce qui a été vu en cours pour le plateau de puissance 4.

  • Une interface plus fluide, utilisant la balise <canvas> pour dessiner directement avec des primitives graphiques. Vous pouvez suivre ce tutoriel.

Parties optionnelles

• Ajoutez la possibilité d’acheter des upgrades avec les points collectés. Donnez libre cours à votre imagination, voici quelques exemples :

  • Gros doigts : un clic détruit plusieurs pavés dans un rayon donné ;
  • Clics automatiques : un curseur clique pour vous toutes les x secondes ;
  • Exclusivité : vous êtes le seul à pouvoir cliquer pendant les prochaines x secondes ;
  • …

• Ajoutez la possibilité pour le serveur d’héberger plusieurs parties en même temps. L’interface listera les parties en cours, et permettra de créer une nouvelle partie, avec un identifiant choisi aléatoirement. Chaque joueur pourra rejoindre n’importe quelle partie active.

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

• Ajoutez la possibilité de zoomer et de se déplacer à la souris, ou au toucher (sur écran tactile). Lisez les documentations de:

  • L’évènement drag,
  • L’évènement wheel,
  • Les évènements tactiles.

• Implantez le vrai jeu de Curiosity sur un cube 3D. Utilisez la bibliothèque three.js pour l’affichage.

Le but du projet est de créer une version simplifiée d’un doodle, permettant à plusieurs utilisateurs de se mettre d’accord sur une date. Chaque utilisateur peut voter pour les dates où il est disponible, et tout le monde voit quelles dates ont le plus de consensus.

Description

Un doodle n’est qu’une collection de préférences individuelles pour des jours de l’année. Une préférence est composée au moins de :

• une date,
• un créateur.

Ces champs sont reflétés dans une table MySQL. Une autre table MySQL sera utilisée pour stocker les utilisateurs, leurs mots de passe, et une couleurs qu’ils auront choisi au moment de la création du compte.

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 le calendrier du mois, 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

Sur la page principale, le planning du mois courant apparaît sous la forme d’une grande table, avec une semaine par ligne et une case par jour. Le tableau doit être généré par JavaScript. La hauteur des cases doit être fixe.

Les préférences pour une date sont représentés en ajoutant un bloc (un carré, ou une barre), coloré aux couleurs des utilisateurs, pour chaque utilisateur ayant voté pour celle-ci. La case affiche aussi le nombre total d’utilisateurs s’étant exprimés favorablement. Voici à quoi cela pourrait ressembler :

Des boutons/menus permettent de naviguer dans les mois.

Ajout/suppression d’une préférence

Uniquement les utilisateurs connectés ont droit de répondre au doodle. Il vont faire cela en interagissant avec le tableau du mois.

Un clic sur une case va engendrer une des deux actions suivantes :

• Si l’utilisateur ne s’est pas déjà exprimé favorablement pour cette date, une préférence est ajoutée à la base de données ;
• Si l’utilisateur s’est déjà exprimé favorablement, tous les blocs colorés de la case sont grisés, à l’exception du sien ; un clic sur son propre bloc, efface la préférence ; un clic ailleurs revient en mode normal.

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

Attention : prêtez attention à vérifier la validité d’une insertion/suppression du côté serveur, et pas uniquement du côté client. Sans cette vérification, vous risquez d’ajouter une même préférence deux fois. Affichez un message d’erreur sensé lorsque cette étape de validation ne passe pas.

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 une préférence.
  • 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 une préférence.
  • Si AJAX, renvoie un code de succès/erreur.
  • Si non-AJAX, redirige vers / après un ajout réussi.
• Route /préférences : renvoyant la liste de toutes les préférences exprimées au format JSON (ou XML, ou autre), pour la mise à jour de l’affichage client après une action. 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

• mousedown,
• mouseup,
• Drag and drop,
• Évènements tactiles.

Parties optionnelles

• Permettre de basculer entre le mode d’affichage normal, et un autre mode où les jours sont rangés du plus voté au moins voté (et les jours sans votes ne sont pas affichés).

• Gérer les clics glissés (clics qui commencent sur une case et qui terminent sur une autre). Toutes les cases entre le début et la fin du clic sont sélectionnées ; si l’utilisateur s’est déjà prononcé en faveur de toutes ces dates, ses préférences sont effacées ; sinon, une préférence est ajoutée pour toute date qui n’est pas déjà sélectionnée. Utiliser des classes CSS pour visualiser la plage sélectionnée pendant le glissement.

• Ajouter la possibilité de créer plusieurs doodles indépendants, chacun comportant un id, et étant servi à une URL différente (par exemple le doodle toto sera accessible à l’adresse http://serveur-calendrier/doodle/toto).

• Définir quatre niveaux d’accès au doodle : création, modification, effacement, administration. Les administrateurs ont droit de modifier/effacer les préférences de tout le monde. Ajouter une page d’administration, accessible uniquement aux administrateurs, pour donner/enlever ces droits aux utilisateurs.

• Réaliser un affichage qui s’adapte à la taille de l’écran, notamment aux écrans mobiles. Ajouter de la gestion d’évènements tactiles, et tester avec un téléphone ou tablette.

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

• Utiliser AJAX pour ne télécharger de la base de données que les préférences du mois visualisé.

  Ou, encore mieux : pour rendre l’interface plus fluide, vous pouvez télécharger en même temps le mois courant, le mois précédent et le mois suivant. Lorsque l’utilisateur navigue dans les mois, vous utilisez la liste de préférences stockée en cache pour afficher le nouveau mois immédiatement, et vous lancez une nouvelle requête AJAX pour télécharger le contenu du nouveau bloc de trois mois. Gardez à l’esprit que le contenu d’un mois peut avoir changé entre le moment où les données ont été téléchargées, et le moment où l’utilisateur demande une navigation.

• Faire en sorte qu’à chaque modification de préférence, tous les navigateurs qui affichent le même doodle soient mis à jour automatiquement.

Le but de ce projet est de développer un jeu multi-joueurs en temps réel. On va s’inspirer des modalités battle présentes dans les différentes sorties de la saga Super Mario Bros. développée par Nintendo.

Description du jeu

Le battle mode de Super Mario Bros. 3 est décrit en détail dans cette page de StrategyWiki. Vous pouvez aussi regarder cette vidéo démontrant une partie.

Nous allons implanter une version simplifiée du jeu, dans laquelle au moins deux personnages évoluent dans une grille de jeu régie par la gravité. Les personnages sont contrôlés par les touches directionnelles du clavier : ils peuvent avancer, reculer, s’accroupir et sauter. Les bords gauche et droite de la grille sont reliés : un personnage sortant par la droite réapparaît par la gauche, et inversement.

Lorsqu’un personnage réussit à sauter sur la tête d’un autre, ce dernier est éliminé et disparaît du jeu. Le dernier joueur restant en jeu est déclaré gagnant.

Note : on vous rappelle que la franchise Super Mario est un copyright de Nintendo. Si vous avez droit de développer le jeu dans un but pédagogique, mettre votre application à disposition du public aurait des implications légales fâcheuses.

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 ou plusieurs adversaires,
• Une interface permettant de jouer le jeu.

L’interface du jeu sera réalisée en JavaScript. Pour faire simple, bornez-vous au possibilités décrites plus haut. Des améliorations imitant le jeu original sont proposées dans les parties optionnelles.

Ressources

• Pour la communication entre clients, vous avez le choix entre les deux technologies de communication bidirectionnelle :

  • EventSource,
  • WebSockets.

• Pour dessiner la scène de jeu, il est conseillé d’utiliser l’API canvas. Vous pouvez suivre ce tutoriel.

##Parties Optionnelles

• Ajouter des caractéristiques du jeu original, ou de votre crû :

  • Les personnages doivent recevoir plusieurs coups avant d’être éliminés ;
  • Présence d’upgrades (champignons et similaires) ;
  • Présence de plate-formes que les personnages peuvent escalader ;
  • Présence d’ennemis contrôlés par l’ordinateur ;
  • Autres modalités de jeu : contre la montre, collection de pièces, … ;
  • …

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

• Proposer un “éditeur de niveaux” pour construire des grilles personnalisés.

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

• Transformer le jeu en 3D en utilisant la technologie WebGL, par exemple avec la bibliothèque three.js.

Le but de ce projet est de réaliser un jeu de Pong dont les raquettes sont contrôlées par les accéléromètres de téléphones portables ou tablettes.

Description du jeu

Pong est un jeu à deux joueurs en temps réel, inspiré du tennis et du ping pong. Sur deux côtés opposés de l’écran, deux raquettes se déplacent sur des axes parallèles sont contrôlées par les joueurs. Une balle est lancée par le jeu en direction de l’un des deux joueurs, qui doit déplacer sa raquette en face de la balle pour pouvoir la renvoyer à l’adversaire.

Le joueur qui laisse une balle sortir par son côté de l’écran fait marquer un point à son adversaire. Lorsque la balle rencontre un mur perpendiculaire aux raquettes, elle rebondit. La vitesse et la direction avec lesquelles la balle rebondit après avoir rencontré une raquette sont déterminées en fonction de la distance du point d’impact au centre de la raquette.

Cette vidéo vous donnera des explications plus claires que mille mots.

Description du projet

Le but de ce projet est de réaliser un jeu de pong à deux utilisateurs, où le contrôle de la raquette se fait à l’aide des accéléromètres installés dans un téléphone portable ou une tablette.

Pour la partie applicative, vous pouvez suivre le modèle vu en TD. Elle 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 de jeu doit être réalisée en JavaScript, et utiliser les techniques de communication bidirectionnelles pour faire les mises à jour en temps réel.

Le contrôle des raquettes doit se faire à travers l’API DeviceMotion, supportée par la plus part des navigateurs mobiles. Pour tester si votre téléphone supporte l’API, vérifiez que les barres dans l’exemple ci-dessous réagissent à vos mouvements:

• Les trois premières barres représentent votre accélération absolue (sans tenir compte de la force de gravité) ;
• Les trois barres suivantes représentent votre accélération, incluant la force de gravité ;
• Les trois dernières représentent votre accélération angulaire.

DeviceMotion demo

Deux autres APIs peuvent vous aider à offrir un meilleur contrôle :

• DeviceOrientation, pour connaître l’orientation de votre téléphone par rapport à l’axe de gravité;

• L’événement orientationchange, pour détecter le passage du mode paysage au portrait.

Note : on vous rappelle que le jeu Pong est un copyright de Atari. Si vous avez droit de développer le jeu dans un but pédagogique, mettre votre application à disposition du public aurait des implications légales fâcheuses.

Ressources

• Pour la communication entre clients, vous avez le choix entre les deux technologies de communication bidirectionnelle :

  • EventSource,
  • WebSockets.

• Pour l’API DeviceMotion, se référer à ce guide MDN, ainsi qu’au Codepen d’exemple.

• Pour le dessin de l’interface vous pouvez utilser le DOM, ou alors l’API <canvas> qui permet de dessiner directement avec des primitives graphiques. Vous pouvez suivre ce tutoriel.

Parties optionnelles

• Permettre la connexion de certains clients en mode affichage seul, et de certains autres en mode contrôleur. De cette façon, vous pourrez utiliser le téléphone comme une manette de jeu, tout en affichant la partie sur un autre écran.

• Passer en mode 3D simulée: la perspective sera subjective, avec la balle qui s’agrandit en approchant et rétrécit en s’éloignant, et la raquette qui peut se déplacer sur un plan plutôt que sur une droite. L’API Canvas peut suffire à réaliser cette partie, ou alors la bibliothèque three.js vous permet de créer des scènes plus réalistes.

• Mode multi-joueurs: accepter jusqu’à n joueurs, en les plaçant sur les sommets d’un n-gone régulier. Les raquettes pourront maintenant se déplacer sur un arc de cercle autour du joueur, et il y aura potentiellement plusieurs balles.

• Mode multi-joueurs 3D: en combinant les deux parties précédentes, vous permettrez aux raquettes de se déplacer sur un cylindre.