Week 14

Here is the link to my final project:
Here is the code documentation:

As you may have noticed, the final project version is vastly different from my midterm project, albeit some minor similarities. I wanted to retain the obstacle-dodging experience, as well as the overall setup of having the player confined to a specific z-dimension, while facing incoming objects. 
Because I've worked with three.js before, it wasn't too difficult to transfer the basic idea of my midterm project to the three.js environment. However, because I wanted to solve the issue of the ambiguous z-space perception, I needed to add shadows and lighting to the scene to give the perception of depth. Once I did however, I realized that it was almost impossible to tell that the ball was moving at all, but rather, it just seemed like the obstacles were the only ones moving towards the player. To remedy this, I had to make some adjustments to the texture, as well as figure out a way to 'roll' the ball forward. 

Adding lighting to the scene to give the perception of depth using shadows

Originally, I had planned to keep the cube shape for the player. However, because I couldn't really 'roll' a cube forward, it didn't give the motion I wanted. By switching to a spherical mesh, I could have the dynamic movement I was looking for.

To make it seem like the player was indeed rolling forward, I created another spherical object that acted as the ground. The ground sphere would roll 'backwards' relative to the player.

The obstacle logic followed the exact same logic as the obstacles in my midterm. I would create the obstacle object, and then push new objects into an array. Then, the object's z-position would continuously be updated so that it would move towards the player. 
One specific area of my final that changed dramatically was the implementation of raycasting. I was very dead set on applying raycasting to my project in order to create a more precise collision detection for the player. However, I realized that unlike my midterm, my final project confined the player to movement only along the x-axis. Instead of using raycasting, it would be much easier to apply the same logic I used in my midterm (detecting if obstacle has moved past the player or not), but split the window into three 'lanes'. If I could detect which lane the player was in, and if the player made contact (obstacles moved pass the player's z-position) within that lane, then a collision would have occurred. 

Laning logic for the player being applied to the arrow keys. 

If a collision has occurred, stop the three.js clock, stop the ground sphere rotation, and stop the player rotation as well. Gravity is increased to make the ball 'melt' into the floor.

Going back to the vector basics from the first week of class!

Setting the ground rotation speed, as well as the player rotation speed. A bounce value is introduced to add some dynamic up and down motion to the player sphere.

In-Game Screenshots:
It was a really amazing experience to be able to create a game like this. I didn't think I would be able to pull off the styling and the logic within the timeframe, but the end result ended up so much better than I expected. In the future, I hope to create some custom shaders for the meshes, since I am just using simple LambertMaterial. I will definitely keep experimenting with three.js as well!
Video:
↑Back to Top