This repository has been archived on 2024-04-18. You can view files and clone it. You cannot open issues or pull requests or push a commit.
2024-03-18 22:31:29 +01:00
2024-03-18 22:31:29 +01:00
2024-03-18 22:31:29 +01:00
2024-03-18 22:31:29 +01:00
2024-03-25 15:04:44 +01:00
2024-03-18 22:31:29 +01:00
2024-04-06 16:56:24 +02:00
2024-03-18 22:31:29 +01:00
2024-03-18 22:31:29 +01:00
2024-03-18 22:31:29 +01:00
2024-03-18 22:31:29 +01:00
2024-03-24 15:24:57 +01:00
2024-03-19 08:22:40 +01:00

BDW - Projet

DeezCycle 🚮

UCBL - DĂ©partement Informatique de Lyon 1 – Printemps 2024

Connect 🌐

ssh p22XXXXX@bdw.univ-lyon1.fr

Transfer 📬

scp -r ./DeezCycle p2203977@bdw.univ-lyon1.fr:~

Site đŸŽČ

https://bdw.univ-lyon1.fr/p22XXXXX/DeezCycle/

Table des matiĂšres

1 Informations générales sur le projet 1

2 SpĂ©cification de l’application 2

3 Mise en place de la Base de Données 5 3.1 Construction de la base de données................................... 5 3.2 Intégration des données fournies.................................... 5

4 Les fonctionnalitĂ©s 5 4.1 Page d’accueil et statistiques...................................... 6 4.2 FonctionnalitĂ© 1 : Liste des parties terminĂ©e et en cours....................... 6 4.3 FonctionnalitĂ© 2 : Mise en place de la partie.............................. 7 4.4 FonctionnalitĂ© 3 : DĂ©roulĂ© d’une partie................................. 8 4.5 FonctionnalitĂ© 4 : fonctionnalitĂ©s supplĂ©mentaires........................... 9

5 Déroulé du projet et jalons 9 5.1 Les jalons................................................. 9 5.2 Rendu du projet............................................. 9 5.3 Calendrier récapitulatif......................................... 10

6 ANNEXE A : Ă  propos de l’intĂ©gration de donnĂ©es 11

1 Informations générales sur le projet

Le projet est Ă  rĂ©aliser en binĂŽme (les trinĂŽmes ne sont pas autorisĂ©s). La rĂ©alisation du projet en monĂŽme nĂ©cessite l’accord du responsable de l’UE.

À noter que la rĂ©alisation du projet nĂ©cessitera un travail personnel et/ou collaboratif complĂ©mentaire au travail rĂ©alisĂ© durant les sĂ©ances de TP. Il est donc important de choisir un binĂŽme avec un emploi du temps compatible avec le vĂŽtre.

À propos de l’évaluation du projet

Le projet est Ă©valuĂ© Ă  travers les notes issues des diffĂ©rents QCM de Validation des Acquis pour le Projet, de l’évaluation des jalons et de la soutenance finale.

Gestion du plagiat. Il est important de noter que toute ressemblance trop importante entre des projets sera sanctionnée par un 0 à chacun des protagonistes.

BDW est avant tout une UE d’introduction aux bases de donnĂ©es. La non-utilisation d’une BD relationnelle dans le projet impactera forcĂ©ment la note de maniĂšre nĂ©gative.

Attention Ă  la gestion de votre temps! La mise en place de jalons rĂ©guliers est lĂ  pour vous aider dans ce sens. En effet, il a souvent Ă©tĂ© observĂ© que des Ă©tudiants passaient trop de temps sur les aspects modĂ©lisa- tion (avec l’objectif d’avoir un schĂ©ma EA parfait) au dĂ©triment du dĂ©veloppement des fonctionnalitĂ©s dont la

compréhension tardive imposait finalement de modifier le schéma EA a posteriori.

2 SpĂ©cification de l’application

L’objectif du projet est de dĂ©velopper un jeu de dĂ©s via une application web. Ce jeu est fortement inspirĂ© du jeu DICYCLE RACE prĂ©sentĂ© en cours.

Le principe du jeu est le suivant : chaque joueur est un cycliste qui doit arriver le premier au bout du parcours qui est composĂ© de 12 cartes. Pour avancer sur une case, il faut que le joueur rĂ©alise la combinaison de dĂ©s demandĂ©e sur la carte. Pour cela, chaque joueur dispose de 6 dĂ©s de couleur bleue, 6 dĂ©s de couleur jaune et 6 dĂ©s de couleur rouge. À chaque tour, le joueur choisit 6 dĂ©s parmi les 18 dĂ©s de couleurs pour essayer de valider une ou plusieurs cases en au plus 3 lancers. DiffĂ©rentes stratĂ©gies peuvent ĂȘtre mises en place en fonction du nombre de cartes que le joueur souhaite valider en un tour.

Cette section va vous permettre de modĂ©liser et concevoir la base de donnĂ©es sur laquelle s’appuiera votre application web. À partir de cette spĂ©cification, il est important de bien distinguer les donnĂ©es qui devront ĂȘtre stockĂ©es de celles qui seront calculĂ©es.

