Mysteriard
Contexte & objectif
Le Pays de Montbéliard Agglomération est labellisé « Capitale française de la culture » pour l’année 2024.
A cette occasion naît Mysteriard, un jeu de piste android narratif qui a pour but de faire découvrir la ville de Montbéliard à travers ses mythes, légendes et figures historiques.
Alors faire découvrir cette petite ville de Franche-Comté, oui, mais l’enjeu de conception était surtout de le faire de façon intéressante, ludique et immersive !Le petit plus ? Mysteriard invite l’utilisateur à visiter la ville, en vrai ou depuis son canapé, pour résoudre des énigmes.
Mais comment visite-t-on une ville depuis son canapé ?! Facile, l’app intègre Google Street View pour permettre au joueur d’explorer les rues. Ce n’est pas aussi immersif que la vraie vie, mais ça permet de découvrir Montbéliard, même depuis Périgueux !
Mon rôle
Mysteriard est né comme un projet scolaire en équipe, où j’étais cheffe de projet, mais le projet me tenait à cœur et j’avais encore plein d’idées alors je l’ai continué en solo. La phase de recherche initiale — lecture de récits, légendes et sources historiques sur Montbéliard, choix des personnages et mythes à intégrer, format de jeu de piste — a été menée collectivement.
A partir de tout ça, j’ai imaginé les mécaniques, construit l’intrigue et la narration qui relie le tout, réfléchi à l’architecture de l’information, aux wireframes, mis en place les ajustements suite aux tests utilisateurs préparés collectivement et développé l’application. Les illustrations, la direction artistique, le design visuel des interfaces et la communication ont été gérés par d’autres membres de l’équipe.
Aperçu – du wireframe aux écrans finaux
Conception – mécaniques et intrigue
Pour éviter que ce jeu à vocation culturelle ne devienne rébarbatif, la narration a été construite autour de trois mécaniques complémentaires, chacune répondant à un besoin précis :
Dialogues
Ils plongent le joueur dans un univers, introduisent des personnalités historiques de manière vivante et transmettent un tas d’informations sans rompre l’immersion du joueur.
Le fonctionnement est simple et intuitif : un personnage parle et le joueur a le choix entre deux réponses pour faire avancer le dialogue et chaque dialogue fait avancer l’intrigue. Donner un choix de réponse permet d’impliquer le joueur plutôt qu’une simple transmission d’information passive.
Mini jeu de reconstitution de mot
Comme des mots clefs qu’on taperait dans un moteur de recherche, le joueur doit reconstituer 3 mots en lien avec les indices qu’il a précédemment, afin de faire une recherche dans la bibliothèque (quartier général du personnage incarné par le joueur).
Cette mécanique permet de transmettre des informations plus factuelles pour faire avancer l’intrigue de façon ludique et sans entacher l’immersion.
Enigmes
Cette partie qui va pousser à l’exploration et ancrer la narration dans un point d’intérêt à visiter. Une énigme est présentée au joueur et il doit observer l’environnement qu’il visite pour trouver la réponse. Le joueur s’y rendre physiquement ou explore via Google Street View. L’apperçu du lieu sur Street View s’ouvre et se ferme d’un clic dans l’application pour réduire un maximum la charge mentale et éviter toutes frictions.
Le joueur est à la fois plongé dans le lieu et dans l’histoire. Cette mécanique joue donc beaucoup sur l’immersion du joueur, tout en exploitant le côté ludique du jeu de piste.
Le tout est découpé en chapitres à chaque fois construit autour d’un personnage et un lieu et chaque chapitre rapproche le joueur de son objectif final. Les chapitres intègrent chacun notre boucle de gameplay où chaque mécanique nourrit la suivante : dialogue – mini jeu – dialogue – enigme – dialogue.
Les écrans – wireframes
Une fois ces trois mécaniques créées, il faut transposer le tout en une interface claire et intuitive. Partant du principe que l’application sert de support pour visiter physiquement la ville, le jeu doit être jouable sur 2h maximum et il est impératif que le jeu soit facilement et rapidement utilisable sur un téléphone. L’application est donc un choix évident.
Cette réalité est à la source de nombreux choix de conception. L’attention du joueur n’est pas à 100% sur le jeu et son aventure sera entrecoupée. L’application n’est qu’un fil rouge et il doit pouvoir le suivre sans effort.
Le jeu sera donc un enchaînement d’écran où chaque mécanique correspond à un ensemble de types d’écran dont les contenus, personnages et décors varient selon l’avancé du joueur dans l’intrigue.
Dialogues
On y montre le personnage dans son décor et on affiche sa réplique (premier écran).
Le joueur appuie sur le bloc de dialogue pour signifier qu’il a fini de lire et qu’il souhaite passer à la suite.
Ce clique déclanche l’arrivé de l’écran suivatn : une autre réplique du personnage ou un choix entre deux réponses pour le joueur (deuxième écran).
Mini jeu de reconstitution de mot
Le mini-jeu consiste toujours en la reconstitution de trois mots.
Trois séries de cases vides en ligne sont alors affichées sous un rappel du but/de l’information à trouver.
En dessous, une série de lettres est présentée. Elles correspondent aux lettres à utiliser pour reconstituer les mots. Elles sont affichées dans un ordre aléatoire et il peut y avoir quelques lettres qui ne servent à rien. Au contraire, certaines lettres peuvent apparaître plusieurs fois.
Le mobile étant tactile, la mécanique se prête très bien au « drag and drop ». Le joueur doit donc prendre une lettre et la glisser-déposer au bon emplacement pour que celle-ci y reste. La lettre en question n’est alors plus disponible dans la pioche.
Enigmes
L’énigme est posée au joueur et reste visible au-dessus des champs de réponse. Ces derniers peuvent être très divers en fonction de l’énigme en question (deux séries de nombres à quatre chiffres, deux séries de nombres à respectivement un et deux chiffres…).
Le mécanisme du mini-jeu est repris : le joueur se voit présenter des séries d’un certain nombre de cases vides (ce qui consiste déjà en un indice) et d’une pioche avec laquelle il doit remplir les cases vides.
Ecrans complémentaires
Pour que le joueur puisse à tout moment se remémorer où il en est, comme s’il avait pris des notes, un écran résumé du chapitre est ajouté et toujours disponible.
Un écran d’accueil est aussi pensé pour que le joueur reprenne son aventure, peu importe où il en était, ou recommence s’il le souhaite.
Tests utilisateurs
Afin d’estimer l’utilisabilité de notre interface et identifier les potentiels points de friction, 2 types de tests sont effectués sur un échantillon qualitatif restreint mais diversifié :
- Test de tâche et questionnaire : le testeur joue en autonomie avec le moins d’indication possible (seulement en cas de blocage) puis répond à un questionnaire évaluant la compréhension du jeu et de ses actions ainsi que la qualité des différentes mécaniques (longueur, intérêt, cohérence).
- Observation comportementale : le testeur joue en autonomie en étant observé sans intervention (à part en cas de blocage), afin d’identifier les comportements instinctifs non anticipés et les écarts entre l’usage prévu et l’usage réel de l’interface.
Itérations & décisions suite aux tests
Le passage du wireframe à la version jouée a fait remonter plusieurs frictions et axes d’amélioration, identifiées à la fois par l’équipe et par les retours de tests.
Quatre grandes modifications ont alors été apportées :
Afin expliciter l’enchaînement logique des écrans/mécaniques et pour que le joueur suive facilement les changements de localisation dans le fil narratif tout en différenciant les lieux purement fictifs des lieux qu’il peut visiter, des écrans de transition sont ajoutés.
Ajout d’un rappel de la dernière réplique du pnj sur l’écran de choix de réponse pour que l’utilisateur sache toujours à quoi il répond.
Ajout d’un “indice” aux mini-jeux et énigmes pour motiver le joueur bloqué à continuer, transformant ainsi un point de friction potentiel en un levier de remotivation pour favoriser la rétention.
Ajout d’un onglet “i” afin de transmettre des informations plus factuelles afin d’apporter du contexte aux joueurs qui en voudraient, sans entacher leur immersion.
Développement & intégration
Le jeu a été développé avec les technologies du web (html, CSS, JS, jquery, Json). Le tout est embarqué dans une WebView Android et exportée en APK pour une diffusion sur le Play Store.
L’architecture repose sur une séparation des données et de la gestion de l’affichage. Chaque écran est généré par un script qui récupère le contenu correspondant à l’avancé du joueur pour l’afficher. Un script maître d’orchestre lance les scripts correspondant au type d’écran à afficher selon l’avancé de l’histoire. L’avancé du joueur est conservé sur le stockage local du navigateur, ce qui permet au joueur de retrouver son avancée même s’il est interrompu.
Pour visiter Montbéliard à distance, API Google Maps avec l’affichage Street View est intégré à l’application. Chaque énigme est associée à des coordonnées réelles, affichées à la fois comme carte et comme panorama à 360°, permettant de repérer les mêmes indices visuels qu’en se rendant physiquement sur place.
Résultat et retours d’expérience
Mysteriard a été publié sur le Play Store et présenté au public lors d’un événement à la médiathèque de Montbéliard, où une activité énigme a été proposée comme introduction/prequel au jeu aux visiteurs, une occasion de confronter le projet à un public réel.
Ce projet reflète bien ce que signifie concevoir une expérience de bout en bout : poser un objectif clair, le traduire en mécaniques de jeu cohérentes, tester ces choix avec de vrais utilisateurs, rebondir sur les résultats des tests, puis le développer techniquement jusqu’à la publication.