Bonjour, nous vous présentons dans cet article notre modèle de données.
Il s’agit ici de la version simplifiée sans les types.
Le Modèle de Données
Partie blanche
Utilisateur : table classique pour stocker un utilisateur de notre application.
Avatar : Nous avons décidé dans un premier temps de créer nos avatar avec une couleur et un symbole. Exemple : ff80aa et M qui devient ensuite un avatar avec un grand M sur fond bleu.
Nous avons commencé à coder ce que ça pourrait rendre et nous avons ça : http://codepen.io/juliensoret/pen/wovMPQ
Cela permet d’avoir des avatars personnalisables avec beaucoup de combinaisons très facilement dans notre application. Nous pensons d’ailleurs générer ces valeurs aléatoirement à la création du profil.
Événement : La table Événement est le cœur de notre application : C’est notre « carte » de jeu qui représente un événement dans l’Histoire. Il peut être un point donné (ex: Mort de Jeanne D’Arc) auquel cas l’entrée ne possède pas de dateFin. Il peut être un événement placé sur une durée (ex: Seconde Guerre Mondiale). Et enfin, il peut être un élément dépendant d’un personnage (ex: Mort de Hitler, Hitler devient chancelier, etc… tous liés à la table Personnage). Le champs Importance est là pour définir sur une échelle de 1 à 3, l’importance de l’événement dans l’Histoire pour calculer la difficulté d’une question (ex: Révolution Française à 3, Premier chimpanzé dans l’Espace à 1).
Score : Lorsqu’une partie est jouée, nous stockons à la fin le score obtenu par le joueur. Nous stockons donc les infos nécessaires à le réutiliser ce score dans les statistiques du joueur. Voir la table Partie pour l’attribut du même nom.
Thème : Un thème est un nom regroupant plusieurs événements. Un exemple simple est « Deuxième Guerre Mondiale » qui regroupe tous les événements liés à cette guerre. Nous utiliserons aussi cette table pour un thème « Diplôme National du Brevet » pour pouvoir proposer des parties spéciales au collégiens.
Personnage : Un personnage est lié à des événements comme expliqué ci-dessus.
Partie bleue
Nous abordons désormais les tables de couleur bleue sur l’image. Ces tables seront créées après la première version de l’application. Elles sont liées à des fonctionnalités de l’application.
Groupe : Il sera possible de créer un groupe d’utilisateurs. Un groupe ne contient qu’un nom et un avatar et on peut y lier des utilisateurs. Un utilisateur peut être dans N groupes et un groupe a un nombre variable de membres.
Partie : Un administrateur de groupe peut décider de générer des parties pour le groupe. C’est à dire qu’un set de questions est enregistré dans le but d’être proposé à l’identique à tous ses membres dans le but de les classer selon leurs résultats. Nous n’avons pas jugé nécessaire d’enregistrer une partie dans un cas différent.
Question : Une partie est composée de questions. Une question est, elle, différente selon de quel mode de jeu elle dépend :
- Si la partie est du mode de jeu Contemporains : Elle est alors composée de 5 questions contenant chacune un repère représentant la carte X dans « X est contemporain de …. » et 4 choix de réponses.
- Si la partie est du mode de jeu Ordre Chronologique : Elle est alors composée d’une seule question contenant un repère représentant la carte placée au début de la partie ainsi que 4 réponses à placer tour à tour pour reformer la chronologie.
- Si la partie est du mode de jeu Frise Chronologique : Elle est alors composé de 5 questions ne contenant aucune réponse! La réponse étant retrouvable dans la carte Événement elle-même.
Conclusion
Les choix « discutables » que nous avons fait sont donc d’utiliser la même table Question pour les 3 types, ce qui rend un peu plus complexe à comprendre notre façon de la gérer. Ainsi que le fait que nous stockons les réponses dans la table Question au lieu de créer une table Réponse.
Ces deux choix ont été fait dans le but d’avoir un modèle de données plus simple.
Dans le prochain article, nous parlerons de plus en plus technique car nous démarrons les développements !