CAW1 2018 Projet de Matthias ALLSPACH et Magali BAUMANN

De Ensiwiki
Aller à : navigation, rechercher

NonPlayerCharacter est un site web de chat axé RPG. Les utilisateurs peuvent se connecter à différentes salles de discussion et créer une fiche personnage lié à cette salle.

Project schedule.png
Titre du projet Site de chat en ligne axé jeu de rôle
Cadre Projets de web
Page principale Site de chat en ligne axé jeu de rôle

Équipe Matthias Allspach, Magali Baumann
Encadrants Sebastien Viardot


Présentation du projet

Description générale

Ce projet s'inscrit dans le cadre des cours de construction d'application WEB proposés par l'ENSIMAG aux alternants de deuxième année. L'objectif est de développer une application web en respectant un cahier des charges imposé.

NonPlayerCharacter

NonPlayerCharacter est un site web de chat axé RPG. Les utilisateurs peuvent créer ou s'inscrire à des salles de discussion. Ils peuvent ensuite s'y connecter et créer une fiche personnage lié à cette salle. Enfin, ils peuvent discuter dans cette salle, consulter la fiche des autres joueurs, prendre des notes, et même lancer des dés !

Screencast

Etant donné que nous ne pouvons pas importer un fichier de plus de 2 Mo sur l'Ensiwiki, le screencast est enregistré sur une plateforme externe : Lien du screencast

Cahier des charges