Dans un premier temps, nous considérons les joueurs. Les joueurs sont identifiés par un entier numérique et on stocke le nom, le prénom, la date de naissance, un pseudo et une adresse mail.

Un joueur joue des parties. Une partie est identifiĂ©e par une valeur numĂ©rique et on stocke la date et l’heure du dĂ©but de partie ainsi que la durĂ©e une fois que la partie est terminĂ©e. Une partie a donc un Ă©tat qui peut ĂȘtre ’A venir’ (partie paramĂ©trĂ©e et créée mais non encore commencĂ©e), ’En cours’ (partie en cours de jeu ou interrompue) et ’TerminĂ©e’ (partie oĂč tous les joueurs ont fini le parcours).

Pour chaque partie, on dispose d’un plateau composĂ© de plusieurs cartes. Chaque plateau a un nombre de cartes fixĂ©. Par dĂ©faut, un plateau est composĂ© de 12 cartes.

Pour chaque carte, on dispose d’une image pour reprĂ©senter le visuel de la carte. Une carte dispose d’un niveau (vert, orange ou noir) en fonction du niveau de difficultĂ© de celle-ci. Chaque carte dispose Ă©galement de points, lĂ  encore dĂ©finis en fonction de la difficultĂ© de la carte. Une carte est associĂ©e Ă  une ou plusieurs contraintes de base. Ces contraintes ont un nom et on en considĂšre quatre :

— une contrainte nommĂ©e "face de dĂ©" reprĂ©sentĂ©e par le couple ( coul , val ), oĂč coul ∈{’rouge’,’jaune’,’bleu’} et val ∈{1, 2, 3, 4, 5, 6} : Pour valider cette contrainte, le joueur doit obtenir au moins un dĂ© de couleur coul avec la valeur val. — une contrainte nommĂ©e "seuil de dĂ©s" reprĂ©sentĂ©e par le triplet ( coul , seuil , sens ), oĂč coul ∈{’rou- ge’,’jaune’,’bleu’}, seuil ∈{2,.. ., 36} et sens ∈{ < , > } : Pour valider cette contrainte, le joueur doit obtenir un score cumulĂ© de valeurs de dĂ©s de couleur coul qui soit strictement supĂ©rieur ou infĂ©rieur (selon la valeur de sens ) Ă  la valeur seuil. — une contrainte nommĂ©e "les mĂȘmes au choix" reprĂ©sentĂ©e par le couple ( coul , nb ), oĂč coul ∈{’rou- ge’,’jaune’,’bleu’} et nb ∈{2, 3, 4} : Pour valider cette contrainte, le joueur doit obtenir au moins nb dĂ©s de mĂȘme valeur et de couleur coul. — une contrainte nommĂ©e "suite au choix" reprĂ©sentĂ©e par le singleton ( coul , nb ), oĂč coul ∈ {’rou- ge’,’jaune’,’bleu’} et nb ∈{2, 3, 4} : Pour valider cette contrainte, le joueur doit obtenir au moins nb dĂ©s de valeurs successives et de couleur coul. À partir de ces contraintes, il est possible d’associer Ă  chaque carte une ou plusieurs contraintes. Ainsi, la Figure 1 reprĂ©sente trois cartes associĂ©es Ă  une ou plusieurs contraintes "face de dĂ©s".

La carte C005.png est associĂ©e Ă  une contrainte "face de dĂ©" (’bleu’,5). La carte C020.png est associĂ©e aux contraintes "face de dĂ©" (’bleu’,2) et (’rouge’,4). La carte C039.png est associĂ©e aux contraintes "face de dĂ©" (’jaune’,3), (’rouge’,3) (’bleu’,3). À noter que C039.png n’est pas associĂ©e Ă  une contrainte "les mĂȘmes au choix" car les couleurs imposĂ©es par dĂ© sont diffĂ©rentes.

Figure 1– Exemple de 3 cartes associĂ©es Ă  une ou plusieurs contraintes "face de dĂ©s"
Figure 2– Exemple de cartes associĂ©es Ă  des contraintes "face de dĂ©", "seuil de dĂ©s" et "les mĂȘmes au choix"

D’autres exemples sont sur la Figure 2. La carte C053.png est associĂ©e Ă  une contrainte "seuil de dĂ©s" (’jaune’,14, ’ > ’). La carte C072.png est asso- ciĂ©e aux contraintes "seuil de dĂ©s" (’rouge’,4, ’ < ’) et "face de dĂ©" (’jaune’,2). La carte C056.png est associĂ©e Ă  la contrainte "les mĂȘmes au choix" (’bleu’,3).

Pour finir, la Figure 3 reprĂ©sente trois cartes associĂ©es Ă  des contraintes "face de dĂ©", "les mĂȘmes au choix" et "suite au choix".

Figure 3– Exemple de 3 cartes associĂ©es Ă  une ou plusieurs contraintes "face de dĂ©s"

