![\"cool-text-palapelis-palace-220832326750108\"](\"http:\/\/blogs.discovery.wisc.edu\/vr2016\/files\/2016\/12\/Cool-Text-Palapelis-Palace-220832326750108-300x155.png\")
<\/p>\n<\/p>\n
Motivation<\/span><\/p>\n <\/p>\n This project revolves around breaking some of the standard tropes of most role-playing games by breaking boundaries with VR technology. Similar to a \u201cchoose your own adventure\u201d type of story, \u00a0the users will figure out that they can either kill the monster or find alternatives to progress. \u00a0You 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. \u00a0By leaving the fighting zone, the the player will notice that the environment \u00a0provides a ways to resolve confrontations without violence. \u00a0This may include manipulating the environment, finding items, or even discovering new words to add to the menu screen. Based on the gamer\u2019s choices, they will find out that their actions affect the ending. \u00a0We ultimately want to place the user in a situation where they are given a choice. \u00a0We 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.<\/span><\/p>\n Contributions<\/span><\/p>\n <\/p>\n 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. <\/span><\/p>\n <\/p>\n Skyler worked with Matt on the coding of the project. \u00a0He 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. \u00a0A 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. \u00a0For example, how after a completing a room\/level we would transition to the next appropriate room\/level. \u00a0Also 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. \u00a0The jist of it, getting the code to work and run properly. \u00a0<\/span><\/p>\n Amarah worked with Matt on designing and developing both the intro and the ending levels of the game. Half of Amarah\u2019s 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\u2019s 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.<\/span><\/p>\n <\/p>\n 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. \u00a0He 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). \u00a0He also was responsible for working with the imported characters and utilizing and manipulating their animations.<\/span><\/p>\n Outcomes<\/span><\/p>\n Our game starts off with the player being in front of Palapeli\u2019s 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. <\/span><\/p>\n <\/p>\n 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. <\/span><\/p>\n 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. <\/span><\/p>\n Problems encountered<\/span><\/p>\n <\/p>\n 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.<\/span><\/p>\n Using VRTK, we found scripts that allowed hands to interact with objects. \u00a0<\/span><\/p>\n 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.<\/span><\/p>\n Inheritance with unity objects was very confusing, but we progressively improved our ability to access components of a game object<\/span><\/p>\n Using timers in Unity was not simple, for simple timer objects are not built into unity scripts. \u00a0We found workarounds in order to make actions execute after a certain amount of time, but it was not intuitive.<\/span><\/p>\n <\/p>\n Next Steps<\/span><\/p>\n <\/p>\n 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\u2019d have it so the user starts in front of the town, coming back from his mushroom collecting journey and explores the empty town. We\u2019d 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. <\/span><\/p>\n As for the endings, we\u2019d create different cut scenes for the ending depending on the user choice rather than just having a \u201cGame Over\u201d screen after the choice is made. That way the ending doesn\u2019t feel too abrupt and the user gets a feel for the choice they made. <\/span><\/p>\n 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\u2019d add more rooms with a different variety of puzzles.<\/span><\/p>\n Video of the Project in Action<\/span><\/p>\n\n
\n
\n
\n
\n
\n