Rapport de conception: GéoCherheur

Membres : Yousrah SOULE, Aaron RANDRETH, Ilo RABIARIVELO, Adrien DEU

Groupe : 203

Notre Concept

Geochercheur est un jeu inspiré de GeoGuessr. Dans le concept de base, le joueur est placé aléatoirement dans un endroit spécifique dans le monde et son objectif est de deviner sa position sur une carte. Nous avons un peu repris l’idée. Mais à la place de le placer aléatoirement, le joueur pourra choisir un certain thème de parcours. Dans ce parcours il y aura plusieurs questions. Tout à la manière de GeoGuessr, le joueur de GeoChercheur possèdera un visuel sur son entourage et pourra se déplacer. Mais le but final sera quand même de placer le marqueur le plus près possible de la bonne position sur la carte. Ainsi un certain nombre de point sera calculé selon cette distance.

Présentation du Site

” Page d’accueil” : Cette page est la première que le joueur rencontrera lorsqu’il ira sur le site. Son objectif est de donner envie à la personne de jouer au jeu. Dessus on peut y apercevoir un carrousel avec des commentaires de joueur et un message de bienvenue.

“Page de connexion” : Cette page est composée d’un formulaire permettant à un joueur déjà inscrit de se connecter et ainsi de continuer de jouer dans sa session.

“Page d’inscription” : Cette page est composée d’un formulaire mais cette fois-ci pour s’inscrire au site. Il y a deux paramètres à rentrer le pseudonyme du joueur ainsi que son mot de passe qui doit correspondre à certains critères. Il a aussi la possibilité de choisir une photo de profil de son choix. Il doit aussi cocher une case pour accepter notre politique de confidentialité.

“Page des parcours” : Cette page est la première page que voit le joueur lorsqu’il vient de se connecter. Elle lui montre les différents parcours de jeu disponible et possède une barre de navigation pour pouvoir se déplacer entre les différentes pages créer et le leaderboard.

“Page de jeu (sans validation)” : Cette page est un exemple de page de jeu lorsqu’on démarre un parcours. Le joueur a une vue d’ensemble sur son environnement et possède une minicarte sur la droite pour pouvoir poser le marqueur et le valider.

“Page de jeu (avec validation)” : Cette page est un exemple de page de jeu lorsqu’on vient de valider la position du marqueur. Lorsqu’on valide la position, le jeu laisse 5 secondes au joueur pour voir la correction et passe à la deuxième question.

“Page de fin de Parcours” : Cette page est un exemple de fin de parcours. Il apparait lorsque le joueur a fini toutes les questions d’un parcours. Le score est affiché avec un message de fin.

“Page de création” : Cette page est la page de création de parcours pour les clients. Elle permet aux clients de choisir les questions et les paramètres du parcours qu’ils créent.

“Page de Leaderboard” : Cette page est un leaderboard qui répertorie tous les joueurs de GeoChercheur et leur score total. Un menu combo box permet de sélectionner le classement pour un seul parcours

“Page de Leaderboard”: Cette version de la page a un classement de parcours séléctionné.

À noter

Les screenshots de la version mobile du site ont été omis pour ne pas encombrer le rapport, cependant le front-end est entièrement responsive et nous avons même joué à notre jeu sur un vrai téléphone grace au serveur local Uwamp/xampp.

La fin du début | Comment jouer ?

Et voilà! La présentation du site est terminée, et vous savez tout ce qu’il y a à savoir pour lancer le projet. Nous parlons plus en détail des aspects techniques et de la conception du jeu dans la suite du rapport, mais si vous êtes impatient de jouer il vous suffit de lancer Uwamp, et ensuite d’importer le fichier SQL/database puis SQL/insert afin de mettre en place les tables et les parcours de démonstration.

Nos Technologies

Pour la création de ce site, un de nos objectifs a été de baser les fondations de notre jeu sur des technologies de l’Open Data. Après beaucoup de recherches et de difficultés à apprendre à utiliser les différentes solutions disponibles, nous avons réussi à dépasser notre objectif et à utiliser l’Open Data pour l’entièreté du site. Pour cela nous avons maitrisé les outils de leaflet, mapillary, et Uwamp/Xampp avec MySql.

Le front-end: Leaflet et Mapillary

La page centrale de notre applicatif jeu.html, est portée par deux technologies combinées.

Nous utilisons une carte leaflet comme outil principal d’interaction pour le joueur. Il peut y explorer la carte, et déposer un marqueur lorsqu’il veut donner une réponse. Nous l’informons ensuite sur cette carte de sa vraie position, en lui affichant deux marqueurs et une ligne entre les deux points.

