green bar seperating the navigation from the content of the page
{back to skills}

(Oculus Escape - Overview)

cover photo for the game companion
Oculus Escape is an Oculus Rift demo made while a design intern with Bursting Brains. The demo was concepted and built in approximately six weeks with a team of 20. It was intended to promote the company's name at the 2013 Rooster Teeth Expo. I concepted and translated design ideas into diagrams and videos for the programming team, making sure they understood the demo's design and how it could possibly be implemented.

{Click here for the Bursting Brain's website}

Responsibilities: Design Implementation


(Sample Gameplay)

Oculus Escape - Object Permanence Mechanic from Nina Park on Vimeo.

The final result at the end of the six weeks. This video focuses on the object permanence mechanic I concepted and then communicated to the team.

(Explaining Using Visual Scripting)

Object Permanence Mechanic - Kismet Example from Nina Park on Vimeo.

In order to help the team better visualize the object permanence mechanic and how it could be implemented as puzzles in the game, I mocked up a potential puzzle using Kismet in UDK. Only by looking at a specific spot would the impeding wall disappear, allowing the player to jump through the hoop. Such videos helped not only the programmers, but the team overall, as everyone then understood our goal and could also help come up with obstacles for the player to encounter.

(Design Explanation Diagrams)

Above is an internal "cheat sheet" for the object permanence mechanic. It detailed the basics of the mechanic and the implementation goals for each department. Such diagrams not only helped the team to understand the design, but also sometimes sparked ideas between them on how the design could be implemented.


The above diagram showcases how the movement of the player could be executed. Players were to entirely control movement via the head tracking of the Oculus, and our goal was to give movement a very free and fluid feel.

If our programmers had an issue understanding a mechanic or how it could be implemented, I would discuss with the rest of the team the best course of action and then draw up diagrams to communicate the agreed upon decision. Having notes and diagrams that were easy to access tended to reduce confusion and stress on the programmers as there was always a file they could refer back to for help.


Another one of my responsibilities was giving feedback to the programming team. The above diagram shows the feedback on the player's collision in the demo. In these feedback notes, I would outline to the programmers the current implementation and then compare it to the desired implementation.



back to top