Weekly Blog for CSCI 538 Spring 2019

Progress

This week we solidified our game idea and created the first iteration of our design document. Additionally, we partitioned roles for the following sprint. During our second meeting we confirmed that our project was technically sound by rendering a VR camera and a static camera at the same time on the same computer. Additionally, we set up the beginning of our environment and made sure that everyone could develop independently in the same environment. With these logistics taken care of, we spent time familiarizing ourselves with the Unity set up and how each person could best impact the project. With the work divided we left to develop independently.

Next Steps

We aim to have a demo of most of our game's mechanics done by the end of our first 2-week sprint. These include having a VR player who can walk and pick up objects, a guard that can know when it has spotted the VR player, and a screen layout for the computer display that can see the VR player from a separate camera.

Progress

This week we merged together all the pieces we had individually worked on to create our first demo. This demo serves as a proof of concept and example of the main mechanic of our game: Using the security cameras outside of VR to tell the person in VR how to avoid the guards. The demo is a simple progression where the player moves down the hall and has to avoid two guards while the people outside VR must switch between 3 security cameras to guide the player.

Challenges

We had some trouble with handling how the colliders should work for the player. Since it is crucial that the player cannot go through or see through walls we decided to make the entire play area collide with walls forcing the player to move inside the play area to get closer to the edge of walls. This comes with a trade-off however because the player can now not move through tight spaces as the large play area prevents them. We will explore different options to solve this problem without letting the player go through walls and keeping the feel as natural as possible.

Additionally, the guards currently rely on hard coded paths. This makes increasing the number of guards unsustainable. To solve this we are looking into using a serialized list of points that we can edit in the editor that the guard will then walk between. With this increased flexibility we will be able to scale the number of guards much faster.

When playing our demo we ran into issues of play style such as how fast the guards and player should move and what should constitute a guard "seeing" the player. These parameters will continue to get tweaked as we progress and have more gameplay and mechanics to test.

Next Steps

We are working to add the door mechanic to our game using a key card or terminal commands to unlock certain doors. This will allow the player to have side objectives such as finding the keys needed or the codes that need to be typed into the terminal to progress and open certain doors.

We originally were going to use very low poly assets to prevent performance issues when rendering both the VR camera and the security cameras, but with our new design only rendering one camera other than the VR camera at a time we should be able to use a more detailed asset pack. Rending on camera at a time will also make the players outside of VR have to be more interactive.

Feedback

We had our first meeting with the professors this past week. We presented our demo and discussed which assets we should use in our project. After showing them 3 different package themes, we decided on the most realistic looking option. Since these assets are higher quality, there could be a performance cost. We will have to test the new asset pack to make sure that the game runs smoothly.

We also received feedback from our demo. The main advice was to vary the games mechanics and to not to rely as heavily on the avoiding guard portion. Instead, the professors suggested we create 3 different levels that all provide unique gameplay. This advice was also aimed to help us prevent the performance issues as we could split up the levels into different scenes that could be loaded separately. We came up with 3 different levels: breaking out of the cell, getting past the guards, and avoiding lasers. The player would progress through these sequentially giving them more variety of game play. Other smaller suggestions were focusing on making a smaller prison and a way of preventing the VR player from getting motion-sick as they navigate the prison.

Progress

We then discussed this advice and solidified our game design and rewrote our design document to reflect the changes. The player will start inside the cell and will have to work with the hacker to complete some mini-puzzles to escape the cell. They will then have to navigate past a few guards using the mechanic we finished in our first demo. Lastly the VR will have to work with the hacker to avoid lasers that only the hacker can see though the security cameras.

While we planned the cell puzzles more thoroughly, we will have to wait to hone the other two level's gameplay because they require more in-game testing. We need to actually be able to play the level in order to gauge the difficulty and then adjust accordingly. We also decided to have the players auto-save their progress after each section since it would be tedious to solve the same puzzles over and over again.

Next Steps

With this new level break down, we split up work based on the levels and are working towards a complete level by the midterm presentation. This level will be shorter than our final product, but will contain the main elements so that we can receive as much feedback as possible.

Challenges

An interesting issue we are still working on is the handling of walking into walls. While seemingly simple there are multiple considerations. For our purposes, it is extremely important to not have the player be able to walk through walls or see through walls. We thought about having the player's body collide with the walls while allowing their head to pass through. Then if their head passed through a script would have their vision fade to black. We decided against this approach and instead have the player be pushed back if they try to move their head into the wall. We chose this approach over having your vision suddenly turn to black as that would be more jarring for the player and bring them out of the game.

Progress

We now have all 3 levels built with each of their respective gameplay. The cell has two puzzles that need to be solved in order to escape. One involves the prisoner finding hidden letters around the cell and telling them to the hacker who uses it to activate the button panel. Then the user must describe the buttons so the hacker can look up what the code is for that situation. Once out of the cell, we have the guard level where we use the mechanic from last time which is the prisoner avoiding guards with the help of the hacker. Lastly, we have a laser hallway where the prisoner just sees an empty hallway, but the hacker sees the lasers in the security cameras. The hacker must instruct the prisoner how to move to escape without being caught by the lasers.

Feedback

After demoing our project, we received some positive feedback on the new look and gameplay. In order to make it more immersive, the professor suggested adding more ambient noise. This will be an interesting challenge as the main part of the game is communication so we cannot have the sound hinder that part of the game. It was also suggested that we focus on completing the gameplay loop (linking all of the scenes) so we can have players test the game.

Next Steps

Although we now have the building blocks, we need to polish the gameplay and link the levels into a cohesive flow. We also need to add sounds and the player and guard models to the game. Lastly, we create a video from our current game play for the midterm presentation.

