PRD

PROJECT BLOG
WEEK 1

This week, each member has been working on WebXR demo projects to familiarize themselves with the tools for the main project, as well as working on the website and discussing project ideas. We created a document of what our project should include in terms of the environment, controls, objectives, tasks, stretch goals, and bottlenecks which we will refine in class. In class, we went through various tutorials to familiarize ourselves with WebXR and VR programming. We also started the code for our website and worked individually on the WebXR tutorials.

Our idea for the project is to create a VR experience in space where a player can move around in different gravitational fields and complete tasks to fix a space station. The player would work through a set of tasks while moving around the inside and outside of the space station. The basic storyline is that an astronaut has woken up to find their spaceship critically damaged, there is a list of tasks that must be completed to remove risks, fix the space station, and establish communication with the team on Earth to send aid.

Next week we will come up with a project pitch and create our Project Requirements Document (PRD).

As for blocking issues, we are wondering what the best way is to obtain 3D models that will be consistent with each other as we build our scenes.

WEEK 2

The following is what each team member accomplished this week:

  • Caelen worked on the pitch slideshow as well as the Project Requirements Document.

  • Devika worked on the pitch slideshow as well as the Project Requirements Document.

  • Elana worked on the pitch slideshow as well as interactions between players and objects for the demo application.

  • Timo worked on the pitch slideshow as well as the multiplayer platform through croquet for the demo application.

As far as progress on our project, we built a demo application using Croquet to create a multiplayer experience where two players can interact with a ball in a space station corridor. Players can also click a button to rotate the entire corridor. Our code can be found on our GitHub repo here. Additionally, we created our Project Requirements Document, which can be viewed here.

We also ironed out more of the goals of the game this week: we want to make a two-player cooperative game set on a broken down space station! Our two characters will be a human and a robot that must work together to fix the space station and find help. We have some new ideas for the tasks they must complete. We aim to have tutorial areas for both players where they can try out their special abilities like computer hacking or picking up and resizing items, which requires communication to leave, followed by a task to repair a generator utilizing wiring skills and flashlights.

Next week we will be focusing on building out the MVP for our game, starting with our environment, which we will be getting from the Unity Asset store once our budget is approved. We also plan on building out our initial tasks for each player. Each team member will be focused on their specific area of specialization: Caelen will be building out the environment, Devika will focus on in-game objectives, Elana will improve the player movements and controls, and Timo will continue working on the multiplayer capabilities and networking.

As for blocking issues, our animated corridor does not seem to work when two players are in the scene. When one of the players clicks the button to rotate the corridor, it starts the animation, but then stops and returns the corridor to its original position for some reason. We’re not really sure why it only does this when there are multiple players in a scene. Additionally, when two players are in the scene, the ball appears to flash between two locations for both players after it is moved from its original location.

WEEK 3

The following is what each team member accomplished this week:

  • Caelen worked on acquiring a 3D model of the space station interior, and editing it in Blender to fit our specifications and narrative.

  • Devika worked on creating one of the initial interactions for the “robot” player, which is clear fallen debris with the robot’s ability to move objects at a range with raycasting (similar to “the force”). So far, we have blocks that can be raycasted to, but we are still working on being able to make it grabbable at the same distance so it can be moved in that range.

  • Elana created one of the initial interactions for the “human” player, which is to seal a hole where air is leaking out. So far, we have a cylinder (which will later be the Spray Sealer™) that shoots out spheres (representing the sealer) when you grab it.

  • Timo worked on creating and alternating character models for players when connecting.

We’re moving our codebase from Glitch to GitHub! Our code can be found here: UWRealityLab/xrcapstone21sp-team3 (github.com)

Our biggest update is that we have an initial map layout! We planned out the introductory areas for our brave astronaut and robot characters, and have tasks planned to fill out those areas. One idea we’re excited about on the human side is an air leak that must be fixed using a Spray Sealer™ (similar to a fire extinguisher). On the robot side of things, we will soon be seeing a telekinetic power to move debris out of the way so the robot can clear the way to a computer terminal.

We will continue to work towards getting our minimum viable product, which will be done by May 4th. Next week, we will be focusing on building out more of the intro sequence. Caelen will be focused on implementing models into our current environment and creating the robot’s terminal screen, Devika will continue building initial objectives and interactions for the players, Elana will work to enable physics for the player characters as well as help implement interactions, and Timo will work on implementing specific controls for each of our characters.

