Interesting/ Hard parts of the project:
+ One of the first things that we started working on in the project is the avatar. From our study of avatars in the theory classes, we realized that an avatar would make the game experience more inclusive for the player making him/her feeling that he/she is actually 'living' the game. But developing the avatar has definitely been a challenging task and even more tedious was to track the movement of the controllers and map it to the avatar's motions. For this we used inverse kinematics.
+ Many a times, we had to keep a track of whether the local or the global axis for a game object had to be modified in case the game object changes orientation. This led to confusion at times.
+ Though coroutines are commonly used in VR, we implemented them for the first time in this project and saw that how better an alternative it is to the update method.
+ We had to keep a track of and change hierarchies of game objects throughout the development of the game.
+ Detecting collision of free falling objects or rather fast moving objects: This issue was faced while trying to detect collisions for falling keys and fast moving arrows. Due to high speed they just moved through the colliders. Finally we had to drop the idea of catching falling keys but managed to come up with a solution for detecting arrow collisions with the bullseye.
+ Being a level based game, we developed the levels individually but we faced a tough time integrating those levels. For each integration we had to write a script which involved deactivating the objects and components of the previous level and activating the objects and scripts of the new level. If there were script conflicts then we had to deal with them accordingly and all of the integration consumed a considerable amount of time. But at the end we succeeded and the final game gives the player a sense of continuity in the game as compared to games which use transitions between scenes.
+ We chose to add a mirror in the first room because the player would want to know how their avatar looks like in the game. A voice assistant explains the game to the player and gives instructional audio input whenever needed in the game.
+ We decided to attach the controllers to the avatar's hands because we're using inverse kinematics (IK) to move the hands which means that sometimes the hands might not reach their end effector position. To avoid this problem and orient the user, we didn't hide the controllers in the game.
+ The reason why we chose to have the avatar floating in the air instead of walking is because, even though using foot IK is easy, the users might have different heights and then since the model of the avatar is fixed in height, this would make the avatar look like it’s walking on air (if the user is tall) or beneath the floor (if the user is short). So we decided to go for the floating avatar instead.
+ Using the left and right controllers in the player's left and right hands respectively is absolutely necessary in the game since we're mirroring the tracked hand movements from the controller for the avatar. The player might not be able to differentiate between the left and right controller which may lead to him/her unintentionally selecting the wrong avatar in the first scene of the game. For this reason we've added virtual labels to the controllers indicating the 'left' and 'right' ones.
+ One of the first things that we started working on in the project is the avatar. From our study of avatars in the theory classes, we realized that an avatar would make the game experience more inclusive for the player making him/her feeling that he/she is actually 'living' the game. But developing the avatar has definitely been a challenging task and even more tedious was to track the movement of the controllers and map it to the avatar's motions. For this we used inverse kinematics.
+ Many a times, we had to keep a track of whether the local or the global axis for a game object had to be modified in case the game object changes orientation. This led to confusion at times.
+ Though coroutines are commonly used in VR, we implemented them for the first time in this project and saw that how better an alternative it is to the update method.
+ We had to keep a track of and change hierarchies of game objects throughout the development of the game.
+ Detecting collision of free falling objects or rather fast moving objects: This issue was faced while trying to detect collisions for falling keys and fast moving arrows. Due to high speed they just moved through the colliders. Finally we had to drop the idea of catching falling keys but managed to come up with a solution for detecting arrow collisions with the bullseye.
+ Being a level based game, we developed the levels individually but we faced a tough time integrating those levels. For each integration we had to write a script which involved deactivating the objects and components of the previous level and activating the objects and scripts of the new level. If there were script conflicts then we had to deal with them accordingly and all of the integration consumed a considerable amount of time. But at the end we succeeded and the final game gives the player a sense of continuity in the game as compared to games which use transitions between scenes.
+ We chose to add a mirror in the first room because the player would want to know how their avatar looks like in the game. A voice assistant explains the game to the player and gives instructional audio input whenever needed in the game.
+ We decided to attach the controllers to the avatar's hands because we're using inverse kinematics (IK) to move the hands which means that sometimes the hands might not reach their end effector position. To avoid this problem and orient the user, we didn't hide the controllers in the game.
+ The reason why we chose to have the avatar floating in the air instead of walking is because, even though using foot IK is easy, the users might have different heights and then since the model of the avatar is fixed in height, this would make the avatar look like it’s walking on air (if the user is tall) or beneath the floor (if the user is short). So we decided to go for the floating avatar instead.
+ Using the left and right controllers in the player's left and right hands respectively is absolutely necessary in the game since we're mirroring the tracked hand movements from the controller for the avatar. The player might not be able to differentiate between the left and right controller which may lead to him/her unintentionally selecting the wrong avatar in the first scene of the game. For this reason we've added virtual labels to the controllers indicating the 'left' and 'right' ones.