Challenges

We have been having issues with controlling the VR player. We are working to figure out if these issues are due to tracking problems or errors in our code. As we are looking to add the prisoner model to the VR game we need to also use position estimation as the hacker player will be able to see that model. The challenge is that there are only 3 points, the head and two hands, to use to estimate the position.

Logistics Update

After classes were moved to online, our project plan had to be reevaluated. We decided to continue our development leveraging the three headsets that our team could use while working remotely. We have moved our weekly meetings online and are using more online progress tracking tools such as trello to keep the team on task. We have limited our scope of work to polishing the current game play and developing features that are effective without being incredibly work intensive.

Progress

We have created a new production plan and have spent the past week working remotely. While this has been more difficult than our in person meetings, we are improving as a team. We have added a panel that hides the buttons in the cell as well as additional lasers to the laser scene making the gameplay more dynamic. We have also fixed the scaling issue in the cell.

Next Steps

We will continue by adding sounds, a way for the hacker to pause guards and our first game build to ensure playability.

Challenges

A major challenge will be continuing to work remotely. This has also led to more merge conflicts making it even more important than before to break the work down into parts that can be developed independently.

Progress

Cell Level: We have removed the lights and hidden the letters around the room. With the lights-off the user now has to use the lamp to explore their surroundings. Additionally, we hid the buttons behind a panel and they can only be revealed when the password is entered correctly. We rebuilt the cell scene so the bed can be separated from the mattress allowing us to hide one of the letters below the mattress. All of these changes make the cell level more difficult and engaging.

Laser Level: We have added more lasers that increase in difficulty as the player progresses throughout the level. The lasers near the end of the hallway also move adding a new dynamic and increasing the difficulty. We have also added sounds to the lasers so the VR player can hear when they are close to a laser. They still need to rely on the hacker but this gives them a sense of danger.

Overall: We have fixed our level transitions and loss mechanic to make the game playable. We have also mitigated the issue of motion sickness by having the players FOV lowered as they move.

Challenges

We have had many merge conflicts in scene layout with different people working on the same scene. To solve this we have better divided the tasks so that now two teams are working on the same scene. These conflicts have slowed progress as we have had to redo some of our improvements after they were lost. We are looking into using unity collab and limiting those developing to 3 computers while the rest pair program. We believe this will reduce our merge conflicts and speed up production.

Next Steps

We plan to build our project and get feedback from the professor when he plays through it. We are also implementing a timer that the hacker and VR player can see to give the levels a sense of urgency. We are also fixing any bugs that hurt game play such as collider issues or missing objects.

Progress

This week we fixed more bugs that had happened during merges and that were discovered throughout the game play. We added a watch mechanic to the VR player that allows them to see the timer that the hacker sees. We have improved the game flow and fixed issues with the level transitions and losing mechanics. For example when the VR player hits a laser they are respawn at the beginning of the laser level and their watch lets them know how they died. We also added guard models to the guard prefabs and fully implemented the guard pausing mechanic. Lastly, we created a skybox that the user enters after they complete the demo to add finality to our demo.

Challenges

We had some trouble with the collider for the VR player so that they lose when a guard sees them or a laser hits their body.

Next Steps

We are putting the finishing touches on the game. We will test playthroughs and tweak the guard level and laser level difficulty. Additionally, we will also sync the hacker and player timer so that when the time runs out the player respawns at the beginning of their current level. We will also be playing through the game to find and fix any bugs that we find to improve the demo experience.

Progress

After meeting with the professor for the last time, we implemented the changes suggested. We fixed the lighting throughout the game making the scenes other than thee cell scene darker to match the cell scenes aesthetic. We fixed the hacker UI making all the mini-maps consistent. We also synced the hacker and VR player’s timer so they count down at the same speed.

Using Final IK, we were able to apply the prisoner model to the VR player making it look more realistic for the hacker players as they can now see a player model through their cameras. Since this game is a demo we have added a game menu that allows the players to skip to any level in case they want to test a specific level and do not want to go through the entire game. In this menu we also display the cause of losing (i.e. a guard caught you or a laser hit you) or a welcome message.

We also collected and created the materials for the final deliverable such as the website, trailer, documents and walkthrough.

Challenges

The final IK has many parameters that need to be adjusted in order to get the most accurate player tracking making it difficult to get the most accurate tracking possible.

Next Steps

For the game, we will run though the game play to ensure playability and improve the Final IK implementation. We will also finish the requirements for the final deliverable and submit them.

This semester was a great experience and learning experience for the entire team. While not many of us had prior experience in VR, we were able to create a playable and interesting game that uses both the VR headset and the computer. From this experience there are some takeaways both of things we did well and things we could have done better.

Challenges

While at the beginning we began with a well divided work structure for the team, this became degreated as the semester went on and each of beagan to work on things outside of our particular area. While this was great in some ways, allowing us to get experience working in multiple areas, it proved difficult after we began working remote. With everyone working on multiple pieces of the project, there were many merge conflicts that in some cases erased our previous work. It may have been beneficial to switch to Unity Collab as soon as we began working remotely instead of stiking with Github. WHile this would have limited the developers as only 3 people can be on the colab at once, we only had 3 people with headsets at home.

Successes

We were able to pick up Unity fairly quickly and had a working proof of concept after the first sprint. Additionally, we pivoted many times and were able to change the direction of the game quickly. We began as a heist game and then switched to the jailbreak theme. At first we thought the whole game would be avoiding guards however we were able to take the professors feedback and pivot our game to include many more mechanics making it much more enjoyable to play.