Varises VR Surgical Simulator

Surgeon training meets virtual reality

Varises is a simulation meant to be a training tool for potential surgeons. It teaches about and runs them through a distal femur resection. Varises was a client project that I worked on during my time at the Emergent Media Center. It was a demo that was used to pitch the idea and get funding; it was successful and is now in its next phase of development at an independent studio.

Intent:

Our goal was to replicate the experience of a real surgery while utilizing the teaching methodologies found in modern video games. This meant researching the surgery, evaluating through testimonials which parts we needed to hone in on, and creating a user experience that made heavy use of interfaces while making sure the player wasn't distracted from the task at hand.

Contributions:

I was primarily the UX designer so I laid out the experience step by step, created the UI, and implemented many of the core systems. By this I mean I entirely refactored the collision system so that the jig wouldn't snap into place but rather could be slid into position and repeatedly adjusted similar to an actual surgery. I also utilized a scripted event framework created by our programmer to call different actions as the player progressed such as UI changes, animations, tooltips, playing sounds, etc. Once each of these were ready I conducted smoke tests with other developers to evaluate their functionality and then presented them to the project adviser and client.

 

Varises was somewhat of a work in progress before I got there. Initially, we were going to build off of the old project but decided to scrap it and build from the ground up. We still used a similar framework but needed to adjust it to work with VRTK (VR tool kit). As such I worked hand in hand with our programmer to rebuild and reprogram everything. Beyond that I also modeled some of the missing tools, created animations, and made lighting adjustments. We didn't have an artist on the team so we were working with old assets that needed to be altered. The other thing I did was create a tutorial area, and make two different modes; training and surgeon mode.

Walkthrough

After spending the first three weeks refactoring the project and getting it to work with VRTK I focused on getting the basics functional. One of the first steps for the player is picking up and using the jigs so I needed to make sure this was clear to the player. Not just any player I had to make sure this made sense to people who had never used VR and possibly never played a video game in their life. To do this I used three things; an emissive circle highlighting the object, a tooltip telling them what the object is, and a transparent controller that is animated and shows them what button to use as well as how close they need to be. 

Jig Placement Indicator

Once the player picks up the jig it needed to be visually indicated where to place it. To show this I created a transparent version of the jig and placed it at the proper location. This changes color based on the proximity of the jig and only shows up in the tutorial and training mode. In surgeon mode most of the indicators are turned off as it is meant to test the player's knowledge of the process.

Surgical Details

To more closely replicate reality, I used an iView model (think of a moving tablet stand) and had it show procedural details. I was able to get an actual surgical outline from our client, but had to split it up into sections and resize it as the diagram didn't fit the dimensions we needed and distorted the text. It isn't required for the player to look at to complete the process but they'll notice it is almost necessary to use it in surgeon mode to ensure that they have the correct placement.

Monitor Utilization Part 1

At this point I started to play around with different UI set ups. My first inclination was to have the iView to the left and then two monitors angled towards the player on the right. This way I could have one screen show the instructions and the other could show the accuracy as well as surgical tips.

Monitor Utilization Part 2

During testing this was having issues. Players often wouldn't look at the rightmost screen as it was generally only in their peripheral vision. This meant they were missing out on what they needed to do. To fix this I condensed the information onto one screen  and oriented it so it was always in the player's view. I also split out the step list to make it more digestible.

Finishing Touches

Once I had figured out how to convey the information I went through the process of attaching it to the scripted events. In doing so I realized that there was a weird empty space in between the iView and the monitor. To fill this gap I created a panel that would slide out on each step and display surgical tips. I also put an exclamation symbol above it to draw attention. Once this was set I created a button that would appear once the player had done enough to complete a step. This meant that they could re-position the jig or continue sawing until they had decided to move on.

Tutorial Creation

With the UI pretty squared away and the rest of the systems complete I needed to make a tutorial to teach the general controls. I decided that for the tutorial it should seem less realistic so that the players wouldn't associate the tutorial with the training they were receiving. As such I created a holographic material for the leg and changed the area to only have one point of focus. As the player went through the tutorial new elements would be added in, thus building off their pre-existing knowledge. 

With that said and done we presented the final product to the clients who were ecstatic about the end result. They said that the experience felt incredibly intuitive and easy to pick up and that we had gotten the demo to the point where it felt like actual surgery. Both of those had been key points in what they had asked for at the beginning of the project so it was great to hear!

Takeaways:

-Research is critical when it comes to delivery and execution

-UX requires constant testing otherwise you can end up making assumptions that slow the process of iteration 

-The bigger the toolkit is the harder the learning curve will be but that it is also generally more powerful and allows for more possibilities

 

-Communicate with and get feedback from clients and advisers as often as possible. Their input is almost always useful.

-Having to learn something on the job can be difficult but as long as you give yourself adequate time to do so and ask plenty of questions it can go really smoothly.

Champlain College Alumni

© 2019. Proudly created with Wix.com

  • Twitter Clean Grey
  • LinkedIn Clean Grey