Le projet doit comporter les éléments suivants :

  • Utilisation de l'un des frameworks.
  • Gestion des rôles avec des utilisateurs différents ayant des droits et des rôles différenciés (2 rôles au minimum)
  • Site adapté à plusieurs terminaux dont une version mobile (par exemple en utilisant Bootstrap)
  • Mise en place de jeux de tests unitaires : pour tester la partie modèle et contrôleur.
  • Mise en place de jeux de tests fonctionnels avec des technologies de type selenium.
  • Utilisation webservice coté serveur (le client demande un service au serveur mis en place, qui à son tour fait un appel à un webservice tiers)(cf. https://code.google.com/intl/fr/apis/language/translate/v2/getting_started.html).
  • Mise en place d'une API pour l'application développée
  • Optionnel : Partie cliente utlisant angular ou vue.js (attention pas de service node... juste la partie cliente)

Nous avons des éléments dans tous les points du cahier des charges. Nous n'avons pas réalisé la partie optionnelle.

Choix techniques

Framework

Nous avons utilisé Django 2.0.5, qui permet de développer le back d'une application web en python.

Framework CSS

Nous avons utilisé Bootstrap dans sa dernière version (4.0.0), avec Font Awesome pour les icônes.

Base de données

Nous avons utilisé le système de base de données SQlite pour stocker les données relatives au site. C'est le système proposé de base par Django.

Gestionnaire de chat

Nous avons utilisé Redis pour assurer le lien dynamique entre les utilisateurs dans les salles de discussion. Redis nous a permis d'isoler les salles de discussions les unes par rapport aux autres.

Mise en œuvre

Adaptation aux terminaux

L'affichage s'adapte selon les terminaux. L'idéal est d'être sur ordinateur. Néanmoins, l'utilisation sur petit écran (téléphone ou tablette) reste fluide. Le très petit écran est à éviter.

Web service

Nous mettons en œuvre deux webservices pour assurer les fonctionnalités du site :

  • Redis gère la partie web socket, qui s'occupe de mettre en relation les différents utilisateurs.
  • https:\\rolz.org/api/? nous sert à simuler le lancement de dé.
  • Pour réinitialiser le mot de passe d'un utilisateur, un mail lui est envoyé. Pour que cette fonctionnalité soit effective, il faut spécifier un serveur SMTP. Pour le moment, les mails sont écris dans le dossier sent_emails à la racine du projet.

API

Nous avons mis en place une API qui permet de récupérer les différentes données du site sous forme de JSON (information utilisateur, ensemble des salle de chat, fiche de jeu de chaque personne sur chaque chat, messages envoyés dans chaque chat). Nous n'exploitons actuellement pas cette API. Ces données pourraient servir à un service de modération par exemple.

Voici les URL qui permettent d'accéder aux différentes fonctionnalités de l'API :

  • /npc/api/users : accès aux informations de tous les utilisateurs.
  • /npc/api/users/<int:userId> : accès aux informations d'un utilisateur (spécifié par son id)
  • /npc/api/playgrounds : accès aux informations de toutes les salles de discussion
  • /npc/api/playgrounds/<int:idPg> : accès aux informations d'une salle de discussion (spécifiée par son id)
  • /npc/api/playgrounds/<int:idPg>/players : accès aux fiches de jeu des personnes inscrites à une salle de discussion (spécifiée par son id)
  • /npc/api/playgrounds/<int:idPg>/players/<int:login> : accès à la fiche de jeu d'une personne (spécifiée par son id) pour une salle de discussion (spécifiée par son id)
  • /npc/api/playgrounds/<int:idPg>/chats : accès à l'ensemble des messages envoyés sur une salle de discussion (spécifiée par son id)

Modèle de données

Ci-dessous, le diagramme de schéma de notre base de données :

DiagramDB.png

Rôles et utilisation

Gestion des rôles

L'accès à notre site se fait par défaut via l'interface de connexion utilisateur. La connexion est nécessaire pour accéder au reste du site. Au-delà, nous avons deux niveaux de privilège imbriqués : les utilisateurs et les administrateurs. Ces deux niveaux sont gérés par Django.

  • Les utilisateurs ont accès à leur propre page d'accueil web une fois connectés. Ce niveau permet de créer des salles de discussion. Il permet aussi de s'y inscrire si l'utilisateur est muni de l'url adaptée. Une fois inscrits (la création d'une salle de discussion entraîne automatiquement son inscription à celle-ci), les utilisateurs peuvent s'y connecter.
  • Les administrateurs, en plus des fonctionnalités des utilisateurs, ont accès à l'interface d'administration basique de Django, qui permet la lecture et l'écriture brute de la base de données. Il n'est pas possible de créer de nouvel administrateur via l'accès web. Les liens vers ces interfaces ne sont pas référencés dans la partie utilisateur. Il faut les connaître (ou demander à internet, on ne les a pas changés), pour y accéder. Le couple identifiant-mot de passe admin/admin ne fonctionne pas.

Les salles de discussion sont elles aussi munies d'un système de trois niveaux de privilège imbriqués : le maître du jeu (GM, Game Master), le joueur (Player) et l'observateur (Guest). Ces trois niveaux sont gérés par l'application.

  • L'observateur a un accès restreint à la salle de discussion. Il peut entretenir sa fiche de jeu, prendre des notes, voir la fiche de jeu des autres joueurs et enfin lire les messages du Chat. En revanche, il ne peut pas envoyer de messages dans celui-ci.
  • Le joueur, en plus des fonctionnalités de l'observateur, peut envoyer des messages dans le chat.
  • Enfin, le maître du jeu est celui qui a créé la salle. Il a accès, en plus de à des fonctionnalités de l'observateur et du joueur, de fonctionnalités spécifiques permettant de gérer le jeu et la salle de discussion. Il peut ainsi accéder à l'url d'inscription à la salle, lancer ou stopper le jeu et utiliser le webservice de lancer de dés.

Cas d'utilisation

Cas d'utilisation généraux

  • Les utilisateurs non connectés
    • Inscription,
    • Connexion,
    • Réinitialisation de mot de passe.
  • Les utilisateurs connectés
    • Visualisation de ses salles de discussion sur l'accueil utilisateur,
    • Accès à ses salles de discussion,
    • Inscription à une salle de discussion existante,
    • Création d'une salle de discussion,
    • Accès aux informations du site,
    • Déconnexion.
  • Les utilisateurs connectés s'inscrivant à une salle
    • Choix d'être joueur ou observateur (dans la limite des places de joueur disponibles).
  • Les utilisateurs connectés créant une salle
    • Choix du nom de la salle,
    • Choix de l'image de la salle (visible dans l'accueil utilisateur),
    • Choix du nombre de joueurs pour la salle.
  • Les administrateurs
    • Fonctionnalités utilisateurs et
    • Accès à l'interface d'administration,
    • Modification de la base de données.

Cas d'utilisation dans les salles de discussion

  • Observateur
    • Entretien de sa fiche de jeu,
    • Prise de notes,
    • Visualisation de la fiche de jeu des joueurs inscrits à la salle,
    • Retour sur l'accueil utilisateur
    • Déconnexion du site.
  • Joueur
    • Fonctionnalités de l'observateur et
    • Utilisation du chat.
  • Maître du jeu
    • Fonctionnalités joueur et
    • Lancer ou arrêter la partie,
    • Paramétrer et lancer les dés,
    • Accès à l'URL d'inscription et copie de cette URL.

Scénario d'usage

Scenarii d'utilisation.jpg

Mise en place et tests

Installation

Voici les instructions nécessaires à la mise en place du projet NonPlayerCharacter sur votre machine. Ces instructions sont également disponibles dans le fichier README.md.

Tout d'abord, pour que le site soit fonctionnel, il est nécessaire d'être connecté à internet.

Python

Vous devez installer python en version 3.6.X. Nous avons développé le projet en python 3.6.3

Installation des librairies python

Vous trouverez à la racine du projet un fichier requirements.txt. Pour installer les librairies nécessaires au fonctionnement du projet, il vous suffit de taper la ligne de commande suivante :

   pip install -r requirements.txt

Redis

Il est nécessaire d'avoir un serveur Redis pour le fonctionnement du chat (web socket). Ci-dessous, des liens de tutoriel pour installer Redis sur Windows, Linus et Mac OS. Nous n'avons pas pu tester le tutoriel sur Mac.

Pour Windows :(testé) Installer chocolatey : https://chocolatey.org/install Installer redis depuis chocolatey : https://chocolatey.org/packages/redis-64

Pour Linux (testé) : https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-redis-on-ubuntu-16-04

Pour Mac (pas testé) : https://medium.com/@petehouston/install-and-config-redis-on-mac-os-x-via-homebrew-eb8df9a4f298

La base de données

Le code source du projet est fournis sans base de données. Le fichier initBD.py va remplir la base de données avec quelques données de tests qui vous permettront de tester les différentes fonctionnalités du site. Voici les différentes commandes à exécuter à la racine du projet :

   py manage.py migrate
   py manage.py makemigrations
   py manage.py shell < initDB.py

Une fois la base de donnée initialisée à l'aide de ce fichier, voici les différents comptes qui seront créés :

  • Identifiant : Guillaume / Password : password!
  • Identifiant : Sarah / Password : password!
  • Identifiant : John / Password : password!

Si vous souhaitez nettoyer la base de données, il suffit de taper la commande suivante :

   py manage.py flush

Lancement du projet

1. Lancer Redis (cf tuto Redis)

2. Lancer la commande suivante : py manage.py runserver

Dans le fichier Settings, nous avons laisser l'option DEBUG=TRUE. Le projet est donc toujours en mode debug. Pour être en mode production, il faut avoir un serveur (type apache) qui sera capable d'envoyer les fichiers statiques au client. En mode debug, les fichiers sont simplement récupérer au chemin d'accès spécifié.

Tests

Les tests que nous avons écrits sont dans le fichier npc/tests.py. Pour lancer les tests, il faut modifier le fichier tests.py (voir Tests fonctionnels) et exécuter la commande py manage.py test.

Tests Unitaires

Tests fonctionnels

Les tests fonctionnels ont été écris à l'aide de Selenium qui utilise le driver gecko pour interagir avec Firefox. Dans le fichier tests.py, à l'initialisation de Selenium, il faut déclarer le chemin pour accéder à gecko. Les tests seront alors exécutés sur Firefox.