We’ve been having trouble importing .obj models into our project. For the time being, we’re looking to use .gltf models only, but it would be nice to expand the selection of models we can choose from. We’re also planning on hosting our app on a GitLab repository instead of Glitch because Glitch is having a hard time loading the space station model we are using for our map.

WEEK 4

The following is what each team member accomplished this week:

  • Caelen worked on decreasing the size of the map, as well as implementing the wiring task.

  • Devika finished implementing the robot’s ‘telekinesis’ ability and added in objects for the robot to move.

  • Elana fixed some bugs and improved interactions for the human’s initial tasks, which are to seal the crack in the window and to use the flashlight to identify the shape of the room they are in.

  • Timo worked on the character models, the croquet physics system, the integration of the codebase onto gitlab, as well as investigating bugs in the multiplayer of the integrated code

We started integrating all our code to a gitlab repository where we will be hosting our app in the future due to performance constraints. You can now find our code here, and our most up to date demo here.

Our plan for the MVP coming up soon is largely the same, so this week we have decided to give you a look into the features we have whipped up! Here are some demo videos of the interactions and environment we have been building:

Here is a video demonstrating the 'telekinesis' ability:

Here is a video demonstrating the Spray Sealer™ sealing the crack in the window, the lights turning off as a result of sealing the window, and the flashlight:

And here is a video showing off part of the map we plan on using with the items the robot will eventually have to move to do their task:

This next week we will be integrating and finalizing our code in preparation for the MVP presentation on May 4th (may the 4th be with you) and squashing any bugs we find along the way. We will also be working on our presentation for the same day. Individually, Caelen will work on making the map smaller in size so our app can load on the Oculus Quest 2, Devika will finish interactions for the robot character for the first stage and begin interactions for final stage, Elana will finish interactions for the human character for the first stage and begin implementing zero gravity, and Timo will create interactions between human and robot players and ensure physics are working properly. Additionally, we will all work to integrate each element we have been working on this week into a single codebase and environment.

This past week, we finally got access to a single repository with enough storage to handle our larger assets, however we found the large file size of our map and some assets is an issue to performance and load times in the WebVR environment. We are working to reduce these file sizes to fit our constraints. There was also some struggle finding a way to sync character model movements to the controller movements, so we are using floating heads with hands synced to controllers to represent our characters. Finally, we’ve had some issues with the croquet physics system and interactions with objects, and while we’ve figured out most of the problems, we’re going to save the use of this system for future levels of the game where object synchronization will be needed due to the players no longer being separated. For the MVP the players are separated, so we will use a local physics system for now.

WEEK 5

The following is what each team member accomplished this week:

  • Caelen worked on finishing up the wiring puzzle, added doors to separate the rooms, and made adjustments to the debris positioning, as well as recorded footage for the demo video.

  • Devika worked on fixing two main bugs for the robot’s first task, stable box positioning and single object telekinesis through a shorter laser.

  • Elana fixed bugs related to the human player’s tasks to ensure events occurred at correct times for the MVP, as well as debugging the issue we are having where light does not reflect off our textures in the Oculus browser.

  • Timo worked on fixing up croquet loading issues, developing separate controls for human and robot players, as well as recording footage for the demo video.

This week we worked on integrating our individual code for tasks and interactions into a single codebase for the MVP (check out our codebase on GitLab here), fixed a couple bugs, added final touches for the demo. Together, we worked on getting our demo ready to present by creating a script, adding our slides to the deck, and recording the key gameplay elements that we have been working on so far.

Here’s a link to our highly anticipated MVP! https://courses.cs.washington.edu/courses/cse481v/21sp/projects/team3/

Or, you can watch our demo video here

Our plan for the upcoming week is to improve the player experience, especially by creating clear and distinct hand gestures, having smoother asset rendering, and including better textures, and working on the next level of the game where the robot and human meet. Individually, Timo will focus on making object positions shared between players so they can interact with each other in the same scene, either using Croquet physics or possibly migrating to Networked A-frame. Elana will be working to make player movement more intuitive for Oculus Quest 2 controllers by replacing our current teleportation component with a different one, as well as try to improve player interactions with objects by improving the grabbing mechanisms. Caelen will be working to resize our textures for our map model so the experience on the Oculus browser can be improved. Devika will be working on planning interactions for the next level in our app and will start building some of the interactions.

