Jeu thérapeutique open source

 Master of Science HES­SO in Engineering Av. de Provence 6 CH­1007 Lausanne Master Of Science HES­SO in Engineering Orientation : Technologies de l’information et de la communication (TIC) Jeu thérapeutique open source Fait par Bonnivard Matthias Sous la direction de Prof. Aicha Rizzotti Dans l’institut ISIC­Arc de l’école HE­ARC [Expert externe : Fabio Balli, Initiateur et garant de la vision jeuxmucoviscidose.net] HES­SO//Master 2016 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias fibrosekystique.net cysticfibrosisgames.net juegosfibrosisquistica.net jeuxmucoviscidose.net Sommaire: 1. Introduction 1.1. Présentation du projet 1.2. Abréviations 2. Analyse 2.1. La Maladie 2.1.1. Mucovicidose ou fibrose kystique 2.1.2. Traitement 2.1.3. Exercices 2.1.4. PEP (Pression expiatoire positive) et Flutter 2.1.5. Pratique quotidienne 2.2. Serious Game: Breathing Games 2.3. Environnement de développement (Unity + C# Scritpting) 2.4. Analyse de “Heritage” 2.4.1. Analyse du contenu sous Unity 2.4.2. Première analyse du code 2.4.3. Analyse finale du code 3. Conception 3.1. Création d’un coeur 3.1.1. Faire du coeur un Unity Asset 3.1.2. Ouverture à la communauté Unity 3.2. Essai du coeur 3.2.1. Remise en question 3.2.2. Point pour améliorer l'assiduité du patient 4. Implémentation 4.1. Extraction du coeur depuis Heritage 4.1.1. Architecture Logicielle 4.1.2. Corrections dans Unity 4.2. Module de test : RollABall 4.2.1. Description générale du module de test 4.2.2. Contenu du Prototype “Roll A Ball” 4.2.3. Connexion de BreathingGameCore dans “Roll A ball” 5. Problèmes rencontrés 6. Améliorations et Perspectives 6.1. Au niveau du “Coeur”, de “Heritage” et de “Roll A Ball” 6.2. Pour les Breathing Games plus généralement 7. Conclusion 8. Références 1 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias 1. Introduction 1.1. Présentation du projet Ce document a été réalisé dans le cadre d’un projet d’approfondissement pour la formation de “Master of science in of Engineering” en technologie de l’information et de la communication, orientation ingénierie logicielle proposée par la HES­SO. Le but du projet était de mettre en place un “Coeur” pour tout les Serious Game (SG) développés dans le cadre du projet Breathing Games. L’ensemble de ces jeux ont été réalisé pour les enfants atteints de la mucoviscidose, aussi appelée fibrose kystique (CF), afin de les aider à réaliser leurs exercices de physiothérapie liés à la respiration. Comme les personnes atteintes de CF doivent améliorer leur qualité de vie au quotidien, au travers d’exercices peu intéressants et par conséquence peu suivi. L'objectif de ces SG est donc de créer un aspect ludique pour rendre les jeunes patients plus réceptifs et donc assidue à leurs exercices. Le projet d'approfondissement présenté ici contribue à un grand projet plus général des “jeuxmucoviscidose.net” qui a pour but de proposer de nombreux Serious Game en rapport avec la CF sous forme open source. Le but de ce projet est notamment de s’ouvrir à diverse pratique thérapeutique dans le monde ainsi qu’une collaboration active de divers contributeurs directement concernés par la problématique ou non. D’autre projet antérieures avaient permis de mettre en place des premières idées de jeu ainsi qu’une API permettant de récupérer les informations du périphérique respiratoire devant être utilisé: Le Flutter. Dans ce document, il sera décrit les 3 phases qui ont été approché durant le travail, c’est à dire l’analyse, la conception et l'implémentation. Il est à noté qu’une partie conséquente du temps de travail a été consacré à l’analyse et à la conception. En effet, les technologies utilisée et les connaissances médicale et pédagogique nécessaire à la compréhension de ce projet sont importantes. Résumé du projet sur GAPS: Le système de jeu est développé en mode agile sur Unity 3D / C#. Il se compose d'un noyau gérant les configurations et données thérapeutiques, d'un éditeur permettant à l'utilisateur de créer des niveaux (style Little big planet), et de modules dédiés à diverses thérapies (gameplay spécifiques). A ce jour, trois prototypes ont été testés et un premier niveau de jeu a été réalisé. Il s'agit de construire sur cette base pour rendre le jeu attractif sur la durée, en respect des contraintes thérapeutiques et des besoins d'accessibilité. 1.2. Abréviations ●