L’outil principal d’exploration quand à lui est Mapillary, avec lequel on affiche la streetview qui sert de d’indice au joueur pour se repérer.

Le back-end: PHP et SQL

Notre back-end est structuré en deux couches, une couche base de données qui stocke toutes les informations requises par le jeu; et une couche API qui cache au front-end le fonctionnement du back-end et vice-versa, tout en leur permettant de communiquer entre eux.

Notre processus de création

Création d’un cahier des charges

La première chose que nous avons faite a été de chercher un idée à mettre en place. Après avoir choisi de reproduire Géogussr nous nous sommes penchés sur le fonctionalités basiques que nous pensions être nécessaires pour avoir une expérience complète. Nous sommes tombés d’accord sur trois fonctionalités de base:

la capacité pour le client d’explorer son environnement.
la capacité pour le client de jouer/créer des parcours.
la capacité de s’inscrire et de se connecter pour les clients.

La conception de la base de données

Après nous être décidés sur les tâches que nous devions accomplir, nous avons réfléchi à la structure de données qui soit la plus flexible possible et qui nous permette de remplir le cahier des charges que nous nous sommes donnés. Après plusieurs itérations nous sommes arrivés sur le modèle relationnel suivant:

Nous avons affiné ce modèle au fil du développement. Pour arriver au schéma suivant:

Les tables présentes dans cette base de données finale sont :

Client qui regroupe les informations du client ( idClient, pseudo, icon et mot de passe)
Parcours qui regroupe le descriptif d’une partie de jeu (IdParcours, nom du parcours, image du parcours, description du parcours)
Question qui regroupe toutes les questions du jeu c’est-à-dire les coordonnées d’un lieu (latitude,longitude)
Compose qui lie une question à un parcours (idQuestion, idParcours)
Historique qui enregistre chaque partie jouée par le client
ScoreTotal qui enregistre le score total des clients pour chaque parcours Et contient aussi un ensemble de procédures et triggers comme addClient, ou addComposition, qui permettent de cacher au PHP le fonctionnement exact de la base de données.

Création de la spécification de notre API

Après avoir effectué la conception de la base de données, nous nous sommes mis d’accord sur une “spécification d’API”, avec plusieurs fichiers JSON qui étaient utilisés à la place du lien api final pour le front end, et qui servaient d’exemples de résultat à finir pour le back-end.

Implémentation en parallèle du front et back end

Grace aux fichiers JSON qui servaient de spécifications, nous avons pu développer le front-end et le back-end en parallèle, avant même que les vraies implémentations soient finies. Nous avons ensuite juste remplacé le lien des fichiers JSON avec les liens vers les fichiers php api dans nos requêtes JS.

Bilan

Nos difficultés et ce que l’on a appris

Les plus grandes difficultés que l’on a eue lors de ce projet ont été l’utilisation de PHP et de Mapillary.

Php étant un langage que nous avons récemment appris contrairement à l’HTML/CSS/JS, nous avons dû prendre un peu plus de temps pour nous y acclimater. Son utilisation assez importante dans le projet, comme intermédiaire entre le front et le back-end, nous a permis de le maîtriser beaucoup mieux.

Mapillary quant à lui nous a forcé à mener beaucoup de recherches et de faire de nombreux d’essais avant de réussir à l’utiliser. En effet ce service n’étant pas très connu, les ressources tierces sur l’utilisation de son API étaient peu nombreuses. Nous avons donc dû utiliser uniquement la documentation officielle, qui n’était pas centralisée ni complète. Pour rendre la tache plus difficile, plusieurs versions de l’API étaient disponibles, avec plusieurs versions de la documentation incompatible entre elles. Un exemple flagrant de l’instabilité de cette API, est le fait que Mapillary ait fait un changement quelques jours avant la présentation, ce qui a rendu les exemples de la documentation et notre application non fonctionnelle. Cela nous a donc forcé à réparer ce changement à la dernière minute.

Le résultat final

Nous sommes très satisfaits du résultat final, et de ce que l’on a appris avec ce projet. Nous avons implémenté toutes les fonctionnalités que nous souhaitions, et obtenu des compétences versatiles comme la bonne lecture de documentation d’API tierces.

En rétrospective, l’échelle du projet a cependant été un peu trop importante ce qui nous a donné des difficultés pour le finir simultanément avec nos autres projets.