La carte C070.png est associĂ©e aux contraintes "les mĂȘmes au choix" (’jaune’, 2) et "face de dĂ©" (’jaune’, 2). La carte C068.png est associĂ©e Ă  la contrainte "sĂ©rie au choix" (’rouge’, 3). La carte C073.png est associĂ©e aux contraintes "les mĂȘmes au choix" (’bleu’,2) et "sĂ©rie au choix" (’rouge’, 2).

À noter que sur les 3 figures, le niveau des cartes est reprĂ©sentĂ© par la couleur de fond de la pastille des

points. Les cartes C005.png et C020.png sont des cartes vertes valant 1 point. Les cartes C053.png et C072.png sont des cartes vertes valant 2 points. Les cartes C039.png, C056.png, C070.png et C068.png sont des cartes oranges valant 4 points. Enfin la carte C073.png est une carte noire valant 5 points.

Au dĂ©but d’une partie, une couleur de pion est attribuĂ©e alĂ©atoirement Ă  chaque joueur. Chaque pion est placĂ© sur la carte ’dĂ©part’. Un ordre de passage est choisi. Trois modes sont possibles : — Un mode dit honneur au plus jeune : l’ordre de passage se fait du plus jeune au plus ancien en fonction de la date de naissance des joueurs. Pour les joueurs nĂ©s le mĂȘme jour, l’ordre de passage se fera en fonction du nom selon l’ordre lexicographique. — Un mode dit honneur au moins expĂ©rimentĂ© : l’ordre de passage se fait du joueurs ayant fait le moins de parties Ă  celui qui en a fait le plus. Pour les joueurs ayant fait le mĂȘme nombre de parties, l’ordre de passage se fera en fonction du nom selon l’ordre lexicographique. — Un mode dit alĂ©atoire : l’ordre de passage se fait de maniĂšre alĂ©atoire. Une partie se dĂ©roule en plusieurs tours (autant que nĂ©cessaires pour que tous les joueurs franchissent la carte ’arrivĂ©e’). À chaque tour, chaque joueur choisit une main constituĂ©e de 6 dĂ©s dont un certain nombre de dĂ©s rouges, de dĂ©s jaunes et de dĂšs bleus. À partir de cette main, le joueur a droit Ă  au plus 3 lancers. AprĂšs chaque lancer, le joueur sĂ©lectionne le ou les dĂ©s qui permettent de valider une ou plusieurs contraintes de la prochaine carte sur laquelle il veut avancer. Si toutes les contraintes de la carte sont validĂ©es, le pion du joueur peut alors avancer sur cette carte.

En termes de stratĂ©gie pour avancer plus vite, le joueur peut chercher Ă  valider plusieurs cartes lors d’un mĂȘme tour. Toutefois, s’il se trouve sur la carte n , qu’il arrive Ă  valider entiĂšrement les contraintes de la carte n +2mais que la carte n +1n’est pas entiĂšrement validĂ©e au bout des 3 lancers, le pion du joueur n’avancera pas.

L’ordre d’arrivĂ©e des joueurs permet d’établir le classement final.

La gestion des scores se fait de la maniĂšre suivante : — Pendant la partie, chaque joueur cumule les points des cartes qu’il a validĂ©es, points qui sont pondĂ©rĂ©es de la maniĂšre suivante, sachant qu’une tentative de validation correspond Ă  un tour (et non un lancer) : — le joueur cumule 3 fois le nombre de points de la carte, s’il la valide Ă  la premiĂšre tentative ; — le joueur cumule 2 fois le nombre de points de la carte, s’il la valide Ă  la seconde tentative ; — le joueur cumule le nombre de points de la carte, s’il la valide Ă  la troisiĂšme tentative ; — le joueur ne cumule aucun point au-delĂ  de la troisiĂšme tentative. — Pendant un tour, le nombre de points cumulĂ©s durant le tour est multipliĂ© par le nombre de cartes validĂ©es durant ledit tour. — À l’arrivĂ©e d’un joueur, son score correspond au nombre de points cumulĂ©s durant la partie multipliĂ© par la pondĂ©ration ÎŽ , oĂč ÎŽ correspond au nombre total de joueurs de la partie auquel on retranche le rang final dudit joueur augmentĂ© de un. Ainsi, pour une partie avec 5 joueurs, le joueur de rang 1 verra son nombre de points cumulĂ©s multipliĂ© par (5-1+1=) 5 et le dernier verra son nombre de points cumulĂ©s multipliĂ© par (5-5+1) = 1. ÉlĂ©ment trĂšs important : l’application doit permettre Ă  un joueur de se dĂ©connecter (volontairement ou non) et de pouvoir reprendre la partie lĂ  oĂč il en Ă©tait. Ainsi, la position des pions sur le plateau, la valeur des dĂ©s lancĂ©s durant un tour, le nombre de points cumulĂ©s, le nombre de tentatives de validation d’une carte par un joueur doivent ĂȘtre mĂ©morisĂ©s en base.

