Missile_Shooter_WriteUP

About my game:

This game is part of my final project for the Game Engineering class taught by John Paul Ownby at the University of Utah. 

My game is a simple missile shooter where you have to defend your base from the incoming missiles by shooting and destroying the missiles.The tricky part of the game is to make sure that you are using the same kind of the missile coming down, to shoot and destroy it successfully. Missiles of different types don't have any effect on each other. There is no win condition for the game nor a losing one. You can play as long as you want. There is a particle effect that spawns each time  you successfully hit a missile, there is also a background score and a successful missile shot sound. A slight rumble effect plays on your controller when the enemy missile successfully hit the player base. 

Couple of screenshots

Instructions on how to play the game:

Player controls a missile shooter with which he/she can shoot 3 different types of missiles each assigned to a different button. Player can move the missile shooter in the lateral axis. There is no vertical movement allowed for the player. That's it, it's just as simple as that, move the missile shooter to the correct position and then shoot the incoming missile down. 

Controls:

Left stick - Missile shooter lateral movement

Face Button Left - Shoot Spherical missile

Face Button Bottom - Shoot cone missile

Face Button Right - Shoot cylindrical missile

How it works:

The rendering of everything is done in a project named Graphics which is mostly the code I used from John Paul Ownby’s project. There are some changes I made it to work for my game.

The Input from Controller is a system I made. It is a very easy to integrate and use system which provides all the necessary functions needed in its interface.

The collision of missiles and base and everything uses the collision system of Luis Garcia Remes. 

The particle system uses the Particle System developed by Joseph Moyle

The sound is played using the code obtained from Fengkai Zhou.

More about the Systems used:

Luis Garcia Remes’s Collision System:

Here is a link to the collision system

Luis Garcia Remes's Collision system

The system was very easy to integrate, it can be done in not more than 2-3 minutes. Coming to the interface, the Run method which takes a list of colliders as input and returns all the pairs which have collided is really helpful. I really like the idea of it, because when I wanted to know about only certain colliders but not all, I could only specify the colliders I want in the collider list I’m passing to the function. It’s really simple yet super effective in my case. 

Joseph Moyle’s Particle System:

Here is a link to the particle system

Joseph Moyle's particle system

The one thing which stood out for me apart from the simple and easy way to integrate is the ability to move the particles using standard rigidbody physics. It is a much more convenient way for me to move the particles from one place to another. In my game, when I needed to spawn the particles, I’m just moving them from the previous place to the new place where the collision happened.

Fengkai Zhou’s Audio System:

Here is the link to the Audio system

Fengkai Zhou's Audio System

This has been very easy to implement although I’ve no idea about the sound, its channels and all that technical jargon. The interface has many useful functions for play pause resume, looping which I believe are very handy. Stopping and playing sounds based on the channel might be very useful for some but I never got the chance to explore more. It supports many different formats of audio files which is another great thing about this project.

Self reflection:

I didn’t find anything frustrating while using my own Graphics interfaces. I think defining a structure that holds the data needed for rendering an object was a good idea. Being able to submit all the data needed at once is also really helpful while I’m submitting the particle effects. One thing that is frustrating for me was to change the size of the number of objects I can send over while submitting to graphics. Each time I added a bunch of objects I had to reset the value of the variable manually. I don’t think having a really big array or having dynamic allocation would be super helpful in this case. So I guess I just have to choose one thing. The idea of GameObject to hold all the data together was a good idea. I've added the data related to the rigidbody state, the mesh I'm drawing, the collider data, the effect I'm drawing with to the Gameobject. So when I'm submitting data to different systems such as Graphics, Collision etc, I just get the necessary data from the Gameobject and pass it to the corresponding system. It is extensible so if I want to add new kind of data that is needed by a new system, I can just add it to the Gameobject.

My Controller system: 

This is one thing I can confidently say where everything is defined and implemented perfectly at least for me. I never changed the code once I pushed the final version of it like 3 weeks ago. It's been easy to use, I could find everything I need already implemented, maybe I’ve thought it through or I’ve only implemented the ones I thought I would use in the future, I’ve no idea but its been great so far.

Things I learned from the John Paul Ownby's Game Engineering class:

It’s been a really great experience to be in this class. The things I learned which stand out from the rest of the many things are

1. John Paul’s naming convention. Although there is already a coding style which I like and use, I found JP’s a bit more efficient. And I’m using it whenever I’m starting a project from scratch
2. I had no idea at the beginning of the semester that code can be defined in multiple different cpp files and tell the compiler to only run certain files based on the platform using. I think it is a major takeaway from this class. 
3. Using references in visual studio is another major thing I learned. Previously if I wanted to access some cpp file from a different project, I used to specify that library in the additional include directories or header files section. 
4. It’s been a really good opportunity to work on such a huge codebase, and learn how to keep things structured, the way it is now, it is so easy to add or remove any projects from the code base, which I think is really awesome.
5. There is stuff I learned about the graphics,I was introduced to shader programming although it wasn’t super heavy
6. The human readable files is one more major take away. Although I’ve doubts on its usage in a large scale environment and its relatively higher probability to error based on the person who writes it, I think it is a great thing to learn coz it gave me an understanding of how to make code reachable for other game developers without actually knowing the underlying technicality.
7. The reference counting and stuff was something I already knew from Joe Barne’s class but I think doing it often instills a good coding practice.
8. One cool thing I liked is importing models from Maya. It was super fun.
9. Having human readable files to edit and binary files to load from is a really great approach I learned. 
10. Another interesting thing I learned is the synchronization of the Application thread and the Rendering thread. The analogy of data to buckets really stuck in my mind. 

I would like to  congratulate all my peers  for making awesome projects in this class. And big thanks to John Paul for making this possible by providing necessary inputs and the codebase.