Looking ahead, we know that we will need more rooms for future scenes and levels, so we worked on trying to find a way to possibly unload assets that were currently not in use for a scene. Since map size has been one of our main struggles for rendering the game on the Oculus, we wanted to be proactive in trying to solve this. A potential solution we are looking into is disposing of objects from previous levels when switching to a new level. We also faced issues with lighting for our scene this week. The lighting looks as expected in the desktop view, but doesn’t work on the headset which may be due to textures being too large. We are looking into compressing our models and textures for the map even more than we already have to see if that allows lights to reflect off of them.

WEEK 6

The following is what each team member accomplished this week:

  • Caelen repacked the map model with proportional textures to fix edge jittering in headset, inverted mesh normals to allow interior lighting in headset, and implemented level transition by toggling scene visibility.

  • Devika worked on adding blink-controls (that were eventually switched for joystick movement) and experimenting with zero gravity with a focus on smoother movement.

  • Elana researched how to implement zero gravity movement and began experimenting with A-frame physics and kinematic-body.

  • Timo experimented with Croquet physics to see if we would be able to use it with our app and he also started replacing Croquet with Networked A-frame once we decided to switch.

We are planning on substituting Networked A-frame for Croquet to enable multiplayer functionality because we are having difficulties using physics with Croquet. As physics plays a major role in our game, we think Networked A-frame will give players a smoother experience when interacting in a shared environment. Additionally, we have started a branch to experiment with zero gravity movement, which can be found here.

We decided to remove the teleportation functionality and only allow the player to use joystick movement to navigate the map. Additionally, we are beginning to plan for our final level and want to focus on implementing zero gravity movement before designing tasks for the players to “win” the game. Here’s a video of our progress with zero gravity so far:

Additionally, we added the functionality for players to progress to the next level by unloading assets from the previous level and loading new assets. Here is a video demonstrating that functionality:

We are also hoping to give each player a new “ability” that they did not have in the first level: we’re giving the “robot” character a laser cutter and the “human” character the ability to shoot fire and a freezing substance from their hands.

Next week, we will continue experimenting with zero gravity movement, as well as with Networked A-frame. We will also start implementing the human’s and robot’s new abilities. Elana and Devika will continue researching zero gravity and work to make it a smoother experience for the players. Caelen and Timo will work on implementing Networked A-frame, as well as implementing the players’ new abilities if they have the time.

We are working to allow players to move around in zero gravity and are having some issues with physics when the hands are involved. Currently, we are just relying on A-frame physics, but the motions are very jerky and aggressive. We will try experimenting with adding our own velocities when the users push against a wall or an object so that the movement is smoother, but any other suggestions for improving the movement are appreciated.

WEEK 7

The following is what each team member accomplished this week:

  • Caelen built the new abilities (fire beam, ice beam, and laser cutter) and created a quick demo to showcase for our practice demo day.

  • Devika worked on creating the push and pull movement in zero gravity.

  • Elana continued working on implementing zero gravity as well as working out some bugs in the transition between the first level and the second level.

  • Timo continued to integrate our code with Networked A-frame, requiring some reorganization of the code.

We merged the separate branches we were using to implement zero gravity and combined them so players can move between levels. We also added new abilities for the human player: ice beam and fire beam, which they can use to freeze and melt water. Here's a video of those abilities:

Additionally, we added a new ability for the robot character along with telekinesis: a laser cutter that can cut through certain materials. Here is a video of the laser cutter:

We plan on using these new abilities, along with zero gravity movement, to design our puzzles for the next (and final) level of the game. Additionally, we are still working on transitioning from Croquet to Networked A-frame for multiplayer functionality. Our progress so far can be found on this Glitch project.

As mentioned above, we introduced the two abilities each player will have. For the first level, the robot player has the power of telekinesis, but not the laser cutter, and the human player receives the ice beam power to seal the crack in the window, but does not have the fire beam power. Therefore, we plan on giving each player their second ability in the second level and will introduce new puzzles and obstacles for the player. We are also adding the ability for the robot player to “die” and respawn if they touch water, which will be an added obstacle that the players will have to consider. Last, we would like to have some interesting puzzles that allow players to experience zero gravity movement with either grab and push mechanisms to move around or by using a “jetpack” that pushes them around.

