Propositions de projet
Cette page présente les typologies de projet de développement acceptées aux fins de validation du contrôle continu. Les projets ne sont pas tous du même niveau : pour chacun on indique une estimation de sa difficulté, et la note maximale à laquelle vous pouvez aspirer en développant celui-ci.
Vous devez respecter les contraintes suivantes :
-
Les projets sont à développer en groupe, idéalement en trinôme.
-
Le code source est à rendre par mail au plus tard le dimanche 3 mai.
-
Le projet doit faire l’objet d’une présentation orale la semaine du 18-22 mai. Vous avez la possibilté de corriger votre code et y ajouter des fonctionnalités en vue de la soutenance. Le code soumis avant le 3 mai et le code final seront également jugés.
-
Un kickstarting/review de votre projet sera fait en semaine 9 sur la séance de TD habituelle. La présence à cette séance est obligatoire. Les groupes et les sujets devront être arrêtés à cette date, et ne pourront plus être modifiés, sauf dérogation exceptionnelle.
Il est conseillé d’héberger votre projet pour la démonstration finale. Heroku et Openshift sont deux plateformes gratuites d’hébergement avec support pour PHP, Node.js et MySQL.
Calendrier
- Frameworks : Node, Silex
- Difficulté :
- Mots-clé : ajax
Le but du projet est de définir une application permettant de gérer un calendrier personnel, un peu comme Google Calendar. Le meilleur projet sera utilisé, avec votre permission, pour l’organisation des soutenances de projet !
Description
Un calendrier est une suite d’événements, qui ne doivent jamais se chevaucher ou se superposer. Un événement a au moins :
- un titre,
- une date et heure de début,
- une date et heure de fin,
- un créateur.
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.
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 planning de la semaine, 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 de la semaine courante apparaît sous la forme d’une grande table, avec une colonne par jour. En première approximation, vous pouvez découper chaque jour en 48 cases d’une demie heure chacune. Le tableau doit être généré par JavaScript. La hauteur des cases doit être fixe.
Les évènements sont représentés en colorant les plages horaires occupées, par exemple en rouge. Utilisez des classes CSS pour distinguer les cases libres des cases occupées. La première case d’un évènement doit contenir le titre et le créateur de l’évènement.
Des boutons/menus permettent de naviguer dans les semaines.
Note : Il existe d’autres solutions, que de diviser le jour en 48 plages. Par exemple vous pouvez utiliser du positionnement CSS et des hauteurs fixes. Les possibilités sont nombreuses, et permettent de réaliser des grains plus fin que la demie heure. Libre à vous de les explorer.
Ajout d’un nouvel évènement
Uniquement les utilisateurs connectés ont droit de modifier le calendrier. Il vont faire cela en interagissant avec le tableau de la semaine.
Un clic sur une case déjà occupé ne fait aucune action, ou donne un message d’erreur, au choix.
Un clic sur une case libre ouvre un popup, permettant de préciser le titre de l’évènement, de modifier les heures de début et de fin, et éventuellement d’autres informations (couleur, description, etc…). Après validation, une requête est envoyée au serveur et l’événement est inséré dans la base de données. Si l’insertion s’effectue avec succès, le nouvel évènement est affiché dans le tableau.
Une interaction de type AJAX et préférable pour cette action.
Attention : prêtez attention à vérifier la validité d’un évènement (format des dates, non-chevauchement, etc.) du côté serveur, et pas uniquement du côté client. Si plusieurs utilisateurs modifient en même temps le calendrier, rater cette vérification peut amener à des conflits. Affichez un message d’erreur significatif lorsque cette étape de validation ne passe pas.
Suppression d’un évènement
En plus d’afficher les informations décrites ci-dessus, uniquement pour les évènements créés par l’utilisateur connecté, donner un moyen (bouton, lien, croix, …) de supprimer l’évènement. 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 évènement.- 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 évènement.- 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 événements 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
Parties optionnelles
-
Ajouter la possibilité de modifier ses propres évènements.
-
Gérer les clics glissés (clics qui commencent sur une case et qui terminent sur une autre). Les heures de début et de fin seront respectivement la plus petite et la plus grande parmi les deux cases. Utiliser des classes CSS pour visualiser la plage sélectionnée pendant le glissement.
-
Définir quatre niveaux d’accès au calendrier : création, modification, effacement, administration. Les administrateurs ont droit de modifier/effacer les évènements 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 calendriers : dans ce cas, chaque calendrier a un identifiant (par exemple toto, et sera accessible à l’adresse http://serveur-calendrier/toto).
-
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.
-
Faire en sorte que 15 minutes avant un évènement, un message d’alerte soit affiché sur la page.
-
Utiliser AJAX pour ne télécharger de la base de données que les évènements de la semaine visualisée.
Ou, encore mieux : pour rendre l’interface plus fluide, vous pouvez télécharger en même temps la semaine courante, la semaine précédente et la semaine suivante. Lorsque l’utilisateur navigue dans les semaines, vous utilisez la liste d’évènements stockée en cache pour afficher la nouvelle semaine immédiatement, et vous lancez une nouvelle requête AJAX pour télécharger le contenu du nouveau bloc de trois semaines. Gardez à l’esprit que le contenu d’une semaine 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 d’événement, tous les navigateurs qui affichent le même calendrier soient mis à jour automatiquement.
Find my Friends
- Frameworks : Node
- Difficulté :
- Mots-clé : mobile, géolocalisation, multi-utilisateur
Le but de ce projet est de développer une application similaire à l’application iPhone Find my friends.
Il s’agit d’une application pour appareils dotés de géolocalisation. L’application utilise ces données pour montrer en temps réel la distance et la direction des autres utilisateurs connectés.
Afin de pouvoir tester l’application, il est impératif de disposer de plusieurs appareils munis de géolocalisation. Puisque cette application utilise des technologies web non-standardisées, elles ne peut être compatible qu’avec les appareils suivants :
- téléphones et tablettes Android avec navigateur Firefox,
- téléphones et tablettes Firefox OS,
- ordinateurs munis de GPS.
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.
-
Lorsque le client se connecte à l’application, deux possibilités lui sont offertes :
- Rejoindre une chambre déjà existante,
- Créer une nouvelle chambre.
Note : C’est votre responsabilité que définir le comportement lorsque un utilisateur essaye de créer une chambre déjà existante.
Note : Limitez le nombre d’utilisateurs par chambre à 2.
-
Chacun des deux utilisateurs connectés à une chambre communique en continu au serveur sa position GPS. Le serveur transmet cette information à l’autre utilisateur.
-
Chaque utilisateur, à la réception de la position de l’autre, visualise sa position avec une flèche pointant dans sa direction, et la distance de celui-ci.
Note : afin de pouvoir diriger la flèche, vous devez accéder aux données de la boussole de l’appareil. En première approximation, vous pouvez afficher un cap à la place de la flèche (par ex.: 20° Nord), ce qui ne nécessite pas de boussole.
Note : cette partie nécessite de savoir faire des calculs géodésiques. C’est des mathématiques de niveau L1, mais si vous y êtes allergiques, ce projet n’est pas pour vous.
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, il est nécessaire d’héberger le serveur à une adresse accessible depuis le web. Nous conseillons les hébergeurs gratuits suivants :
Ressources
-
Pour la communication entre clients, vous avez le choix entre les deux technologies de communication bidirectionnelle :
-
Les données de géolocalisation doivent être interrogées avec l’API web https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/Using_geolocation.
-
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.
Parties optionnelles
-
Faire vibrer les appareils lorsque la distance est inférieure à un seuil.
-
Permettre la privatisation d’une chambre avec mot de passe (nécessite l’ajout d’une base de données).
-
Autoriser plus de 2 utilisateurs par chambre, et afficher une flèche pour chacun.
-
Ajouter une visualisation des positions sur carte.
Labyrinthe 3D avec WebGL
- Frameworks : Node, Silex
- Difficulté :
- Mots-clé : WebGL, 3D
Le but de ce projet est de développer un labyrinthe en 3D (vue en première personne), ainsi que son éditeur de cartes.
L’application tournera sur un ordinateur muni d’une carte graphique et d’un browser compatible webGL (Firefox et Chromium-browser fonctionneront avec la plupart des cartes nvidia et ati).
Description
On considèrera des labyrinthes dont le plan en 2D est construit sur la base d’un quadrillage en petits carrés, dans lequel certaines cloisons entre deux carrés adjacents ont été supprimées.
Les cloisons qui restent forment les murs du labyrinthe, et peuvent avoir chacune sa couleur. Le joueur démarre depuis un des carrés, qui est désigné comme la case initiale, et doit trouver son chemin vers un carré désigné comme la case finale.
Le but du projet consiste en la création d’un éditeur de labyrinthe entièrement en ligne. On devra être capable de créer, supprimer ou éditer la couleur de chaque cloison en quelques clics. Le labyrinthe sera naturellement sauvegardé dans une base de donnée, et pourra être réédité ultérieurement.
Ensuite, il faut créer le jeu en lui même. On utilisera le framework Three.js afin d’afficher le labyrinthe en 3D, en vue à la première personne. On utilisera la souris pour tourner la caméra, et le clavier pour avancer. Le joueur gagne lorsqu’il atteint la case finale, et le temps qu’il a mis est enregistré dans les high-scores du labyrinthe dans la base de donnée.
Ressources
-
Pour le moteur graphique, vous pourrez utiliser la librairie Three.js (à moins que vous ne souhaitiez reprogrammer tous les shaders à la main…):
Parties optionnelles
-
Faire un mode multijoueur dans lequel vous mettez plusieurs joueurs en temps réel sur le même labyrinthe, et le premier qui arrive gagne. Un joueur peut être modélisé par une boule colorée qui avance dans le labyrinthe.
-
Utiliser une base de données No-SQL (par exemple MongoDB) à la place de MySQL.
-
Permettre un mode spectateur en 2D.
-
Ajouter d’autres règles (téléportation d’une case à une autre, possibilité de détruire des cloisons, possibilité de traverser temporairement une cloison, possibilité de tuer des adversaires qui sont dans la même case…)
Mau mau
- Frameworks : Node
- Difficulté :
- Mots-clé : multi-utilisateur, jeu
Le but de ce projet est de réaliser un jeu de cartes en ligne multi-utilisateur. Il s’agit du jeu Mau mau, ancêtre de Uno populaire en Allemagne.
Description du jeu
Le jeu de Mau mau se joue ainsi :
-
Un jeu de cartes est mélange. 7 cartes sont distribuées à chaque joueur. On pose le reste du jeu, face cachée, au milieu.
-
On découvre la première carte du jeu et on la pose par terre.
-
À tour de rôle, chacun des joueurs a droit de poser par dessus la carte découverte une de ses cartes qui a soit la même enseigne (cœurs, carreaux, trèfles, piques), soit la même valeur.
S’il ne peut pas poser de carte, il en pioche une du jeu face cachée. Il la joue s’il peut, sinon il la met dans son jeu.
Un joueur a droit de piocher et passer son tour même s’il possède des cartes jouables dans son jeu.
-
Lorsque le jeu face cachée est épuisé, on prend la totalité des cartes découvertes à l’exception de la dernière, on les mélange et on les pose à nouveau face cachée.
-
Gagne le joueur qui se débarrasse en premier de son jeu.
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 :
- Le joueur voit uniquement sont jeu et la dernière carte découverte.
- Le joueur doit pouvoir sélectionner la carte à jouer en cliquant dessus.
- L’interface doit clairement montrer les cartes jouables.
- Lorsque il ne peut pas jouer, l’interface doit lui montrer clairement la nouvelle carte piochée, et lui permettre de la jouer si possible.
- Un bouton pour passer la main doit être présent.
Note : en première approximation, vous pouvez simplement représenter une carte par une boîte contenant sa description textuelle, ex. : « 7 de piques ». Si vous voulez utiliser des icônes, pensez à utiliser un jeu libre de droits ou avec une licence permissive.
Note : pour faire simple, limitez une partie à deux joueurs.
Ressources
Parties optionnelles
-
Tous les points optionnels du TD sur Puissance 4 sont aussi valables pour ce projet.
-
Permettez de faire des parties à un nombre arbitraire de joueurs.