Lee Wei Liang
Systems Designer | Programmer
Package 404
Made with Unity Engine(I do not own any of the assets used in the simulation)
Overview
Package 404 is a VR simulation where you deliver a package in the late night.
I successfully delivered Package 404 after 4 weeks with a part-time assistant as a self-pitched project during my internship at Keio-NUS CUTE Center.
Credits to the original owners for their art and audio assets (Detailed list is in the video and its description)
Roles & Responsibilities
Role: Project Manager, Programmer, Designer
Being the main developer/designer in the team, I had to deliver the package that contains:
-
A managed plan to deliver the product in several forms for each milestone.
-
Fitbit heart rate data export for usage in Unity to develop dynamic content.
-
An experience designed to fit with the concept of heart rate tracking.
-
BGM composition and SFX creation/modifications.
-
UI and asset integration.
Research Process
Overview
I was given the chance to develop on a personal project after proving my capabilities during the first 2 months of my internship, as Keio-NUS CUTE Center is research center for Interactive Digital Media which was different from the conventional games that I had produced in DigiPen, I had to research on developing a product that involved Virtual Reality (VR).
Initially I pitched 2 other projects besides Package 404 which included a full body gesture tracking to impact the behaviour of AI and tackling mental health issues in a VR world but the former was not viable due to the space constraints within the center and the latter was a topic that was too sensitive. A horror simulation that had dynamic content with a wearable caught the attention of my producer which was what earned the green light.
Researching on Fitbit
The documentation from fitbit gave me some directions as to the process of extracting data from its watches, I had learned to create a simple interface on it using html and css, with python to program the app on the watch. It was not easy to understand at first why I could not program an app on the watch itself to send data over to Unity and I had to go through a 4-step process.
-
Recording the heart rate data from the Device API in the Fitbit smartwatch and sending it to the Companion API on the smartphone app.
-
Configure the Companion API to listen to the Device API and receive data using its Messaging API.
-
Using the same Messaging API to send the data received from the smartwatch to the server.
-
Server sends data received to Unity.
After I ensured Unity receives the data, I then proceeded towards designing the systems in the simulation in Unity.
Initially I did my testing using the Fitbit Studio which is now deprecated and eventually ported my project over to its command-line SDK which runs on Node.js which made it easier as I could now do version control on the source files.
Post-Mortem
Package 404 was my first project done in VR using Oculus Rift together with Fitbit Sense. It was hard to develop this project at the start due to having multiple components to work with, as it is not simply developing a VR application with Unity. I had to take some time to research on how to extract the data and presenting it to my Producer before getting the green light.
This project had to be worked on top of the main project the company was handling, and when the workload of the main project went up, this project was put on hold for 2 months before resuming it. Thankfully I have good coding practices of leaving useful comments which made picking the project back up to speed did not take long.
Overall it was a fresh experience for me to work with external wearable for the first time and I can see potential for similar projects in terms of education and training sectors with data reading to better equip the user with the information of their performance.
Thank you for reading about my work on Package 404!
Design Process (Iteration 1)
Overview
Due to a constrained space in the center, I was advised to design something that allowed the user to sit and experience the simulation and I had to design a horror experience which the user sits down. I then wanted to design an experience that included movement to fit that theme but also remembered that movement easily causes motion sickness. Thus, I had to ensure that the user has a point of reference in their surrounding so their minds will perceive that their physical body is not moving and decided on placing the user in a truck driver's seat.
Experience design for heart rate
I placed emphasis on dialogue in order to build up fear before releasing scare elements so that I am able to control the amount of tension the user can experience; A branching path where the user will journey through based on their average heartbeat level.
What went wrong?
The heavy emphasis on dialogue meant that it requires the user to sit through the simulation for a longer period of roughly 10 minutes, however, due to limitations of time from the increased workload of the main project, I was requested to scope down the amount of content to be delivered.
What went right?
The scare elements still works as the main factor of increasing the user's heart rate.
Experience design for driving
I intended for the user to not have a smooth and pleasant driving experience by introducing bumpy roads which can cause the user to easily swerve and crash should they try to do heavy manoeuvres. I also designed the driving path to be narrow so that the user has more tension when facing the scare factors while concentrating on steering the truck.
What went wrong?
It was too hard and most users keep crashing where most of the users already crash before the scare factors.
What went right?
It increased the heart rate of the user which was intended.
I designed for 4 sets of interactions which included manually winding down windows, adjusting radio volume and switching on the lights to maintain sanity and visual based scare factors which the ghost inches closer each time the user looks away.
What went wrong?
Due to the tough driving conditions, most users ignored some of the scare factors as they were already overly invested in keeping the truck steady.
What went right?
For the users who managed to experience it, they said it was good but there were too many interaction types on top of the driving, and the winding of windows was impossible as they had to focus on the road, thus, I decided to cut down on the amount of interactions.
Experience design for interactions
Design Process (Iteration 2)
Experience design for heart rate
I relied more on lighting, audio cues and paced the scare factors so that the user will not be bored or feel too much tension with no rest. I used red lighting and flashing lighting and eerie sound effects to warn users of incoming scares. Each scare factor was also paced to have a range from 5 to 7 seconds to follow The Seven Second Rule to allow the users to process what has happened and what could potentially happen next.
What went wrong?
This time round, only a small percentage complained about the pacing being too intense.
What went right?
Some users liked how there are lighting cues and audio cues to present the scare factors and felt the shivers from them.
Experience design for driving
Due to the previous iteration being too harsh, I flattened and widened the roads and increased the allowance that allowed the users to have 4 times more leeway before being able to crash their truck.
What went wrong?
There remained a small percentage of the users who still complained that the driving was too hard.
What went right?
Most of the users are now able to drive and reach nearer to the end, the users who did not make it were due to being scared and distracted by the scare factors within the first few tries which is also the expected and intended result.
I made the action of winding the windows to simulate holding a button when the user's hands are near the window switch, changed the radio and light interaction to be automatic, and kept the ghost inching closer each time the user looks away.
What went wrong?
A small percentage of the users still felt that it was too tough, but slightly more manageable.
What went right?
Most of the users are able to enjoy the full experience from the reduced hassle and lesser amount of interactions distracting them.