Shantanu Pandey
  • Projects
    • Hard Light Vector
    • Memory Manager
    • Samurai Crusader
    • Dyslexia VR
    • Geriatric Depression Suite
  • Prototypes
    • Game Mechanics
    • Diana's Inferno
    • MakeUp & BreakUp
    • 10Pest
    • Ninja Pinball
  • Blogs
    • Sic Parvis Magna
    • Game Engineering - Week 1
    • Game Engineering - Week 2
    • Game Engineering - Week 3
    • Game Engineering - Week 4
    • Game Engineering - Week 5
    • Game Engineering - Week 6
    • Game Engineering - Week 7
    • Game Engineering - Week 8
    • Game Engineering - Week 9
    • Engine Feature - Audio Subsystem
    • Final Project - GameEngineering III
    • AI Movement Algorithms
    • Pathfinding Algortihms
    • Decision Makiing
  • About

Final Project

12/2/2018

0 Comments

 
This my final project write up for the Game Engineering II class. As a part of the final project, we have to use our engine system and someone else’s engine component and create a small game out of it.

The game I choose for this final assignment is the old classic frogger. In frogger, player controls a frog and has to navigate it across the screen, dodging or using the obstacles. What I initially thought was I would make a game very similar to the frogger in terms of gameplay (maybe not visually). But after working on the game, it turned out to be quite complicated and I decided to pivot from the original frogger. I took this decision as I was having some difficulties integrating the collision system in my game, and hence decide to move away from complicated collisions. I still have some collisions, but that’s just basic 2D box collision with the walls for making my game work.
For the new game, I decided to take inspiration from the original frogger with some tweaks. In original frogger, the player controls the movement of the frog but in my game, player can only change direction once the movement is started. To explain the game in a nutshell:
  • The frog accelerates with time once the movement is started.
  • Player has the ability to stop the movement only once in a level.
  • Player has to navigate the frog through a maze and reach the end point.
  • On colliding with any wall, the player dies and level restarts.

I will be using the audio system I created for this game. Bare-minimum, the game will have a background music, a player dying sound effect and the level complete effect. Also I have added the controller support for this game. I used Sai Pavan Koundinya Upadhyayula's controller engine component. Adding controller was pretty straight forwards as he has a pretty easy interface to use his library. I will go through the technical details of adding the controller in my next update.

Final Project

I integrated the following features in my final project:
  1. My audio system for background sound and effects.
  2. Sai's controller engine component (as stated last week)
  3. Ekshit Nalwaya's particle system for player death visual feedback. 
I will first talk about other two engine components I added in my final project and then about my learnings.

Sai' Controller
This was as simple as anything we have done in our class. He had Controller project which we can easily add to our project and controller can be used after that.
Only thing required to setup this was to initialize and cleanup controller in out cbApplication class, but since everyone of us was already familiar with this, using controller as a whole was super simple.
Picture
Controller Initialize
Picture
Controller Cleanup
Ekshit's Particle System
For using the particle system, we need to include two projects; Particle system and the Particle system builder. The concept was same like mesh or effects as we have done before; builder is used to build the particles from the lua file and Particle system was the project which contains everything related to particles. Using these particles was also simple (it looked a bit intimidating initially as we have to update the graphics buckets we were submitting and rendering), however it required few additional steps for using these properly. 
An additional data for the particles was added to the graphics buckets we are using. As we have submitted the mesh effect pair, we will now submit the particle as well. I added this particle in my mesh effect struct and and checked if its not null while binding and drawing this data.
Picture
Updated Mesh Effect Pair Struct
Picture
Rendering the particles with mesh effect
Thing I liked about this component was it was a nice revision of small things we learned at the start of the semester. 

Final Project Learnings
Controls: 
W S A D or Left Controller joystick to move
                   Space or 'A' key to brake
Playable Download
Picture
Screenshot
While making the final project, few of the place that I got stuck were:
  1. Collisions: My initial assessment was I wanted to make something similar to Frogger which required me to have collision overlaps. I was unable to achieve this and so I decided to move away from the floating platforms.
  2. I had a very basic collisions in my final project. Player position was checked against the boundaries  of the lanes used in the games.
  3. I had used uint8 at one the place in my graphics system which did not work when we used the meshes with high vertex count. I found this out when I was trying to put various random meshes in the game.
  4. Dependencies and references; I encountered linker error sometimes while adding the new projects but was able to quickly resolve them.
Semester as a Whole
Looking back at this final project and the semester as a whole, I would say that my biggest learning is regarding the linker errors. I still remember how worried I used to get whenever I see any linker error but now they seem pretty primitive and I am confident enough to resolve them.
Being the graphics class, my knowledge of OpenGL and Direct3D is more than it was 6 months ago. Though we specifically didn't write any code from scratch, going though JP's code has helped me improve my graphics understanding and how the graphics pipeline works.  
Datatypes, Memory and Optimizations: This is something which I have been doing since the start of this school, and this class improved my understanding of how to effectively utilize different datatypes in different situations. I also encountered the ill effects of premature-optimizations.
Platform Independence: This was something JP stressed a lot on and the system really works well when we take care of different platforms. Interfaces should be platform independent with their platform dependent implementations. 
Few other small but important tricks I learned in this class are:
  • Graphics debugging (week 2), how we can use visuals studio for graphics debugging.
  • LUA; I did some LUA last semester and it was good to revise it some more this semester.
  • How different windows configurations affect the development environment and memory utilization.
  • Property sheets, how and when to use them.
  • Build time debugging (this was one of the most amazing thing I saw, I had no idea we can do this)
0 Comments

    Author

    Write something about yourself. No need to be fancy, just an overview.

    Archives

    December 2018

    Categories

    All

    RSS Feed

FOR ANY FURTHER DETAILS


Telephone

801-859-1131

Email

Resume
File Size: 227 kb
File Type: pdf
Download File

Visit Hard Light Vector
[email protected]
Git Hub
  • Projects
    • Hard Light Vector
    • Memory Manager
    • Samurai Crusader
    • Dyslexia VR
    • Geriatric Depression Suite
  • Prototypes
    • Game Mechanics
    • Diana's Inferno
    • MakeUp & BreakUp
    • 10Pest
    • Ninja Pinball
  • Blogs
    • Sic Parvis Magna
    • Game Engineering - Week 1
    • Game Engineering - Week 2
    • Game Engineering - Week 3
    • Game Engineering - Week 4
    • Game Engineering - Week 5
    • Game Engineering - Week 6
    • Game Engineering - Week 7
    • Game Engineering - Week 8
    • Game Engineering - Week 9
    • Engine Feature - Audio Subsystem
    • Final Project - GameEngineering III
    • AI Movement Algorithms
    • Pathfinding Algortihms
    • Decision Makiing
  • About