During 9 month, we worked with DOWiNO and the Paris Descartes University on a medical serious game.
Effic’asthme is available both on the Play store ( https://play.google.com/store/apps/details?id=fr.parisdescartes.efficasthme ) and the App store ( https://itunes.apple.com/fr/app/efficasthme/id1400814236?mt=8 ).
The app targets parents of children suffering from asthma to help them face asthma attacks. The app is based on and supported by a thesis of a PhD student in health David DRUMMOND. (Link to the thesis – in French )
Effic’asthme provides : a digital action planning to deal with asthma attacks, a small encyclopedia on asthma attacks, a diary, and a simulator with realistic medical behaviors and a screen debriefing the event.
In the rest of the article, I will explain the most important parts of Effic’asthme : the simulator.
Simulator part
The simulator combines 3 elements : a child’s medical state, a medical logic and a scenario manager.
Child state
The child state is obviously the state of the child in the simulator. It contain the medical status of the child (temperature, cough, abnormal breathing, …).
At the beginning of the simulation, it is configured by the Scenario manager. After, it will be affected by the Medical logic, and in particular cases by the Scenario manager.
The child state control the 3D character models (animation & shader) to show the health information.
Scenario Manager
The scenario manager is the scenario part of the simulator. It initializes the simulation, gives a context, and can modify the simulation based on the scenario.
A scenario is a ScriptableObject for persistence. The data structure of a scenario is represented below.
This manager also records all actions and simulator events. It with this log the manager can know where we are on the scenario (scenario steps), and trigger modification on the simulation (scenario action).
The manager and his log are the corner stone between the simulation and the debriefing.
Medical Logic
This part is relatively simple. One action is made, a consequence is apply and the event (action and his consequence) is record in the Scenario Manager log.
The medical logic use the Child State and medical information of the child (weight, medical planning, …) to determine the consequence of a action. It can be Good, No effect, or Bad. The consequences are applies on the Child State.
Some action, like medical spray, require more interaction than just clicking on a button. It’s also the medical logic (particularly a sub module for each medicine) which manage the manipulation system and send the manipulation events. By following the medical protocol and the user interaction (fingers movement, 3D trigger), the system can report the good and bad manipulations.
You can see below a scheme of the simulator integration.
When the user wish to stop or the scenario stop the simulation (Time out), the simulator close and the debriefing start.
Debriefing Part
The debriefing is compose of 2 aspects : the diary log and the dynamic correction.
Debriefing Diary
The diary capture the Scenario Manager to read the initial state of the simulation, the scenario and the log.
It will compare the scenario and the log to determine if you have correctly deal the situation (done all the scenario and made no big mistake). Then it will read each entry of the log, see the consequences, to determine the action result : Good, Partially good (good consequences, bad manipulation), or if the health state was Worst after that. It will also look the scenario to check if the action was Badly Timed. Some extra information will be provide depending of the action result.
In most of scenario some actions like Give the emergency medicine are mandatory. When the simulation log reading is finished, we verify if these mandatory actions was performed. In the case they weren’t, new display entries are added to warn the user of their mistakes.
To conclude, the debriefing will assign a score on this session. On each entry display previously, the system will compute associate points. It depending of the action result and a table given by the game designers. Furthermore, some action not performed will give or cost points depending of the scenario.
A mark will be give on the advance you made in the current scenario. If you have a poor mark (< 50%), the debriefing will propose you to play the dynamic correction of the scenario.
Dynamic Correction
The dynamic corrector is a guided version of a scenario. It is a extra layer module on the simulator.
A first screen display the current medical state of the child. Each asthma symptoms are checked and a medical report is made with the attack gravity.
If the child state change during the simulation, this screen will be call again.
Then the simulation launched and the dynamic correction controlled the UI and some interactions to guide the user.
Based on the needed actions, the dynamic correction will composed a parallel scenario with scripted pattern block.
Each scripted pattern block are manually designed. They have a queue (sequence list) of simulation events and reactions (modify UI, limit user interaction, send simulator request). The simulation event sequences are designed to follow the events send by the simulator.
The dynamic corrector follow his scenario (queue of scripted pattern block). For each event send by the simulator corresponding with the current scripted pattern, the linked reaction is apply. When all events in the scripted pattern are triggers, the next scripted pattern is selected.
When all scripted pattern in the scenario are consumed, the dynamic correction end.
A descriptive schematic of the dynamic correction is available bellow.
Particularity & Challenge :
Localization
Effic’asthme will be use, at least, in two languages : French and English. To make localization easier, we use a plugin call I2Loc. We could localize texts, sounds, images and also videos.
The useful feature in I2Loc is the google sheet provider. Instead of had a .csv or .xml file, the plugin will use a google sheet in a google drive. So the translation can be done during or further the development, without any modification in the build. The refresh period can be modify according to needs.
A localization term (text, image, sound , …) is identify by a string id. To make more usable, we implemented enums and static readonly dictionaries. Like this, we can centralize string ids and avoid bad naming call.
3D animations
This is a important part of the project cause of the realism needed. Because of the artistic process, we decided to use point cache animations.
Cache animations are animations like blend shape but they are separate from the 3d model. So the animation software capture the vertex on an area of the model and sample their positions periodically. After, this samples are write in a file, a .mdd in that case.
Like this the artists can make the animations and release them gradually without the previous ones and the model. On the other hand, depending on the vertex number and the sampling frequency, the animation files can be super heavy. This can be a problem for mobile application.
Unity can’t read this type of animation, so we use a plugin which read them, MegaFiers. MegaFiers modify the mesh geometry with the instruction of the .mdd and some extrapolation.
The animations are play in multiple scripts attach to the GameObject with the mesh. For more convenient usages, I prefer to link this scripts to the animation controller by animation clips. It work very well excepting for the animation blending.
Our animation cover all the child body and some artifacts appear when blend are apply. Some vertex go away depending on their positions on the animations. By iterations, I found that blending on the beginning of animations was the most stable part.
This type of animation give more flexibility to the artists, whereas is more difficult to programmers to integrate it and it can be super heavy.