Final Project 471: Xavier Graham

General Information

The initial plan for my game. This plan consisted of a height-mapped hillside with collision detection, animation, and procedurally generated obstacles.

Above are some screenshots of a single playthrough of the game. The dummy is controlled using the A and D keys. The player can also hold the spacebar to decrease the speed of the player, but this is simply to make the game a bit easier, incase the speed of the player changes on certain machines. Lastly, pressing the M key will change the player color.
(I apologize in advance about the bad frame rate, my computer is not that strong.)

Above you can see a short screen recording of the game. As you can see, the console outputs the player's health value on each render, and at the end of the game, the player can check the console to see how many points they scored if they reach the goal at the end of the level. A player can collect points and increase their score by picking up the red alien boxes scattered down the map.

Also, the player can lose health if they run into an obstacle, whether it be a rock or a tree; however, the player will lose more health if they run into a rock (-4 health) than a tree (-2 health).

If a player loses all their health, they lose the game and the console says "GAME OVER". The window will also close automatically on a loss, making it easy to restart and try again.

Collision Detection

My project uses bounding cylinders to detect collision between objects. Initially, I used spheres, but the player is too tall, so the sphere jutted out much farther than I needed it to. Bounding cylinders (basically bounding circles, but with a y dimension) are more accurate for my program because the player can only collide with rocks, tree trucks, and power cubes, all of which can be correctly represented by bounding cylinders. This is only possible because my game is played on one plane (y = 0). If I were to implement a height map with interpolated height at every position, I would have to alter the collision logic to accommodate for the leaves and the possibility of jumping over rocks/powerups.

I use a simple struct to represent my bounding cylinder. Every collision-detectable object contains this bounding cylinder struct inside their own struct representation. This made it easy for me to test the bounds for my collisions by simply referencing the objects that I'm testing and summing their specific radii.

Hierarchical Modeling and Animation

I used hierarchical modeling to move parts of the dummy. Pressing A or D will bend the dummy's legs left or right, respectively, creating the illusion of a person skiing (except for the fact that I couldn't get the ski's to appear correctly on the dummy's feet).

If the player reaches the finish line, represented by a massively-scaled-up hockey goal (none of the checkered flag meshes were free of charge), then the dummy will flap his arms up and down in joy that the player didn't kill him.

Also, the alien cubes are animated and rotate around their y-axis to differentiate them from the other obstacles. This is visible in the above video.

Procedurally Generated Obstacles and Powerups

I used srand(SEED) and rand() to generate a constant, yet random, level of the game. The default seed for obstacles is 161, and the default seed for the alien cube powerups is 202; however, the player can feel free to change the random seeds (on lines 385 and 403 of main.cpp) to experience an infinite number of different courses.

External Resources and Unfinished Work

Most of my project was individual work, but I did use some meshes that I found on turbosquid.com; specifically, the rock, tree, hockey goal, and alien cube meshes. The rest of the code (collision, hierarchy, game logic, etc...) and the other meshes were taken from previous projects/labs, as well as my brain.

Of course, no project is ever 100% complete. However, in this project, I had wanted to implement an interpolated height map that the player could ski through that would make the game a bit more challenging, since the hills would sometimes block the player's view of the rest of the level. However, I was never able to get the height map to properly offset the player or the objects. Thus, the day before the final presentation, I decided to scrap the height map altogether in order to have a working prototype to show to the class.

With extra time, I would (hopefully) implement a height map as well as a HUD for the player's health, score, and distance traveled through the level.

Thanks for playing!