Motivation

This project revolves around breaking some of the standard tropes of most role-playing games by breaking boundaries with VR technology. Similar to a “choose your own adventure” type of story,  the users will figure out that they can either kill the monster or find alternatives to progress.  You can click on the menu options and fight the monster like a standard turn-based RPG, or you can choose to walk outside of the boundaries of the fight and explore the area around you.  By leaving the fighting zone, the the player will notice that the environment  provides a ways to resolve confrontations without violence.  This may include manipulating the environment, finding items, or even discovering new words to add to the menu screen. Based on the gamer’s choices, they will find out that their actions affect the ending.  We ultimately want to place the user in a situation where they are given a choice.  We hope that the user ends up reflecting on personal morality, the consequences of violent actions, and the importance of thinking outside the box to solve problems.

Contributions

Mais worked on the entire storyboarding process making sure each point of the game makes sense and connects to each other. She created the blueprint of the game of how the player gets to point A which is the intro to point B which is the start of the game and point C which is the ending of the game. She also wrote the storyline to the game including the intro and backstory as well as creating the final endings of the game and how the user reaches each one. Mais also assisted in coming up with some of the puzzles including one that reached the final game. She was also responsible for the audio of the game including recording and editing the voices of Palapeli, the villain.

Skyler worked with Matt on the coding of the project.  He first white boarded and thought about the flow of execution throughout the game, and then thought about how to create objects and interactions that corresponded to the design of the game.  A majority of his time was spent getting objects to interact with each other, and even more so spent figuring out how to flow through the game.  For example, how after a completing a room/level we would transition to the next appropriate room/level.  Also focused time getting objects from different scenes and levels to interact with each other, which is much trickier than simply having an object interact with an object from the same level.  The jist of it, getting the code to work and run properly.  

Amarah worked with Matt on designing and developing both the intro and the ending levels of the game. Half of Amarah’s time was spent on creating the game environments within these scenes, including designing the terrains, working on some aspects of of character functionality, and gameplay music. The other half of Amarah’s time was spent working with Matt and Skyler on debugging issues after the initial game prototype had been completed, including making transitions through levels work, working on puzzle objects, and minor cutscene functionality issues.

Matt was the lead designer throughout the project and worked with the team throughout the project’s timeline to make sure the project came together.  He constructed the puzzle rooms, programmed the intractable menus, worked with script interactions, and ensured that the VR elements of the game worked (camera functions, grabbing and touching objects, UI pointers, etc).  He also was responsible for working with the imported characters and utilizing and manipulating their animations.

Outcomes

Our game starts off with the player being in front of Palapeli’s castle which is where the game starts. They are given a text story introduction that serves as the backstory to the game. After that, they enter the castle and find themselves in a room with a monster blocking the room. The player is given a choice to either attack the monster, defend or solve the puzzle. They are not explicitly told that they can solve the puzzle. We hope being in a VR environment encourages the player to look around their environment and discover that there is possibly another way to move on without fighting the monster. The defend option serves as a mean to communicate with the monster. The monster forfeits a hint which assists the player in solving the puzzle. The function is the same for all the rooms in the game. The ending is decided based on how the player goes through the different rooms. There are three possible endings and two of those endings also results in another choice for the player that involves choosing to save himself or his townspeople.

Overall, we were able to come up with a final product that has a beginning, the gameplay and the ending. We are very pleased with what we were able to accomplish with the limited time we had.

We are all very pleased with what we accomplished. There were some things that were frustrating such as figuring out certain scripts and figuring out how to program certain interactions. Although it was a time crunch, we are very satisfied that we came up with a full demo game.

Problems encountered

• Collisions  

This was confusing to figure out at first, but then we realized we needed collision boxes and rigid bodies to make objects behave like they would in a real room.

• Object Interaction

Using VRTK, we found scripts that allowed hands to interact with objects.  

• Figuring out load on level

Scene management was tricky, and it was difficult to manage which scripts to handle level loading, especially when we had different conditions for swapping levels.

• Attaching scripts to objects

Inheritance with unity objects was very confusing, but we progressively improved our ability to access components of a game object

• Transition from one scene to another
  • Fading the camera was a real pain and involved multiple steps especially because the VR method of fading in/out is much different than standard unity games.
• How do get thing to happen in relation to time

Using timers in Unity was not simple, for simple timer objects are not built into unity scripts.  We found workarounds in order to make actions execute after a certain amount of time, but it was not intuitive.

Next Steps

One of the things would be expanding on the introduction to the game and the endings. The intro would be fully fleshed out and not just text based. We’d have it so the user starts in front of the town, coming back from his mushroom collecting journey and explores the empty town. We’d have the player find a sole townsperson who is in hiding and explains to him what happened to the rest of the people then the player would go back into the forest and find the palace.

As for the endings, we’d create different cut scenes for the ending depending on the user choice rather than just having a “Game Over” screen after the choice is made. That way the ending doesn’t feel too abrupt and the user gets a feel for the choice they made.

Another thing would be adding more rooms. While three rooms was great for a demo, a game with that many rooms feels too short. We’d add more rooms with a different variety of puzzles.

Video of the Project in Action