En marge des parties, on souhaite gĂ©rer Ă©galement l’organisation de tournois et les classements de joueurs. Concernant les tournois, un tournoi est identifiĂ© par un entier numĂ©rique et il a un nom, une date de dĂ©but et une date de fin. Un tournoi se dĂ©compose en phase. Une phase est identifiĂ©e relativement au tournoi par rapport Ă  un niveau ’Poule de sĂ©lection’, ’SeiziĂšme de finale’, ’HuitiĂšme de finale’, ’Quart de finale’, ’Demi-finale’ et ’Finale’. Un joueur participe Ă  une phase de tournoi et on stocke l’information si le joueur a jouĂ© la phase et s’il s’est qualifiĂ© pour la phase suivante ou pas. À noter que si le joueur est qualifiĂ© pour la phase de niveau ’Finale’, cela signifie qu’il a gagnĂ© le tournoi. Les diffĂ©rentes Ă©ditions des tournois sont gĂ©rĂ©es par le fait que les

tournois peuvent ĂȘtre en lien les uns avec les autres. Ainsi, le tournoi nommĂ© ’DeezCycle France 2024’ est en lien avec le tournoi nommĂ© ’DeezCycle Race France 2023’. Le type de lien entre les deux tournois est un lien d’édition. Les classements se font en fonction des points cumulĂ©s et du nombre de parties jouĂ©es. Un classement est identifiĂ© par un entier et on stocke la portĂ©e du classement (’internationale’, ’nationale’, ’rĂ©gionale’.. .). Il existe alors diffĂ©rents classements. Les joueurs peuvent ĂȘtre classĂ©s de maniĂšre individuelle ou en Ă©quipe. En effet, un joueur peut ĂȘtre membre d’une Ă©quipe. Les rĂ©sultats des membres d’une Ă©quipe sont agrĂ©gĂ©s, ce qui permet de classer les Ă©quipes. Au mĂȘme titre que les tournois, les classements peuvent ĂȘtre en lien. Ainsi, le Classement international ’World DeezCycle Ranking’ est en lien avec le classement national ’DeezCycle Race France’. Les types de lien peuvent ĂȘtre hiĂ©rarchiques.

3 Mise en place de la Base de Données

3.1 Construction de la base de données

