College Chronicles Part 4: Asteroids Evolution

Immediately after finishing Katamari Arkanoids I started work on the next assigned project in my class.  This game was made in the same class as Katamari Arkanoids, Structures of Game Design (SGD), while attending Full Sail University.  Everyone was assigned to make an Asteroids inspired game.  This meant you could make any game that had something player-controlled that shot bullets.

Making a traditional Asteroids game was something I always wanted to do.  The big reason why was because it was my Dad's favorite game.  I figured since my Mom and Dad were paying for all of this school that I should make something for them (sorry Mom).  Because of all of this I chose to make a traditional asteroids game...with a few twists.  Check it!

This game was finished in June of 2006 and was worked on for about 4 weeks.  It was the most feature rich game I made at the time.  The game has all of the mechanics and features of the original Asteroids.  The twist I mentioned earlier came in the form of weapon upgrades and bosses.  The level was also completely scripted and has an end.

Speaking of scripting, I created a simple Command-Based Scripting Language and interpreter to allow the game to be tweaked easily.  Prior to starting this game I read a lot of the book Game Scripting Mastery (which I highly recommend) and thought that it would be cool/helpful to implement Command-Based Scripting for this game.  I had a lot of fun making it and the work I did in this game helped me better utilize scripting solutions in future projects.

Some other underlying tech that I made on this was a message system and memory manager.  They were actually hard requirements for the project.  From looking at the code it is clear I didn't understand the meaning of a message system.  The message system was completely coupled with the main game class and hardly used.  The memory manager was useful. I remember actually tracking down issues by using it to report how much memory was being used.  Template functions to allocate and deallocate memory isn't how I would do it now.  Overloading new/delete would have been a more elegant approach in my opinion.  I also did not do anything cool with the memory manager like allocate a huge chunk up front, or keep memory from being fragmented, or really anything extra besides allocating/deallocating.

Most of the code was from my previous game and was unchanged.  It is clear I focused mostly on adding new tech and game features.  This makes sense due to time constraints, but had the adverse effect of transferring the same flaws over to this project.  Which means there are singletons a plenty and coupling galore.  However, I will admit that there is something special about hacking something together and having a game come out the other end.

I almost forgot about my favorite thing I did for this game.  This was the first game I implemented a particle engine for.  A friend of mine had made a particle engine for his pong game (same time as Extreme Pong 2) and it made me very jealous.  Earlier in the year I had read a book called OpenGL Game Programming, which had a section on how to make a simple particle engine.  Definitely not an ideal implementation, but it was a way for me to wrap my head around the idea.

The particle engine was just a particle object and a class that manages the particles.  With my implementation you could create a new particle effect by extending the manager class and making your own update logic.  This is not how it should be done as you have to hand code the effects, but you gotta walk before you can run.  It was quick and easy to do and time was something I didn't have much of.  Stay tuned to later Chronicles as particle engines is something I have a bit of a fetish with for the rest of my stay at Full Sail University (and to this day).

I did do some code maintenance before I posted and it wastn't too bad.  As usual there are many comical and silly codez to be seen.  I STILL hadn't made or utilized a math library at that point so there are lots of sweet inline algorithms that made the code hairy.  It is not just lack of a math library either. There is code duplication everywhere.  One feature I added before posting was the ability to give the ship reverse thrust.  The input code for the ship had this same block that had to be called for each case and I had missed one line of it when I copied it for the Nth time.  It took me couple of minutes to figure it out.

These snippets made me laugh:

Overall the code isn't too bad.  Don't get me wrong, its terrible by my current standards, but I can always say that I've seen worse (more on that in a future post).

I learned a lot with this game.  Going back and analyzing it today I have also learned something.  Now that I think about it, this was the last game I made from start to finish 100% on my own.  There is something very special about making a game with only your means.  Some parts are pretty bad like sounds or graphics or design or code (unless you're crazy), but dammit they were made with my own hands.  He didn't help me, She didn't help me, not even YOU helped me.  I did it on my own!

P.S.  Sorry no "how to" instructions in-game, check out the "ReadMe.txt" in the "bin" folder for the controls.

Game Download(Windows):
Asteroids Evolution - Game and Source

Game Video: