This post is a portion of my mini-series on Object Oriented Game Development using the Allegro 5 library. You can see all of the posts by going to http://fixbyproximity.com and clicking the “OOP Game Development” button at the top of this site.
OOP Practices
This series is meant to be a mini extension of the previous 2D Game Development Course that I recently wrapped up. During my time making that course, there were a lot of people requesting information on completing the different projects in an object oriented manner. If you are unfamiliar with Object Oriented Programming, basically they mean wrapping your code up (encapsulating) into modules which we call classes. These modules contain all of the data relevant to one particular thing (object). There is a lot that can be said (much better) about this topic, but in a nut shell, we are looking to make our code better.
The Benefits
There are major benefits to developing games (or any software) using OOP. Basically, when we design these encapsulated classes, we can create an infinite amount of them. If you took my 2D Game Dev. Course, then you remember using structs to make our game. This process is very similar to that, but it is better because we can pull those multitude of functions into the classes. This makes all of the code much more clean and organized (organized code is happy code). Also, since we are using objects, we can apply the principles of inheritance to remove a majority of the redundant code that has been plaguing us so far.
Another benefit is extensibility. Basically, extensibility is a measure of how easy a program is to upgrade or add on to. Since all similar code is put in the same area and bound to the relevant data, adding new features is trivial. If I wanted to make a new enemy type, I can just inherit from my Comet or GameObject base class, throw it into my object list, and it just works. Easy. Are code is also more robust and harder to break. Sign me up!
The Drawbacks
Right up front, there is a major drawback to using OOP in the game. Due to the simple nature of the game, OOP is way overkill. We have to do a lot of work on the front end, and a lot of it is much more complicated than we really need. This is made greater by the fact that I am utilizing a lot of techniques that aren’t really required. I am trying to throw as much as I can into these videos to give you a crash course on OOP. As such, for a beginner, these videos may be confusing. If you find yourself getting lost, be sure to do some reading on OOP from the immeasurable number of sites on the topic.
Otherwise, you asked and I supplied. Let’s get to our mini series on Object Oriented Game Development!
Videos in the Series:
- Object Oriented Game Development – Intro
- Object Oriented Game Development – Part 1
- Object Oriented Game Development – Part 2
- Object Oriented Game Development – Part 3
- Object Oriented Game Development – Part 4
- Object Oriented Game Development – Part 5
- Object Oriented Game Development – Part 6
- Object Oriented Game Development – Part 7
- Object Oriented Game Development – Part 8
Hello and thanks a lot for everything you’ve worked on.
So, i just downloaded your full game code .zip and tried to run the game through codeblocks. I get some multiple definition problems though.
Some ppl suggested the ‘extern’ keyword but as i checked that works for variables.
So what about multiple definition of e.g. Background::Background(ALLEGRO_BITMAP *,float)? if i use extern on this i get errors that wont allow further compilation.
Thanks again!
Ah nevermind! It was my fault as i had not properly linked some allegro files.
Hi mike.
First of all i want to say thank you.
n i have a doubt..
you are deriving “Bullet” from “GameObject” . don’t you think it will increase bullet object size??
In your program of Allegro 5 oop game development you have updated the score when the bullet hits a comet but what if i do not want the score to be updated when the bullet hits the comet but instead score is updated when the ship is not collided with the comet or when it passes the comet?