CF: “Cystic Fibrosis” désigne la fibrose kystique ou mucoviscidose. 2 / 20 Projet d’approfondissement , Printemps 2016
●
●
●
Bonnivard Matthias SG: “Serious Game” désigne un jeu avec un but sérieux. BG: “Breathing Games” désigne la plateforme de jeux pour la mucoviscidose. PEP: Pression expiratoire positive. 2. Analyse En amont de la conception du coeur pour les BG et du prototype de jeu pour le tester, la partie analyse a représenté une bonne partie du travail fait tout au long du projet. Elle a pour objectif dans un premier temps de mieux comprendre les tenant de la maladie, dans un second temps de comprendre le contexte des Serious Game pour les Breathing Games et finalement de faire une analyse du jeu “Heritage” ainsi que son environnement de développement. 2.1. La Maladie 2.1.1. Mucovicidose ou fibrose kystique La mucoviscidose (pour « maladie des mucus visqueux » en français) ou fibrose kystique (en ​
anglais​
: cystic fibrosis, sous­entendu « du pancréas ») est une ​
maladie génétique​
, affectant les ​
épithéliums glandulaires​
de nombreux organes. C'est la maladie génétique létale​
à ​
transmission autosomique récessive​
la plus fréquente dans les populations de type europoïde​
, alors qu'elle est très rare dans les populations africaines et asiatiques. Elle est liée à des ​
mutations​
du ​
gène CFTR​
sur le ​
chromosome 7​
, entraînant une altération de la ​
protéine​
CFTR (sigle pour cystic fibrosis transmembrane conductance regulator). Cette protéine est un ​
canal ionique​
perméable au ​
chlore​
, au​
thiocyanate​
7​
dont la fonction est de réguler le transport du chlore à travers les ​
membranes cellulaires​
. Son dysfonctionnement provoque une augmentation de la viscosité du ​
mucus​
et son accumulation dans les ​
voies respiratoires​
et ​
digestives​
. La maladie touche de nombreux ​
organes​
mais les ​
atteintes respiratoires​
sont prédominantes et représentent l'essentiel de la ​
morbidité​
. La forme clinique la plus fréquente associe 3 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias troubles respiratoires, troubles digestifs et ​
troubles de la croissance staturopondérale​
. D'évolution chronique et progressive, la maladie s'exprime souvent tôt dès la petite enfance même s'il existe des formes frustes de diagnostic tardif. 2.1.2. Traitement Pour traiter cette maladie l’objectif principale est la prise en charge par l’éducation du patient et de sa famille ainsi que la prévention et le traitement précoce des complications broncho­pulmonaire. Le but ici est le maintien d’une fonction respiratoire et d’un état nutritionnel optimal pour une amélioration de la qualité de vie. A ce jour aucun traitement curatif n’est actuellement disponible et donc les seules solution sont des traitement symptomatique qui permettent de soulager les symptômes de la maladie. Une prise en charge multidisciplinaire est donc nécessaire (​
le pédiatre, le kinésithérapeute, le diététicien ou le psychologue​
) et consiste largement en une prise en charge de l’atteinte respiratoire par un drainage bronchique accompagné d’antibiotiques et de supplément alimentaires. 2.1.3. Exercices Ici il sera décrit les différents exercices qui permettent de pallier au multiples symptômes causé par la CF. Les exercices qui sont des traitements palliatif à l’atteinte des voies respiratoires passent par la ​
kinésithérapie respiratoire. Les bronches sont souvent obstruées par une stase de mucus et sujettes à des infections broncho­pulmonaires permanentes. La ​
kinésithérapie​
a pour objectif de mobiliser et d'évacuer les sécrétions bronchiques, apportant un effet bénéfique immédiat et limitant possiblement à long terme les effets des médiateurs pro­inflammatoires contenu dans les sécrétions muco­purulentes. Tout ceci permet au patient de maintenir une adaptation optimale à l’effort. Les différentes techniques de la kinésithérapie respiratoire conventionnelle sont le drainage de posture, la percussion et la vibration. Il y a aussi des techniques plus récentes utilisant le contrôle du flux expiratoire. Pour aider ces méthodes respiratoire les praticiens ont recours à des techniques instrumentales : ● L’​
aérosolthérapie​
de médicaments qui tant à l’amélioration de l’humidification des expectrorations. ● Le “Threshold inspiratoire” qui a pour but d’améliorer l’endurance et la force des muscles inspiratoires ● L’aspiration des fosses nasales 4 / 20 Projet d’approfondissement , Printemps 2016
●
Bonnivard Matthias Les systèmes de Pression Expiatoire Positive appelé PEP qui va entraîner une augmentation du volume de l’expectoration. 2.1.4. PEP (Pression expiatoire positive) et Flutter Le PEP combiné au Flutter est l’outil qui permet de faire des exercices palliatifs par lequel notre breathing game (Heritage) est concerné. C’est la raison pour laquelle elle sera détaillée par la suite. La technique PEP entraîne le désencombrement développée pour réduire les troubles ventilatoires qui obstruent les bronches. Schéma de système PEP Le patient doit souffler dans l’appareil pour faire rebondir une bille d’acier dans celui­ci causant une vibration qui obstrue le passage de l’air et créant ainsi une oscillation de la pression. Comme pour les autres techniques le patient répète une manoeuvre de 10 à 15 respirations, puis plusieurs expirations forcées ou toussotement. Ce cycle est donc répété 3 ou 4 fois pour donner une session de désencombrement allant de 15 à 20 minutes. L’avantage est que c’est un appareil peu onéreux ce qui le rend accessible. En plus cela rend la technique praticable de manière individuelle. Chaque patient doit trouver la fréquence de résonance des vibrations avec la cage thoracique du patient ce qui semble maximiser l’impact de l’oscillation. Oscillation de pression sur les parois des poumons pour maximiser le décollement du Mucus. Le patient doit donc trouver l’inclinaison optimale du FLutter par tâtonnement. 2.1.5. Pratique quotidienne La problématique qui ressort de l’utilisation du PEP est essentiellement liée à l’adhérence aux traitement. D’après une étude universitaire aux USA, la faible adhésion est très significative pour les patients atteints de fibrose kystique, cette adhésion se situerait en dessous de 50% en particulier auprès des adolescents. 5 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias C’est donc la la problématique qui doit être résolue par les Breathing Games surtout pour la pratique faite par les plus jeunes patients. 2.2. Serious Game: Breathing Games Dans cette partie il sera définit ce qu’est un serious game et ensuite pourquoi il est utilisé dans les exercices respiratoires combinés à des jeux proposés par Breathing Games. Un serious game ou jeu sérieux en français est un logiciel qui va combiner l’aspect ludiques apporté par un jeux vidéo en général avec une intention pédagogique, médicale ou d'entraînement. L’apport espéré par un jeu sérieux est de rendre attrayant la dimension sérieuse par une inter activité ou des objectifs ludiques. Les jeux sérieux sur le thème de la santé sont très fréquents de nos jours, ils sont utilisés pour sensibiliser la population à leur bien être. Généralement ils vont être utilisés par des patients touchés par une maladie et par leurs proches. Dans cette mesure, la plate forme BG sur le web est une initiative qui a pour but de répondre par l’utilisation des Serious Game à la difficulté à faire adhérer aux patients leurs exercices de traitement palliatif pour la CF. La raison d’être de cette initiative est d’améliorer la qualité et l’espérance de vie des personnes atteintes de difficultés respiratoires. Pour cela, la conception et la distribution à large échelle et à moindre coût de supports thérapeutiques ludiques et éducatifs. 2.3. Environnement de développement (Unity + C# Scritpting) Pour tout ce qui concerne le design et les interfaces utilisateurs dans le jeu heritage l’outil Unity a été utilisé. Unity est un moteur de jeu qui permet de développé des jeux pour toutes plateformes. C’est un moteur très répandu car il est très rapide à prototype. De plus il est sous licence gratuite. Le logiciel a pour particularité d’utiliser un éditeur de script compatible avec Visual Studio pour développer des script ainsi que des architectures logicielles complexes en C#. Dans le cadre de ce projet, il a donc était nécessaire de se familiariser avec l’outil unity au travers de tutoriels d’initiation. Les tutoriels disponibles sont nombreux et sous forme de vidéo pour la plupart ou différents aspect de la conception d’un jeu sont abordés. Il a aussi fallu s’habituer à l’environnement visual studio et au langage C#. 2.4. Analyse de “Heritage” Le jeu Heritage est développé en collaboration avec la Haute école Arc de Neuchâtel et le CHUV ainsi que deux autres hôpitaux. 6 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias Le jeu est donc un SG destiné à un enfant atteint de CF. Ici l’enfant a pour mission de défendre les cultures de différents pays. Le niveau de la Grèce a été développé et représente un personnage qui doit attraper un voleur qui s’est emparé du trident de Poséidon. Ce jeu rassemble des fonctionnalités communes au jeux BG. C’est a dire une interface de navigation, la gestion des langues, la gestion des univers visuels, la gestion des périphériques entrant et le paramétrage des cycles thérapeutiques. Image prise pendant le cours du jeu 2.4.1. Analyse du contenu sous Unity L’état du jeu au début du projet est composé d’un ensemble d’Assets Unity qui génèrent diffèrent aspect du jeu tant au niveau du design que des mécanismes. Contenu de Heritage dans Unity Sur cette image l’on peut voir le contenu du jeu dans unity. Le panneau de gauche représente tout les object qui ont été ajouté dans le jeu tels que le Player, le niveau 7 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias level_greece_underwater, de gestionnaires pour le son, la caméra, des obstacle et autre. C’est l’ensemble de ces GameObject de unity qui définit le contenu visuel et sonore du jeu. Lorsqu’un de ces composant est sélectionné, comme sur l’image ci dessus, on peut voir tout les composant qui sont contenu dans ce GameObject. Le composant transform qui définit la position dans l’espace visuel par exemple ou le collider qui va gérer les collisions comme son nom l’indique. Finalement on voit que des script C# sont relié à ces GameObject en prenant en compte plusieurs paramètres. Par la suite il est donc nécessaire de se pencher sur la partie code de Heritage. 2.4.2. Première analyse du code Dans un premier temps, avec l’aide de Nicolas Wenk qui a participé grandement au développement du jeu, une analyse générale de la structure du code. J’ai ensuite fait une extraction simple en supposant que le code ce scinderait bien entre des parties spécifiques à Heritage et des parties spécifiques au Noyau BG que nous voulions mettre en place. Heritage est composé de 3 packages principaux et après une première revue du code avec Nicolas, l’analyse supposait la séparation suivante par package: ●
Package Controller : ○ séparation de classe propre au jeux et des classes générales 8 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias Les classes ​
CalibrationController.cs ​
et MenuController.cs​
​
devront être intégré au noyau. ■ La plupart des autres classes semblent propre au contrôle dans le jeu de Heritage. Package Model : ○ Model/Curves : ■ Le calcul des courbes pour les exercices respiratoires semblent correspondre au noyau. ○ Model/Exercices: ■ Devrait être en grande partie extrait vers le noyau aussi. ○ Model/Input: ■ Toutes les classes de ce package sont basées sur l’interface InputController_I.cs. Dans cette classe seule la dernière méthode IsMoving() dépendra spécifiquement du jeux. Il serait donc utile de remonter tout cela vers le noyau pour utiliser ces contrôleurs dans d’autres jeux aussi. Package View : ○ il semble préférable dans un premier temps de laisser ce contenu propre au jeu héritage. Pourra être rediscuté après que le noyau soit plus avancé. ■
●
●
Suite à cela, des modifications ont été faites sur une extraction de Heritage et après avoir enlever le contrôle du déplacement, méthode IsMoving() dans la classe InputController.cs, beaucoup d’autres modifications en ont découlés. Dans les autres parties du code, ainsi que dans les “branchages” à faire avec Unity, de nombreuses fonctionnalités ont étés altéré. A ce stade il est apparu assez clair que la création d’un noyau complet était beaucoup plus complexe que prévu. Et que la couche Unity ajoutait beaucoup de complexité au tout. 2.4.3. Analyse finale du code Dans cette partie il sera décrit l’analyse finale qui résulte de plusieurs itération de l’analyse, la conception et l’implémentation. Malgré cela il semblait plus judicieux de la conservée ici pour faciliter la compréhension des parties conception et implémentassions. Dans cette seconde analyse, il a donc était sujet de faire une analyse qui séparait bien la partie Controller de la partie Model. Les 3 packages principaux ont donc été revu classe par classe pour s’assurer que les dépendances seront mieux identifié par la suite. L’idée derrière tout ça est qu’il et préférable d’avoir un coeur qui ne porte que sur une partie du code de Heritage, que sur le package Model par exemple que de vouloir absolument tout prendre mais que le résultat soit bancale. Si dessous les analyses détaillées par package et contenant des observations pour chaque classe ou la séparation n’était pas triviale: Concernant le package “Controller”: 9 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias ●
●
●
Breathe.cs : doit être divisé pour s’inclure dans le coeur HeritageCalibrationController.cs : classe à implémenté dans heritage et qui hérite de calibration controller PlayerController.cs : Doit être dans le noyau mais contient beaucoup de dépendance à Heritage. Concernant le package “Model”: ● Ajout d’une classe InputController_I_GameSpec qui va permettre d’implémenter des fonctionnalités spécifique. Dans le cas de Heritage, par exemple, la méthode onMover() spécifique au jeu sera implémenté ici. Il en sera de même pour tout autre jeu des BG ● Enlevé les dépendance à onMove() dans le reste du package car elle est ré­implémentée de nombreuses fois. ● Vérifier que Exercice.cs est indépendant de Heritage et donc faire les modifications nécessaires. Concernant le package “View”: Dans le package View, la plupart des fonctionnalités implémentées sont utilisé seulement par des fonctionnalités du jeu Heritage et non générale à au Coeur Breathing Game. Pour les classes Bar.cs, CurveViewer.cs et PepInputChart, il faut vérifier si l’utilisation faite pour la calibration est réutilisable et dans quelle mesure. 10 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias 3. Conception Cette partie correspond à un travail fait durant tout le projet, il est à noter que la conception finale décrit ici le concept final mais que de nombreuses étapes intermédiaires de réflections ont été nécessaires. De plus, les étapes successives décrites dans la partie analyse de Heritage vues précédemment se sont fait en parallèle chronologiquement parlant. Malgré cela il est apparu préférable de découper l’analyse et le concept de cette manière. 3.1. Création d’un coeur Initialement le coeur que l’on veut créer pour les Breathing Games va être extrait depuis le jeu Heritage. Les fonctionnalités pour les interactions et l’utilisation des input devront être donc conservées. L’architecture logicielle désirée suite à la séparation du jeux purement visuel et de son coeur avec les outils de fonctionnalités qui en résultent devraient être structurées de la manière à avoir deux packages bien distincts. La forme finale dans Heritage devrait donc ressembler à ceci: Structure du concept finale dans Heritage L’idée derrière cette séparation est de transformer le package “BreathingGameCore” comme on peut le voir dans l’image ci dessus en une dll telechargable depuis le “Asset Store” de Unity par exemple. Mais cela nécessite d’avoir une librairie testé et fonctionnelle. Une fois tout cela mis en place on peut utiliser le “Asset Store” de Unity. En effet, cet asset store propose à tout les utilisateurs un très grand nombre d’outils qui sont téléchargables directement depuis le projet en cour. 3.1.1. Faire du coeur un Unity Asset De nombreux assets gratuits ou payant propose plein de solutions aux problèmes auxquels font fasse les nouveaux développeurs de jeux vidéo sur Unity. Il vaut souvent mieux faire 11 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias une recherche sur le “Asset Store” pour résoudre un problème donné plutôt que de chercher à tout vouloir refaire sois même. C’est donc pour cela qu’il serait intéressant de faire de même pour les jeux BG. En effet, de nombreux avantages semblent évidents, tel que la portabilité de Unity sur toute plateforme. En effet, comme on veut proposer de jouer soit sur son ordinateur soit sur téléphone avec un système audio, l’outil Unity ne parait pas nous limiter. Dans cette mesure, il est extrêmement intéressant d’arriver à une véritable asset “Breathing Game”, en partant de notre coeur actuel. 3.1.2. Ouverture à la communauté Unity En plus, on pourrait ajouter dans le futur de nombreux autres outils en rapport avec les BG. Par exemple, incorporée lors de la calibration, la même barre respiratoire dans tous les jeux BG à travers cet asset mis gratuitement sur le “Asset Store”. Ou encore de faire des interfaces tel qu’un menu général BG ou des vidéos tutoriels pour normaliser les jeux BG. On peut même imaginer que cela pourrait nous permettre de toucher plus de développeur de jeux vidéo, car Unity est devenu une grande communauté, surtout pour les développeurs indépendants. Le point très positif ici, c’est qu’une fois ce coeur mis en ligne sur le “Asset Store” de unity, On pourrait ensuite se mettre en relation avec des développeurs de jeux gratuit fait sur Unity auquel on aurait déjà apporté un concept d’intégration dans les BG. Ce qui permettrait d'accélérer l’augmentation du volume de jeux sur la plate forme. Mais pour cela il est très important d’avoir un coeur facile à intégrer dans n’importe quel jeux et une documentation pour la mise en place de celui­ci. On se rend donc bien compte de l’utilité de ce coeur pour le développement des BG. 3.2. Essai du coeur 3.2.1. Remise en question Par la suite, il sera nécessaire de tester notre coeur dans le cadre d’un nouveau jeu fraîchement crée. Ainsi il sera plus facile d’avoir un oeil critique sur l’état du coeur et surtout de voir quelles sont les dépendances à Heritage qui ont persistés. Ici le concept du jeu lui même n’est pas un but en soi. Malgré cela, comme le sujet et le concept du jeu était totalement libre, il aurait été dommage de ne pas profiter pour imaginer un concept de jeu intéressant. En gardant à l’esprit que le but principale de ces jeux est d’éviter que les jeunes patients se soustraient à leurs exercices en leur proposant quelque chose d’amusant et avec une dimension possiblement addictive. L’idée est de se concentrer sur le concept du jeu plus que sur le design tout en éloignant de l'esprit de l’utilisateur l’aspect exercice médical. L’objéctif est donc de remettre en question les jeux actuellement disponible pour les BG et donc de revoir les défauts et avantages pour imaginer autre chose. 12 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias 3.2.2. Point pour améliorer l'assiduité du patient Le jeu devra apporter un axe plus orienté compétition plutôt que de faire un jeu joli à voir mais dont le gameplay n’est pas immersif. Comme la période des exercices doit durer entre 15 et 20 minutes, il parait difficile de plonger le joueur dans un univers avec une histoire comme c’est le cas dans Heritage. Il vaut mieux un jeu avec des parties courtes (4­5 min) ou l’objectif du jeu est pratiquement évident au boût de quelques secondes. L’objectif sera aussi de mettre en place un environnement qui demande de se concentrer sur le jeu pendant les parties. Le joueur doit soit oublier qu’il fait un exercice thérapeutique ou alors utiliser l’appareil respiratoire comme un atout pour améliorer les résultats en jeu. Si le joueur veut obtenir les meilleurs scores, il devra utiliser les exercices respiratoires de manière précise, ce qui pourrait en plus lui faire oublier sa maladie pendant un moment malgré l’exercice thérapeutique. Contrairement à Heritage il serait intéressant d’éviter de rappeler l’exercice respiratoire par de courbes visibles à l’écran qui représentent les cycles de respirations. On peut imaginer d’utiliser une variation de la couleur pour signifier le cycle respiratoire, de choisir une couleur pour l’inspiration et une pour l’expiration. Une autre idée pourrait être de faire varier le volume d’un objet visible à l’écran qui se gonfle quand il faut inspirer et se dégonfle quand il faut expirer. 4. Implémentation 4.1. Extraction du coeur depuis Heritage Dans cette partie la séparation du coeur d’un point de vue implémentation sera abordée. Comme cette partie représente beaucoup de conception d’architecture logicielle et de lecture de code l’aspect concept ayant était largement vu auparavant, l’implémentation est finalement une partie minime du travail. 4.1.1. Architecture Logicielle Comme montré dans la partie conception la restructuration des classes à bien était fait et à présent il y a un Core et une partie Heritage qui sont bien séparées. Malgré cela il reste encore beaucoup de travail de connections entre l’interface dans Heritage et l’architecture logiciel à proprement parler. De plus, il n’y a plus aucune erreur de compilation. A présent le contrôle fait par le PEP (PepInputController) est complètement incorporé au coeur et les inputs liés au gameplay du jeu sont à rajouter indépendemment dans chaque jeu au travers du InputController_I_Game_Spec.cs. Chaque jeux peut donc implémenter son propre ensemble d’input provenant d’un clavier ou autre. 13 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias 4.1.2. Corrections dans Unity Pendant le développement du BreathingGameCore, de nombreuses déconnections se sont fait au niveau de Unity. En effet, les scripts et classes développés dans Visual Studio sont souvent raccordés à un GameObject de l’interface de Unity. Il est donc possible que des morceaux du code de Heritage ne soient pas raccordés à l’identique et pourraient nécessiter une revue avec le développeur initial de Heritage (Nicolas) ultérieurement. Malgré cela un grand nombre de raccordement ont été fait et semblent fonctionner de nouveau. 4.2. Module de test : RollABall Pour cette partie il y avait beaucoup plus de liberté au niveau du jeu unity. Il a donc fallu partir d’une petite idée de jeu pour l’améliorer et trouver comment l'incorporer dans un concept alliant un BreathingGame au game concept de base. 4.2.1. Description générale du module de test L’idée de base est donc une simple plate forme rectangulaire avec des mur sur les 4 côtés. Sur laquelle il y a une sphère qui se déplace et qui est contrôlée par le joueur à l’aide des touches du clavier pour se déplacer sur cette plateforme. Idée initiale Ensuite l’idée du jeu était de générer des objets appelés “pick Up” représentés par des cubes en rotation qui sont générés aléatoirement sur la plate forme de jeu. Le but d’une partie ,qui a une durée déterminée, est donc de ramasser le plus de ces pickUps afin d’obtenir le meilleur score dans le temps imparti. 14 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias Une fois le mécanisme du jeu de base en place, il fallait réfléchir à comment incorporer la dimension breathing game dans ce concept de base. Plusieurs petites idées ont été implémentés dans le jeu mais, mais une seule a été bien avancée, celle qui paraissait la plus intéressante. Les 4 idées étaient: ● respecter le cycle respiratoire va influer sur la vitesse de la boule contrôlée par le joueur ● plus on respecte le cycle respiratoire plus la boule grossit et donc plus c'est facile de ramasser des pickUps ● plus on respecte le cycle respiratoire plus le nombre de pickUps générés est important ● plus on respecte le cycle respiratoire plus la boule grossit et donc plus c'est facile de ramasser des pickUps L’idée de générer plus de pickUps lorsque l’on respecte les cycles paraissait la plus intéressante et c’est sur cette base que le jeu a été avancé. Ensuite pour améliorer cela il fallait trouver un moyen de représenter les cycles respiratoires de manière différente par rapport à Heritage. Le principe de déplacer une sphère va inciter le joueur a suivre des yeux son déplacement sur l’écran. Deux indicateurs visuels ont donc été ajoutés sur la sphère pour indiquer si le joueur doit inspirer ou expirer. Le premier c’est de faire gonfler la sphère pendant l’inspiration comme des poumons qui se gonflent et inversement, expiration quand elle se dégonfle, ce qui parait être assez intuitif. Le second c’est de changer la sphère de couleur, la sphère est verte quand le joueur inspire et rouge quand il expire, cet aspect est simulé par la barre d’espace comme dans Heritage. Un message “expiration” ou “inspiration” apparaît sous la sphère pour aider le joueur à respecter la phase respiratoire. Finalement, c’est lorsque la couleur de la sphère et du message correspondent que le joueur obtient des avantages pour améliorer son score. En effet, la génération de pickUp à ramasser est plus rapide dans ce cas là. 15 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias En haut le cycle respiratoire n’est pas respecté En bas le cycle respiratoire est respecté 4.2.2. Contenu du Prototype “Roll A Ball” Ce prototype est composé de différents game object et de scripts pour fonctionner. Voici la structure du jeu avec les composants et scripts qui en dépendent: ● Un générateur de lumière directionnel. ● Un sol et des paroies. ● Une caméra qui se centre sur le joueur grâce à un script qui calcul la différence en sa position et celle de la sphère ● Une sphère qui représente le joueur. Le script PlayerController y est incorporé et fait le lien avec le coeur. Il permet le contrôle directionnel de la sphère et l'interaction avec le PEP ou en tout cas son simulateur dans notre cas. Il gère aussi les collision avec les autres objets du jeux et les phases des exercices. Le système de bonus en jeu y est aussi implémenté. ● Un prefab PickUps pour générer des objet aléatoirement. Un script permet de gérer la création et les paramètres des objets et leur positions aléatoires. ● Un canvas contenant des objets de texte permettent d’afficher le score, l’état de l’exercice, les bonus, un décompte et la fin de jeu. 4.2.3. Connexion de BreathingGameCore dans “Roll A ball” L’étape suivante est donc de vérifier la possibilité de fonctionnement de notre coeur dans ce mini projet de jeu. Cette partie est sans doute la plus conséquente et la plus complexe. 16 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias En effet, c’est la qu’on s'aperçoit des nombreuses difficultés de connexions. A chaque fois qu’une nouvelle version du coeur à été importée dans le jeu de test de nouvelles erreurs apparaissaient. De nombreuses fois on constate que des classes du coeurs ne sont pas si indépendantes que ça de Heritage. Il faut donc d'abord les retravailler au sein de Heritage et ensuite réimporter dans le jeu de test. La procédure étant assez répétitive, le coeur était contenu dans un package de taille importante qui était copié dans le prototype “Roll a ball”. Le CalibrationController a été adapté pour être plus générique. Chaque classe doit à présent implémenter son propre “HeritageCalibrationController” par exemple pour Heritage qui va étendre le CalibrageController du coeur. Il faudra ensuite override les 4 méthodes suivantes: ​
public virtual void ​
CalibrationStateWaiting(){} ​
public virtual void​
CalibrationStateCharging(){} ​
public virtual void​
CalibrationStateToGameAnimation(){} ​
public virtual void​
CalibrationStateFailAnimation(){} De plus pour la calibration il faut redéfinir l'énumération pour les différents GameState selon ses besoins: public enum ​
GameState {
LOGO, INTRO, CALIBRATION, GAME, END_SCREEN } Il est aussi nécessaire d’implémenter la gestion des autres inputs de contrôle du jeu dans l’interface : InputController_I_Game_Spec public interface ​
InputController_I_Game_Spec {​
/// </summary ​
​
/// ​
Determines whether the patient is holding the moving input or not. ​
/// </summary> ​
bool ​
IsMoving(); } 17 / 20 Projet d’approfondissement , Printemps 2016
Bonnivard Matthias Il ne faut pas oublier d’inclure le dossier Fabric non plus qui est nécessaire au bon fonctionnement du coeur. 5. Problèmes rencontrés ●
●
●
●
●
Difficultés pour lire du code existant ayant été implémenté par différente personnes. Et ensuite devoir le comprendre pour l’adapter au code existant Difficile de comprendre les besoins clair des patients, en effet, n’ayant jamais été à leur contact, il parait difficile de remettre en question les idées de jeux et de comprendre leurs besoins réels. Finalement, on s’est aperçu qu’il y avait trop peu de temps pour beaucoup de travail au final. Même si il était difficile de savoir la quantité de travail avant de se mettre dedans. On peut se dire que cette difficulté était inévitable comment souvent hélas. Tout de même un prototype de coeur et de module de test a été fait, mais il manque encore du travail et sûrement encore de la réflexion. Le projet au niveau conceptuel est bien en place mais il faut plus de temps pour tout raccorder. 6. Améliorations et Perspectives 6.1. Au niveau du “Coeur”, de “Heritage” et de “Roll A Ball” ●
●
●
Suite à ce rapport, il faut continuer à travailler sur le package “BreathingGameCore” Continuer avec le fork de Heritage utilisant le nouveau Coeur qui est à présent combiné avec le prototype Roll A Ball. Améliorations du coeur ○ Retoucher la classe Level Controller pour être sur de sa généricité ○ Continuer de refaire des tests du coeurs en gardant en parallèle Heritage et le jeu de test. ○ Problème de PepInputController.cs quand il est testé sur le coeur. ○ Vérifier qu’il n’y a pas de régression sur la version de Heritage contenant le coeur au niveau des gameObject au sein de unity et de leurs inter­connections. Amélioration du jeu “Roll A Ball” car beaucoup de principes à développer: ○ Repenser l'intérêt du jeu avec l’avis du patient (jeu plus rapide, moins sophistiqué que Heritage mais qui a pour but d’être plus addictif). Faire des essais pour tester la réactions des patients face au jeu. ○ Beaucoup de principe à implémenter dans roll a ball (faire plusieurs mode de jeux : plate­forme qui se réduit, obstacles qui peuvent ralentir, plate­forme qui bouge,...) ○ Faire une version Android, facile à transposer en un jeu smartphone car l’entrée clavier et la gestion sur smartphone a été homogénisée. 18 / 20 Projet d’approfondissement , Printemps 2016
○
○
Bonnivard Matthias Système de score motivant pour l’enfant avec un mode en ligne qui permettra de se mesurer à d’autres joueurs. Donner une identité visuelle au jeu par le biais de textures, animations, audio, niveaux... 6.2. Pour les Breathing Games plus généralement ●
●
Prendre le temps avec les spécialistes et les gens atteints de la maladie pour vraiment définir ce que pourrait être un breathing game productif pour le traitement mais qui soit à la fois addictif pour les jeunes patients. L’idée est de définir quelles paramètres sont vecteurs de divertissement tout en restant fidèles au traitement. Essai des jeux avec l’appareil d’exercice et en condition réelles avec le patient. Pour mieux se rendre compte des objectifs. 7. Conclusion En conclusion, on peut dire que l’idée générale qui ressort de tout ce travail est qu’il y a eu un gros travail de réflexion et d’analyse autour du concept de coeur. Beaucoup de points ont été modifié ou repensé tout au long de ce travail, surtout en ce qui concerne le coeur, malgré le travail restant. Finalement, un concept assez clair est ressorti de tout ça. L’objectif final d’avoir un asset sur Unity spécial pour les BG est un objectif très intéressant. De plus le prototype de jeu m’a permit de continuer mon apprentissage de Unity et surtout de remettre en question l’objectif du jeu pour BG, ce qui m’a amener à repenser les systèmes de jeu pour atteindre les objectifs liés aux exercices thérapeutiques. 8. Références ●
Wikipedia Mucoviscidose [Online] Available: https://fr.wikipedia.org/wiki/Mucoviscidose ●
Rapport Nicolas Wenk, “Serious Games pour la Mucoviscidose”, [Online] Available: http://breathinggames.net/sites/docs/breathinggames_net_2015_report_wenk.pdf ●
Unity Manual, [Online] Available : ​
http://docs.unity3d.com/Manual/index.html ●
Breathing Games [Online] Available : ​
http://breathinggames.net/?q=fr 19 / 20