Paradox Rift

Project header image

VR Design/Development Project

Team

  • John Ordoyo
  • Nick Sung
  • Aman Singh
  • Oscar Waizel

Roles

  • Project Lead
  • Level Designer
  • Game Designer
  • Developer

Tools

  • Unity
  • Procreate

Timeline

  • October 26 - December 14, 2023

Project Description

Paradox Rift is a mind-bending, time-bending VR puzzle game about time travel and portals, created in a little over a month for IAT 445 - Immersive Environments. You play as an explorer in the far future, entering a spaceship that has long been abandoned. A message plays:

"Hi. If you're hearing this, we're already dead."

Time rifts have started appearing throughout the ship, and it's up to you to use these time portals to make your way to the end of the ship and change its fate.

Project Video

Play Paradox Rift

Puzzle Concepts

We started the puzzle design by establishing the common puzzle elements that would be used throughout the game. As we had a very limited amount of time to design the puzzles, we decided to keep them to common puzzle elements found in other puzzle games like Portal 2 or The Talos Principle, and so we settled on cubes, pressure plates, moving platforms, and directable lasers, as well as our core puzzle mechanic of time portals and Cause and Effect.

The main idea behind Cause and Effect was inspired by time travel in fiction, and its implementation in the Portal 2 mod Portal Reloaded. Any object you move in the past would be moved to the same location in the future, but any object moved in the future would not affect the past. You would also be able to bring objects from the future back to the past, but not the other way around. Any attempts to do so would remove the future version of the object from existence, and you would have to bring it back to the past to bring it back. This was the main conceit of our game and every puzzle was designed around this central mechanic.

Implementing Mechanics

Due to the limited amount of time to develop this project, all of the core mechanics had to be developed quickly, and designed in a way to be reused and implemented into levels quickly.

One of the initial roadblocks we had was with the actual portals themselves. I had previously created a portal system in Unity for my project Neon Dreams, however the key issue was translating the portals into VR. As the method for making portals required rendering separate camera views onto two cameras instead of one in VR, for the sake of time we ultimately settled on using a Unity Asset Store package that had everything we needed for the project from the outset. This package was Portals for VR, and this saved us a lot of time.

The Portals for VR asset.

With the portals figured out, I focused on developing the rest of the mechanics. For Cause and Effect, the idea was to have any object you move in the past also move in the same way in the future. Because we were working in VR and had to make sure the game ran as smoothly as possible to ensure no motion sickness or frame drops while playing, I made the call to change the position of a cube only occur once when the past cube has changed its position, and it is touching the ground. This way we aren't making transform calls every single frame.

After detecting the transform change, the same transform is applied to the future version of the object, with an offset so that the mechanic works in any way we have the levels laid out, either side by side or one above the other. The future object is serialized so we can connect any two version of an object easily when adding them to the levels.

The Cause and Effect script applied to an object in Unity, showing the serialized variables to make easy changes within the editor.

For interactable objects, such as pressure plates or buttons, I use Unity's Event system to allow us to set which puzzle elements they affect within the editor, without requiring any dependencies in code.

The pressure plate script on a pressure plate prefab, showing Unity's events for when the pressure plate is toggled or not.

Then, on the puzzle elements affected, such as doors or moving platforms, I create public functions that are called by the Unity Event which then change certain states on the puzzle element, or add a trigger to it if the puzzle element requires multiple interactables to be toggled.

Functions called by interactable elements through Unity's Event system.

Puzzle Design

After establishing all the puzzle elements, I began sketching out levels and puzzle design. As we were limited in time, I designed 5 levels initially, with room to expand if we ever had more time to develop the game. I began by sketching out layouts of each puzzle. Two versions of the layouts, in fact, to represent the past and future versions of the puzzle layout. I sketched out the puzzle elements involved and the steps required to solve the puzzle.

The sketch for the game's fourth level, requiring the player to go back and forth in time to bring a single cube up a chain of elevators, before triggering the final central elevator at the bottom to reach the top.

Once the levels were all sketched out, I prototyped them in Unity by using primitive cubes to establish the layout.

The greybox prototype for the game's fourth level, with walls removed to reveal the internals. This layout was used to test the level design to make sure it was logical and solvable.

After we ran a test with members outside of our group using the level prototypes, we made changes to the level design to address areas of friction players were having, and then decorated the levels and implemented them fully for the final game.

A screenshot from the final version of the game, showing the level decoration, lighting, and models.

Other Considerations

Outside of the level design, there were other design problems we had to address. Namely, players were having trouble understanding what puzzle elements were being affected by things like pressure plates. To solve this, I added a laser that connects each puzzle element that interacts with one another. This simple change immediately made puzzles more understandable for players.

A screenshot of the puzzle indicator added to the game. Putting the cube on the pressure plate draws a line directly to the door, indicating that the pressure plate is affecting the door somehow.

Another issue we had was players getting confused about what time period they were in. During our testing, we had to directly tell them which time period they were in. While we wanted to decorate the future time period to be more ruined and decrepit, showing the passage of time, we had no time to do this, so we used highlight colours to indicate the difference. We used blue to represent the past, as it was safer and clean, and we used red for the future, to represent danger.

A level taking place in the past.
A level taking place in the future.

Takeaways

This was my first ever project in VR, and the amount of time we had was much shorter than I would usually have for a project of this scope. Nonetheless, I learned a lot about 3D and VR development that challenged me to push my skills in both game design and development. One thing I wish I had taken into consideration was making the systems more friendly for VR play. As it stands, the game was designed as if it was designed as a regular first person computer game, like Portal, however due to the differences in interaction styles in VR, the puzzle design may not have suited the platform as well as it could. The fact that you had to use the joystick to move also caused some motion sickness among some players. If I were to work on this project again, I would look to design puzzles better suited to VR.