Dans un premier temps, vous allez concevoir la base de données à partir des spécifications précédentes. Votre modélisation doit respecter au mieux ces spécifications.

  1. Produire un diagramme EntitĂ©/Association selon les spĂ©cifications fournies via l’outil mocodo (version en ligne https://www.mocodo.net/) ou Looping.
  2. Produire le modĂšle relationnel dĂ©rivĂ© de votre schĂ©ma EntitĂ©/Association. Attention : si vous gĂ©nĂ©rez automatiquement ce schĂ©ma avec l’outil de modĂ©lisation, il est fortement recommandĂ© de le vĂ©rifier pour Ă©ventuellement le corriger ou le complĂ©ter.
  3. Produire le script SQL permettant le création de votre base de données ( idem que précédemment, il sera sûrement nécessaire de le modifier si vous le générez automatiquement).

3.2 Intégration des données fournies

Dans un deuxiĂšme temps, vous allez migrer les donnĂ©es existantes fournies dans la base de donnĂ©es dataset dans votre base de donnĂ©es. L’utilisation de ces donnĂ©es est obligatoire. Les donnĂ©es fournies sont stockĂ©es dans une table qui ne correspond pas Ă  votre modĂšle de donnĂ©es, il va donc ĂȘtre nĂ©cessaire de transformer les donnĂ©es fournies pour pouvoir les insĂ©rer dans vos tables. Ce processus, que l’on appelle intĂ©gration de donnĂ©es sera rĂ©alisĂ© Ă  travers des requĂȘtes SQL que vous exĂ©cuterez dans PHPMyAdmin. L’étape d’intĂ©gration peut se dĂ©composer en 3 parties :

  1. RĂ©flĂ©chir aux correspondances entre les donnĂ©es existantes et votre schĂ©ma ( e.g., Ă  quel attribut de votre schĂ©ma correspond tel attribut fourni). VĂ©rifier si les types de donnĂ©es sont cohĂ©rents entre attributs correspondants et quelles sont les transformations nĂ©cessaires au niveau des valeurs. Il est important de comprendre que le jeu de donnĂ©es fourni n’est pas bien modĂ©lisĂ©. En consĂ©quence si vous modĂ©lisez votre schĂ©ma de base de donnĂ©es avec l’objectif d’intĂ©grer facilement les donnĂ©es fournies, votre schĂ©ma ne respectera plus les spĂ©cifications demandĂ©es.
  2. Écrire les d’insertion du type INSERT INTO maTable SELECT ... FROM donnees_fournies.instancesX ; permettant de peupler votre base. Il est important de noter que la base donnees_fournies sera Ă  terme (avant la soutenance) supprimĂ©e. Donc les donnĂ©es doivent ĂȘtre absolument rĂ©cupĂ©rĂ©es dans votre propre base de donnĂ©es.

Remarque : il n’est pas demandĂ© de dĂ©velopper une fonctionnalitĂ© permettant de gĂ©rer l’intĂ©gration depuis votre interface Web. Pour bien comprendre le principe par l’exemple, vous pouvez vous rĂ©fĂ©rer Ă  l’annexe A.

4 Les fonctionnalités

Dans ce projet, vous allez avoir à développer des interfaces associées aux fonctionnalités décrites dans cette section. Il est important dans un premier temps de définir (ou récupérer dans les TP4-5) ces primitives de votre modÚle que vous pourrez alors utiliser pour le développement des fonctionnalités.

Vous disposez avec le sujet des ressources graphiques associĂ©es aux cartes dans le rĂ©pertoire RessourcesGra- phiquesDĂ©Biclou. Les 75 cartes proposĂ©es sont dĂ©finies dans la base _donnees_fournies dans la table ’ressources’.

4.1 Page d’accueil et statistiques

En parallĂšle du processus d’intĂ©gration, vous pouvez commencer Ă  mettre en place votre site WEB Ă  partir du code fourni lors des TP prĂ©cĂ©dent. Il est important de conserver l’approche MVC que l’on vous a apprise.

À propos des statistiques

La premiĂšre fonctionnalitĂ© de votre application est de mettre en place la page d’accueil qui offre un descriptif de l’application et un ensemble d’informations et de statistiques. Parmi ces informations et ces statistiques, il est demandĂ© d’avoir au moins :

— "un n-uplet contenant le nombre de joueurs, le nombre d’équipes, le nombre de classements, le nombre de
tournois et la moyenne des participants par tournoi".
— "les phases de tournoi (nom et annĂ©e de tournoi, niveau de phase) jouĂ©es et pour lesquelles s’est qualifiĂ©
l’utilisateur courant. Le rĂ©sultat sera triĂ© sur les annĂ©es selon l’ordre antĂ©chronologique puis sur les niveaux
de phase selon l’ordre lexicographique inverse".
— "le nombre d’équipes classĂ©es premiĂšres des classements et dont aucun des membres n’est premier dans
un classement individuel".
— "Pour les 3 derniĂšres annĂ©es, donner le nombre moyen de participants aux tournois".
— "Donner le nom et le prĂ©nom des joueurs classĂ©s de maniĂšre individuelle dans le top 5 d’au moins 2
classements de portée nationale".
— "Pour chaque taille de plateau, donner le nombre de parties jouĂ©es avec un plateau de cette taille".
— "Le top 5 des joueurs (pseudo) qui ont jouĂ© le plus de parties".

Ă  propos du design du site

Chaque page de votre site dispose d’une structure qui vous est imposĂ©e. En effet, pour chaque page vous devez avoir les cinq zones suivantes :

— Un bloc "entĂȘte" (

), qui contient le nom du site et un logo cliquable pour toujours revenir Ă  la page d’accueil, — Un bloc "menu" ( ) dans lequel chaque Ă©lĂ©ment permet d’accĂ©der Ă  une page spĂ©cifique, — Un bloc "contenu de la page" ; contenu qui s’adaptera en fonction de la fonctionnalitĂ© Ă  laquelle l’utilisateur souhaite accĂ©der, — Un bloc "pied de page" ( ), qui contiendra au moins un lien vers le site de l’UCBL, le nom des auteurs du site, l’annĂ©e de rĂ©alisation, un lien vers une page statique contenant le plan du site... Concernant la mise en forme du site, elle se fera avec des styles CSS. Le projet sera Ă©valuĂ© avec le navigateur Mozilla Firefox, donc vĂ©rifiez le rendu de votre site avec ce navigateur!

Concernant le rendu, il est possible d’embellir votre application en ajoutant des composants ou widgets javascript. Il est cependant important de garder en mĂ©moire que le projet est un projet PHP, donc la proportion de javascript doit rester raisonnable.

4.2 Fonctionnalité 1 : liste des parties terminées et en cours

Cette fonctionnalitĂ©, que l’on nommera "afficherPartie", consiste Ă  lister les parties se trouvant en base.

Pour cette fonctionnalitĂ©, on affichera les informations sur les parties sous la forme d’un lien hypertexte faisant apparaĂźtre les informations suivantes (quand celles-ci existent) :

— Identifiant de partie,
— Date et horaire de la partie,
— Taille du plateau,
— Triplet (nbB, nbJ, nbR) reprĂ©sentant respectivement le nombre de cartes vertes, oranges et noires dans la
partie,
— Liste des pseudos des joueurs de la partie,
— Podium (1 e , 2 e et 3 e places) des joueurs avec respectivement leur nombre de points gagnĂ©s dans la partie.
Ainsi, vous devez :
  1. Créer le contrÎleur et la vue associés à cette fonctionnalité.
  2. Afficher la liste des parties dans l’état ’À venir’.
  3. Afficher la liste des parties dans l’état ’En cours’ (potentiellement interrompue).
  4. Afficher un formulaire permettant de sĂ©lectionner un mode d’affichage des parties terminĂ©es. On considĂ©- rera une liste dĂ©roulante avec au moins les modes d’affichage suivants : — "Toutes les parties", — "Les 50 parties les plus rĂ©centes" avec un tri de la plus rĂ©cente Ă  la plus ancienne, — "Les 50 parties plus rapides par taille de plateau" avec un tri par nombre de cartes dĂ©croissant puis, pour les parties avec un plateau de mĂȘme taille, de la plus rapide Ă  la plus lente.

4.3 Fonctionnalité 2 : Mise en place de la partie

Cette fonctionnalitĂ©, que l’on nommera "creerPartie", consiste Ă  crĂ©er en base une partie paramĂ©trĂ©e par l’utilisateur et de lui associer des joueurs.

Pour cela, vous devez :
  1. créer le contrÎleur et la vue associés à cette fonctionnalité.
  2. afficher, quand aucun formulaire n’est soumis, un formulaire permettant de saisir les paramĂštres de la partie qui contient au moins : — le nombre de cartes constituant le plateau (en plus des cartes de dĂ©part et d’arrivĂ©e) — le nombre de cartes vertes Ă  sĂ©lectionner — le nombre de cartes oranges Ă  sĂ©lectionner — le nombre de cartes noires Ă  sĂ©lectionner — un bouton de soumission du formulaire qui dĂ©clenche la crĂ©ation de la partie en base.
  3. crĂ©er la partie en base dans un Ă©tat ’A venir’. Une fois la partie créée, il faut crĂ©er le plateau avec la taille saisie dans le formulaire et associer le plateau courant Ă  la partie courante. Une fois le plateau créé, il est nĂ©cessaire de choisir alĂ©atoirement autant de cartes vertes, oranges et noires que demandĂ©es dans le formulaire pour les associer au plateau courant. Il sera Ă©videmment nĂ©cessaire de s’assurer que le nombre de cartes sĂ©lectionnĂ©es est cohĂ©rent avec la taille du plateau.
  4. afficher, quand le formulaire de saisie des paramĂštres de la partie est soumis, un formulaire permettant de sĂ©lectionner des joueurs, qui contient au moins : — une liste dĂ©roulante contenant la liste de tous les noms, prĂ©nom et pseudo des joueurs en base. — un bouton de soumission d’ajout d’une personne, qui rechargera la page en affectant la personne sĂ©lectionnĂ©e Ă  la partie courante. Une couleur sera alors associĂ©e alĂ©atoirement Ă  la personne, ce qui correspondra Ă  la couleur de son pion dans le jeu. — un bouton de soumission de retrait d’une personne, qui rechargera la page en retirant la personne sĂ©lectionnĂ©e de la partie courante (pour gĂ©rer les Ă©ventuelle erreur d’affectation). — une liste dĂ©roulante contenant la liste des stratĂ©gies d’ordre de passage ’Honneur au plus jeune", "Honneur au moins expĂ©rimentĂ©" ou "AlĂ©atoire". — un bouton de soumission de validation de la partie. En fonction de la stratĂ©gie d’ordre de passage des joueurs, il est nĂ©cessaire de calculer l’ordre de passage des joueurs et de mettre Ă  jour l’information en base. Remarque d’amĂ©lioration : Le protocole proposĂ© est une proposition, libre Ă  vous de proposer un autre protocole, qui peut se baser sur le principe d’invitation de certains joueurs, d’inscription Ă  la partie par publication sur une page des parties en attente de joueurs...

4.4 FonctionnalitĂ© 3 : DĂ©roulĂ© d’une partie

Cette fonctionnalitĂ©, que l’on nommera "jouerPartie", correspond au dĂ©roulement d’une partie.
Pour cela, vous devez :
  1. créer le contrÎleur et la vue associés à cette fonctionnalité.
  2. afficher, quand aucun formulaire n’est soumis, les diffĂ©rents Ă©lĂ©ments permettant le dĂ©roulĂ© d’une partie : — le plateau contenant les cartes sĂ©lectionnĂ©es, — un numĂ©ro au-dessus de chaque carte (hormis carte de dĂ©part et d’arrivĂ©e) qui servira Ă  associer les dĂ©s lancĂ©s Ă  la carte lors du dĂ©roulement de la partie, — les pions de chaque joueur placĂ©s sur ou Ă  hauteur de la case de dĂ©part, — la liste des joueurs (pseudo) triĂ©e selon l’ordre de passage dĂ©terminĂ© prĂ©cĂ©demment.Le nom des joueur doivent apparaĂźtre de la couleur correspondant Ă  leur pion. — un bouton de soumission pour lancer la partie. Au lancement de la partie, la base est mise Ă  jour pour sauvegarder la date et l’horaire de dĂ©but de partie. L’état de la partie passe Ă  ’En cours’.
  3. crĂ©er un tour pour la partie. À la crĂ©ation du tour, le pseudo du joueur courant est indiquĂ© et sauvegardĂ© en base. Le formulaire prĂ©cĂ©dent s’affichera hormis le bouton de soumission pour lancer la partie qui est remplacĂ© par les onglets permettant au joueur courant de choisir une main. On a donc : — un onglet de saisie du nombre de dĂ©s bleus, — un onglet de saisie du nombre de dĂ©s jaunes, — un onglet de saisie du nombre de dĂ©s rouges, — un bouton de soumission pour enregistrer la main en base et permettre ensuite au joueur courant de lancer 3 fois les dĂ©s.
  4. crĂ©er la main associĂ©e au joueur courant pour le tour courant dans la base. Une fois la main créée, afficher : — les dĂ©s correspondants Ă  la main, — le numĂ©ro du tour, — le nombre de lancers restant, — un bouton "lancer les dĂ©s" pour que le joueur courant puisse lancer les dĂ©s.
  5. lancer les dĂ©s consiste Ă  choisir alĂ©atoirement des valeurs entre 1 et 6 pour chaque couleur de dĂ©s de la main. Ce choix est mis en base. Pour permettre ensuite Ă  l’utilisateur d’associer un dĂ© Ă  une carte pour valider sa contrainte, le joueur courant verra afficher sur la page : — les dĂ©s correspondant au lancer, — Ă  cĂŽtĂ© de chaque dĂ©, on affichera une liste dĂ©roulante cor- respondant au numĂ©ro des cartes du plateau qu’il reste Ă  parcourir et l’option ’Affecter une carte’ comme reprĂ©sentĂ© sur la Figure 4. — le nombre de lancers restant, — le nombre de tentatives de validation de la carte suivante ( i.e., depuis combien de tours le joueur essaie de valider la carte suivante) , — un bouton "lancer les dĂ©s" pour que le joueur courant puisse lancer les dĂ©s.
Figure 4 : Illustration de
l’affectation de dĂ©s Ă  des cartes
  1. valider l’affectation d’un dĂ© Ă  une carte. Il est nĂ©cessaire de s’assurer que la ou les affectations Ă  une carte sont possibles. Si l’affectation est valide, elle est mise en base. Les dĂ©s affectĂ©s ne peuvent plus ĂȘtre utilisĂ©s au lancer suivant.

  2. avancer le pion du joueur au bout des 3 lancers. Une fois les 3 lancers effectués, identifier la ou les cartes dont toutes les contraintes sont validées. Affecter la nouvelle position du joueur et la mettre en base. Calculer le nombre de points obtenus par le joueur.

  3. passer au joueur suivant en mettant Ă  jour la base.

  4. changer de tour, une fois que tous les joueurs ont effectué leurs 3 lancers,

  5. dĂ©tecter si un joueur est arrivĂ©. Dans le cas oĂč le joueur valide la derniĂšre carte (avant celle de l’arrivĂ©e), le rang final du joueur est mĂ©morisĂ© en base.

  6. dĂ©tecter si tous les joueurs sont arrivĂ©s. Dans le cas oĂč le dernier joueur est arrivĂ©, on mĂ©morise la durĂ©e de la partie et on calcule les scores des joueurs selon le principe dĂ©crit dans le cahier des charges. L’état de la partie passe Ă  ’TerminĂ©e’. On affichera alors : — l’ordre d’arrivĂ©e des joueurs — le nombre de points gagnĂ©s pour chaque joueur

Remarque importante : Il est rappelĂ© ici qu’à tout moment le navigateur peu ĂȘtre fermĂ© et la partie interrompue. Il est donc important de bien mettre en base toute information permettant de reprendre la partie lĂ  oĂč elle a Ă©tĂ© interrompue.

4.5 Fonctionnalité 4 : fonctionnalités supplémentaires

En fonction de l’avancement de votre projet, libre Ă  vous de proposer des amĂ©lioration dans le dĂ©roulĂ© de la partie, ou des fonctionnalitĂ©s supplĂ©mentaires telles que la gestion des tournois, des classements, la proposition de nouvelles rĂšgles de jeux...

5 Déroulé du projet et jalons

Lors de la réalisation de votre projet, on vous demande de respecter le calendrier de jalons suivant.

5.1 Les jalons

JALON 1

Lors de la sĂ©ance de TP du 29/03/2023, vous prĂ©senterez votre schĂ©ma entitĂ© association en l’état. Une apprĂ©ciation vous sera alors attribuĂ©e.

JALON 2

Lors de la sĂ©ance de TP du 05/04/2023, vous prĂ©senterez votre base de donnĂ©es peuplĂ©es et les requĂȘtes statistiques. Une apprĂ©ciation vous sera alors attribuĂ©e.

JALON 3

Lors de la sĂ©ance de TP 13/04/2023, vous prĂ©senterez l’état d’avancement du dĂ©roulĂ© d’une partie. Une apprĂ©ciation vous sera alors attribuĂ©e.

5.2 Rendu du projet

Ce projet est Ă  rendre avec les consignes de rendu suivantes :
— L’archive rendue (un seul par binîme) aura une extension .zip et il doit inclure votre/vos nom(s) à la fois
dans le nom de fichier et en entĂȘte de chacun de vos fichiers
— Ce fichier zip contiendra au moins 4 fichiers :
— l’archive contenant les pages de votre site (code commentĂ© et indentĂ©).
— un fichier .sql qui contiendra le script SQL "exĂ©cutable" de crĂ©ation de votre base de donnĂ©es,
— un fichier .sql qui contiendra le script SQL "exĂ©cutable" d’importation des donnĂ©es dans votre base,
— un fichier contenant votre MCD (schĂ©ma E/A).
Ce fichier zip est à rendre le 18 avril à 23h59 dans la zone de dépÎt TOMUSS dédiée (Rendu_projet).

5.3 Calendrier récapitulatif

Date Type Description
29/03/23 Jalon 1 Évaluation du schĂ©ma E/A en sĂ©ance
05/04/23 Jalon 2 Évaluation Ă©tat BD et statistiques en sĂ©ance
13/04/23 Jalon 3 Évaluation Ă©tat d’avancement dĂ©roulĂ© d’une partie
18/04/23 Jalon 4 DépÎt sur TOMUSS de votre rendu de projet
19/04/23 Soutenance dĂ©monstration de l’application

6 ANNEXE A : Ă  propos de l’intĂ©gration de donnĂ©es

On considĂšre d’une part, la relation initiale R dĂ©finie comme suit :
R (idA, A1, A2, B1, B2, C1, C2, D)
En sachant que D est une valeur numérique représentant une capacité mémoire en Mo.
D’autre part, on dispose du schĂ©ma relationnel suivant :
EA (idA, A1, A2), #idB)
EB (idB, B1, B2)
EC (idC, C1, C2)
ED (#idA, #idC, D)
En sachant que D est exprimé en Ko.
Ce modÚle relationnel répond au schéma Entité/Association suivant :
Comment intégrer les données de R dans les relation EA, EB, EC, ED?
  1. CrĂ©ation de la table EB : comme EB ne dispose d’aucune contrainte de clĂ© Ă©trangĂšre, nous allons commencer par crĂ©er la table correspondante. Cependant, il n’y a pas de valeur deidBdans R. Nous allons donc dĂ©finiridB de typeinteger avec unAUTO_INCREMENT. On peut donc crĂ©er la EB de la maniĂšre suivante : CREATE TABLE EB ( idB integer AUTO_INCREMENT PRIMARY KEY, B1 varchar(100), B2 varchar(100) )
  2. CrĂ©ation de la table EC : on utilise le mĂȘme principe que prĂ©cĂ©demment. On peut donc crĂ©er la EC de la maniĂšre suivante : CREATE TABLE EC ( idC integer AUTO_INCREMENT PRIMARY KEY, C1 varchar(100), C2 varchar(100) )
  3. CrĂ©ation de la table EA : comme l’identifiantidAde ’EA’ se trouve dans R, il est possible de rĂ©cupĂ©rer directement sa valeur dans R. On peut donc crĂ©er la EA de la maniĂšre suivante : CREATE TABLE EA ( idA integer PRIMARY KEY, A1 varchar(100), A2 varchar(100), idB integer ) ; ALTER TABLE EA ADD CONSTRAINT fk_EA_EB FOREING KEY (idB) REFERENCES EB (idB) ;
  4. CrĂ©ation de la table ED : La table ED peut ĂȘtre dĂ©finie de la maniĂšre suivante :

CREATE TABLE ED (

idA integer,
idB integer,
D integer ) ;
ALTER TABLE ED ADD CONSTRAINT fk_ED_EA FOREING KEY (idA) REFERENCES EA (idA) ;
ALTER TABLE ED ADD CONSTRAINT fk_ED_EB FOREING KEY (idB) REFERENCES EB (idB) ;
  1. Peuplement de la table EB : Pour cela, il est possible d’utiliser la requĂȘte suivante :
INSERT INTO EB (B1, B2) SELECT DISTINCT B1, B2 FROM R ;
Les valeurs deidBsont alors définies.
  1. Peuplement de la table EC : Pour cela, il est possible d’utiliser la requĂȘte suivante :
INSERT INTO EB (B1, B2) SELECT DISTINCT B1, B2 FROM R ;
Les valeurs deidBsont alors définies.
  1. Peuplement de la table EA : Pour cela, il est possible d’utiliser la requĂȘte suivante :
INSERT INTO EA (idA, A1, A2, idB)
SELECT DISTINCT R.idA, R.A1, R.A2, EB.idB FROM R JOIN EB ON R.B1 = EB.B1 AND
R.B2 = EB.B2 ;
La valeur deidBen clĂ© Ă©trangĂšre est retrouvĂ©e grĂące Ă  la jointure sur B1 et B2, que l’on sait unique dans
ce cas particulier (du fait de la maniÚre dont on a peuplé EB). Dans le cas général, il sera important de
s’assurer que les attributs de jointures garantissent d’identifier de maniùre unique le n-uplet.
  1. Peuplement de la table ED : Pour cela, il est possible d’utiliser la requĂȘte suivante en transformant les donnĂ©es quand cela est nĂ©cessaire :
INSERT INTO ED (idA, idC, D)
SELECT DISTINCT R.idA, EC.idC, (1024 * R.D) as D FROM R JOIN EC ON R.C1 = EC.C1 AND
R.C2 = EC.C
Description
Look at deez game 🚮
Readme 34 MiB
Languages
HTML 87.3%
PHP 11.6%
CSS 0.8%
Hack 0.3%