Propositions de projet

Le but de ce projet est de réaliser un jeu de bataille navale en ligne multi-utilisateur.

Description du jeu

On rappelle le principe de la bataille navale.

• Deux joueurs disposent chacun d’une grille de jeu (par ex., de 10×10 cases).

• Chaque joueur dispose du même nombre de navires. Les navires peuvent occuper une, deux, trois ou quatre cases.

• Avant de commencer la partie, chaque joueur dispose ses navires sur sa grille.

• À tour de rôle, un joueur décide de frapper une case sur la grille du joueur adverse. S’il touche un navire, l’adversaire lui annonce « touché », sinon il lui annonce « manqué ». Lorsque toutes les cases d’un même navire ont été touchées, le joueur annonce « coulé ».

• Gagne le joueur qui en premier coule tous les navires de l’adversaire.

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 navires sont disposés aléatoirement ;
• Chauque joueur voit les deux grilles :
  • Sur sa propre grille toutes les informations sont affichées : disposition des navires, navires touchés/coulés, cases frappées ;
  • Sur la grille de l’adversaire, uniquement les cases frappées, touchées, coulées sont affichées, mais pas les bateaux.
• Le joueur doit pouvoir sélectionner la case à frapper en cliquant dessus.
• L’affichage montre clairement si la frappe a manqué/touché/coulé.
• Lorsqu’un joueur a coulé tous les navires de son adversaire, le jeu déclare le joueur gagnant.

Ressources

• Le TD sur Puissance 4 multi-utilisateurs,
• La page wikipedia du jeu de la bataille navale.

Parties optionnelles

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

• Créez une interface qui permet aux joueurs de placer leurs navires avant le début de la partie.

• Faites une version multi-joueurs du jeu : les joueurs sont séparés en deux équipes, qui essaient de collaborer pour vaincre les adversaires.

Le but de ce projet est de développer un jeu à deux joueurs en temps réel. On va choisir l’arcade très populaire Bomberman.

Description du jeu

Bomberman se joue de deux a quatre joueurs. Les joueurs démarrent aux coins opposés d’une une grille 11×11.

Les joueurs peuvent se déplacer librement dans la grille. Toutes les cases de coordonnées paires de la grille sont inaccessibles, formant ainsi des couloirs pour les joueurs.

Les joueurs disposent d’un nombre illimité de bombes à retardement, qu’ils peuvent placer dans une case libre. Les bombes explosent après un nombre prédéterminé de secondes. Aucun joueur ne peut déposer plus d’une bombe en même temps.

Lorsqu’une bombe explose, son explosion frappe dans quatres directions, jusqu’à une distance préderminée. Un joueur frappé par une explosion est éliminé du jeu.

Une vidéo va expliquer mieux que mille mots.

Description du projet

Vous devez réaliser un jeu de Bomberman 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. Pour faire simple, limitez vous à un jeu basique :

• Uniquement deux joueurs;
• Pas de murs autres que les murs indestructibles;
• Pas d’upgrades;
• Pas de temps limite.

Les joueurs peuvent contrôler leur personnage avec le clavier: flèches pour se déplacer, espace pour déposer une bombe.

Note : Pour 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, et où les déplacements des personnages se font de case en case. 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 dessinner directement avec des primitives graphiques. Vous pouvez suivre ce tutoriel.

Note : on vous rappelle que le jeu Bomberman est un copyright de Konami. 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.

Parties optionnelles

• Permettre des parties jusqu’à 4 joueurs.

• Ajouter des caractéristiques du jeu original, ou de votre crû : murs destructibles, upgrades, etc.

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

• Proposer un “éditeur de maps” pour construire des terrains de jeu personnalisés.

• Permettre de contrôler le personnage à la souris : clic gauche pour se déplacer, clic droit pour déposer une bombe. Quel parcours choisir lorsque le déplacement ne peut pas se faire en ligne droite ?

• Transformer le jeu en 3D en utilisant la technologie WebGL. Cet exemple pourrait vous aider.

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 MySQL. Une autre table MySQL 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-ti

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

• 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 de ce projet est d’utiliser un smartphone comme télecommande pour contrôler un objet sur un écran distant. Pour développer ce projet vous aurez besoin d’un smartphone avec un navigateur web supportant l’API device orientation.

Les acceleromètres du téléphone vont contrôler les mouvements d’un objet (épée, sabre laser, ou similaire) sur l’écran d’un autre appareil connecté au serveur.

L’utilisation d’une base de données n’est pas obligatoire pour cette application.

Description

En imitant le modèle des chats, l’application compartimente les utilisateurs dans des chambres. Chaque chambre sera identifiée par une URL du type

http://application.com/aeadfw23x

où aeadfw23x est l’identifiant de la chambre. Les identifiants peuvent être générés aléatoirement, ou créés par les utilisateurs.

1. Lorsque le client se connecte à l’application, deux possibilités lui sont offertes :

   • Rejoindre/créer une chambre en modalité affichage, pour visualiser le sabre,
   • Rejoindre/créer une chambre en modalité contrôleur, pour contrôler le sabre avec un smartphone.

   Chaque chambre accepte au plus un contrôleur, mais peut avoir un nombre arbitraire d’afficheurs.

2. Le contrôleur communique en continu son orientation, obtenue à travers l’API device orientation.

3. Les afficheurs reçoivent les données sur l’orientation, et modifient l’affichage du sabre en conséquence.

L’application peut être testée en local en connectant le serveur et les clients mobiles au même réseau local (par ex.: un réseau wifi), ou en utilisant le serveur de Cloud9. Pour un test hors du laboratoire (par ex., le jour de la soutenance), il est nécessaire d’héberger le serveur à une adresse accessible depuis le web. Cela peut être fait avec Cloud9, mais nous conseillons les hébergeurs gratuits suivants :

• Heroku,
• Openshift.

Ressources

• Pour le moteur graphique, vous pourrez utiliser la bibliothèque Three.js (à moins que vous ne souhaitiez reprogrammer tous les shaders à la main…):

  • Doc officielle de Three.js,
  • Un exemple parlant.

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

  • EventSource,
  • WebSockets.

• L’orientation de l’appareil doit être interrogée avec l’API web https://developer.mozilla.org/en-US/docs/Web/API/Detecting_device_orientation, éventuellement en combinaison avec l’API https://developer.mozilla.org/en-US/docs/Web/Events/devicemotion.

Parties optionnelles

• Créer une scène, par exemple une pièce avec des murs, ou un labyrinthe, pour les afficheurs.

• Comme dans un First Person Shooter, utiliser l’écran du smartphone comme un touchpad pour contrôler le mouvement du personnage : en déplaçant le doigt vers le haut/bas, le personnage avance/recule (la vitesse peut être proportionnelle à l’éloignement du milieu de l’écran). En déplaçant le doigt vers la gauche/droite, le personnage tourne à gauche/droite.

• Permettre à plusieurs contrôleurs de rejoindre une même chambre. Pour chaque contrôleur, un personnage est créé dans la scène, et affiché à tous les afficheurs.

• Créer une résolution de duels primitive : lorsque deux personnages sont suffisamment proches, ils ne peuvent pas se traverser. En vous basant sur les orientations des sabres, décidez qui des personnages a gagné le duel, et éliminez le perdant. Gagne le dernier personnage resté vivant.