Tracheostomy & Laryngectomy Care: VR Curriculum
Gameplay / Systems Programmer
Embedded Files
stomaGameplay.mp4Tracheostomy & Laryngectomy Care: VR Curriculum was a project made over the summer in collaboration with Michigan State’s Speech Pathologist Department. This project was developed to assist incoming Speech Pathologists and simulate a check-up visit following a patient’s surgery. The application also included a VR on-boarding module for those new to the hardware.
I contributed to this project over the course of 4 months, building on and refactoring existing systems from the last iteration of the project. It is currently being used to train speech pathologists at Michigan State University in patient care post-surgery.
Programming Responsibilities
Tutorial / On-boarding Responsibilities
• My initial task in the project was to create the tutorial sequence. This involved teaching players the very basics of VR, so we careful designed each sequence of the tutorial to get players adjusted to the hardware.
• The tutorial asks players to look in all directions, to get a sense of the space. Users are then asked to click and point at a teleport point, which we use throughout the entire simulation to traverse the levels. We decided on this method of movement to prevent players from clipping out of bounds.
• The tutorial then asks players to place different shapes on the correctly colored pedestals. This section, although simple programmatically, require a lot of rework to make sure it met our client’s accessibility needs, and was intuitive for users who had never used VR before.
• Lastly, we wanted to teach users how to access the teleport menu to ease traveling around in the patient levels. We devised a section of the tutorial with some sort of wall (which became the blue-ish force fields featured in the images) to impel users to use the menu. We also wanted users to be aware they could teleport while holding an object, so the final section of the tutorial forces users to hold a key needed to unlock a door while interacting with a teleport point.
Mini-Game Design / Implementation
Build It! Mini-game
• For this mini-game, we wanted to familiarize users with the neck area they would be typically working with in their field, and allow users to manipulate the pieces of the throat to learn more about it.
• The mini-game asks users to assemble different pieces of the throat and neck area, and then piece them into their correct positions.
• Programmatically, the mini-game involves an invisible version of the model sitting in the center of the pedestal. If an individual piece hits the trigger collider of it’s invisible counterpart, the piece will lerp into place. Once all pieces are noted to be in place, the puzzle will move onto the next section and repeat the process.
Sorting Tools Mini-Game
• For this mini-game, instead of familiarizing the users with the operation area, we wanted to acquaint them with the tools used for this procedure. Allowing user’s to get their hands on the tools was our favorite approach.
• The mini-game drops various tools associated with the different procedures (a Tracheostomy and Laryngectomy) and sort them into their respective bins. Users are given a points for sorting correctly, and lose points otherwise. Users are also under a time limit to give the mini-game an end-point.
• Programmatically, the tools themselves are tagged either as a Tracheostomy tool or a Laryngectomy tool. Once placed into the bin’s collider, if the tag matches the bin’s tag, the user gains points. Otherwise, they lose points. We had quite a few bugs with the object being destroyed while the user was holding it, and so we included checks to make sure the object was no longer being held before it was destroyed.
Airway Mini-Game
• For this mini-game, we wanted users to understand how the airflow through the body changes after a Tracheostomy or Laryngectomy, as this is vital to understanding how residue can build up around a patient’s stoma.
• The mini-game shows users various empty boxes on a diagram of a throat, and asks them to place arrows facing the direction of the airflow. Users must then press a button to check all the arrows, and the arrows will turn green if correct. Otherwise, the arrows turn white and must be rotated.
• Programmatically, the arrows attach to each trigger, and a manager has a reference of each trigger. Once the button to check the arrows is pressed, the manager goes through each trigger and attached arrow, and compares the angle of each arrow to what the angle should be. If it is correct, we change the material to indicate that. Otherwise, we still change the material, but to a different color.
Project & General Responsibilities
Clipboard UI System
• Near the end of this project, we found ourselves in need of a new UI system for our patient levels. The original UI was a default Unity canvas, that was stuck to certain parts of the level.
• I created the clipboard UI featured here, which features all the menus we originally had compressed into a mobile format. If the player gets too far from the clipboard, it will teleport to a default position in front of the player.
• By keeping the fail-safe teleport distance larger than the distance between teleport points, users could re-position the clipboard wherever they need at each teleport point based on what task they’re performing.
• The clipboard UI features a main objective screen, a checklist to see all of the level steps, an option to enter an email for feedback, and a pause menu, all of which I fixed and set up from the previous iteration.
Main Menu / Level Selection Screens
• I created a simple Main Menu scene to give the player a moment before jumping directly into the action.
• Because we don't allow the player to turn manually (to prevent loss of direction and motion sickness) I developed this simple system to force the menu to rotate towards the player at all times.
General Bug Fixing / Optimizations
• As this project was ongoing when I joined, many of my responsibilities involved working with previously established code. On numerous occasions, I re-factored or remastered systems in the game so we could build new systems on top of them.
• Near the end of this project, I actually had the opportunity to tackle some of our optimization issues alongside my teammates. We delved into previously established systems and optimized meshes, scripts, materials, and more to get the framerate consistent for the Quest 2.
Page updated
Google Sites
Report abuse