Over the next week, we will design and implement the puzzles for the new level using the players’ new abilities and zero gravity movement. Caelen will create the respawn event for the robot player when it touches water and start building the puzzles. Devika will continue trying to implement the push and pull mechanism for players to move around in zero gravity, as well as start implementing some of the puzzles. Elana will work on enabling and disabling zero gravity when players move between levels and try to get kinematic-body to work well with the rest of the code. Timo will work on getting objects to move on both players’ screens in Networked A-frame and make some final touches on the networking.

Over the past week we’ve had some problems with constraining the player’s movement using the kinematic-body component, as well as trouble implementing push and pull off of objects in zero gravity. Also, replacing our current networking with Networked A-frame required a good bit of code to be rewritten, but has been faster to develop as it is more straightforward with more documented support.

WEEK 8

The following is what each team member accomplished this week:

  • Caelen figured out multiplayer object syncing with the physics engine using Networked Aframe.

  • Devika did some final work on using a climbing mechanism for zero G and implemented part of the final level puzzles.

  • Elana looked into alternatives to kinematic-body if it stops working and implemented part of the final level puzzles.

  • Timo worked on Networked A-frame integration and investigated Networked A-frame custom messages to handle in-game events.

For zero gravity, we have decided not to use the climbing mechanism and just stick with a kinematic-body with a “jetpack” that allows the player to fly around. We occasionally have some issues with CANNON.js kinematic-body breaking our link, so we want to explore using ammo.js physics instead of CANNON.js physics. We will be working on this branch to convert physics in case it breaks the rest of our code. As for networking and multiplayer, we’ve figured out how to sync object physics between clients using networked a-frame and are working on creating templates and scripts to bring it into the game.

We came up with our puzzles for the final level this week and implemented a large chunk of them. Our idea with the final puzzle was to combine the four abilities for both players and have them work together to supply power to the ship. The players must search the room for two batteries that they will place in the central terminal, which will then power the ship and allow the players to continue their journey through space!

Over the next week, we will finalize our final series of puzzles, replace Croquet with Networked A-frame, explore ammo.js as a replacement for CANNON.js, and add any last final touches to our app before our final video and code submission is due. Caelen will try out ammo.js instead of CANNON.js and work on adding Networked A-frame to our project. Devika will add some finishing touches to the final puzzle and create the obstacle course in the corridor to be done in zero gravity. Elana will change the final puzzle to use batteries instead of button presses to power the ship, work on an event that signals the end of the game and start making tutorial messages. Timo will be working on transferring the Networked A-frame Glitch project to our GitLab project and sync objects between players.

We currently do not have any blocking issues, although we will be changing the underlying code for a lot of our app, which might cause some bugs. We will be working over the weekend to make these changes so we still have time to fix any bugs or errors that might occur. We will also save a copy of our current codebase in case the changes do not work with our code and need to revert it.

WEEK 9

The following is what each team member accomplished this week:

  • Caelen synced the human and robot templates for Networked A-frame and also filmed and edited our final video.

  • Devika finished up the final puzzle and created the obstacle course for the zero gravity experience.

  • Elana finished up the final puzzle, created a final event that happens when the players finish the game, added tutorial graphics around the map, and started polishing the player experience.

  • Timo worked on syncing objects across clients and debugging issues that came up with syncing.

This week we finalized the multiplayer experience, allowing players to join the same game and interact with each other through synchronized object physics. Additionally, we finished all the puzzles and rooms and created a final sequence that occurs when the players beat the game. We also are starting to work on creating a smoother player experience by adding a loading screen with room and player selection and ensuring all objects are synchronized between players. You can play our final version using this link: https://event-horizon.glitch.me/, or you can watch our hype video here:

For our final app that we will demo, we wanted to add some small extra features that would improve player experience. Our main focus before demo day will be adding an initial screen that allows players to choose a room and which player they would like to play as. This screen will also hide the assets as they are being loaded into the scene. There are also a few extra features we would like to implement if we have time, such as giving players a reason to seal the cracked window (it’s currently not required to advance through the levels), adding teleport controls and snap turns without them conflicting with joystick movement, and adding sounds to the scene.

Over the weekend, we will be working on some finishing touches to our project, ensuring that we have fixed all the bugs before demo day. Additionally, we might add a few extra features if we have the time to do so.

We’re just working on debugging and polishing the player experience now, so no blocking issues!