So in the last tutorial we created a GameObject class that took advantage of the sprite class from earlier tutorials. It didn't really do too much but it was only the start. In this tutorial we will really harness the power of C++ using inheritance and polymorphism.

So to start things off lets create a class derived from our GameObject class and call it Player, this will be a controllable character.

#include "Player.h"
void Player::Load(char* filename)
{
/* For the moment our player does not need to have any specific loading function
so we can just use the load function from the GameObject parent class, like so. */
GameObject::Load(filename);
}
void Player::Update()
{
// nothing for now
}
void Player::Draw()
{
/* Again we are drawing a sprite so lets reuse the function found in the parent class */
GameObject::Draw();
}
void Player::Clean()
{
/* And again we free the surface using the function from game object */
GameObject::Clean();
}

Before I continue I think that you should know of a few basic rules of thumb for inheritance, a derived class should model the "is a" concept, for example here I have derived player from gameobject, this fits the rule because player "is a" game object. If you find that an object models the "has a" concept then
you should think about creating a member inside the class for that object. For example a player "has a" weapon so it should have a member of type weapon.

Another rule of thumb is to only derive from a class if an object has different behaviour not if the object only changes some data, this can be achieved using a simpler solution of member variables. I got an example from a book of if you had created an enemy class and then you derived a boss class from it, say you wanted to create a boss that was faster or had more health, would you then derive a super boss from boss? you could but you would find that the super boss class is a little empty as you only really had to
change the health and acceleration of the boss (I know at this point my player class seems to be breaking that rule but it will change and I am really just trying to show how this kind of thing works ).

Hope that is some food for thought, but anyway onwards...

So now in our playstate we can create an object of type player instead of game object in the same way and naruto will pop up again.

Ok that should look the same as we had before when you compile it. Now we are going to code something that essentially encapsulates the entire point of OOP, hopefully I can do justice to just how powerful writing games in this way is and how much easier and more readable your code will become. Even though in the player class we added functions different to the ones in the game object class what was really happening is that the functions being called were still those of the base class (GameObject). This is where virtual functions come in.

If we wish to specify that we want to use the functions in a derived class then we need to prefix the base class functions with the virtual keyword

Now when you run this code the functions called for player are those we added earlier (essentially the game object functions). This may not seem to helpful on its own but with this we can use polymorphism which means we can refer to a derived object through a pointer to its base class, now I will show you
how great this idea is.

Lets open up PlayState.h and add a container, in this case a vector of pointers to GameObjects.

essentially this loop says that while i is less than the amount of objects within the container it should call the Update function, before that it checks that the vector is not empty if it is then it just skips
over. Notice we didnt have to explicitly call each function for the player, we looped through a vector of pointers to its parent class, but because of the virtual keyword the appropriate function for that derived object is called. This would work for any object derived from game object. Pretty damn cool huh?

Just to do another test lets create a game object and then a player object with a slightly larger image so we can make use of our vector and see this in action on multiple objects, of course feel free to derive more classes from game object and try them out too.

Notice that we simply create the game object and then pushed it onto the vector, the loops took care of the rest. You should see your two images on screen in the correct order. I advise you to look at this code a few times and really get to grips with it and then try to derive your own classes from game object and push them onto the vector.

As you can see this is extremely powerful and allows for some really nice readable and reusable code, next time I will improve it even further using an abstract base class and loading objects from a file, bet you can't wait

Heres the image I used for the game objectryuk.bmp(428.96K)Number of downloads: 417

Thanks alot for these tutorials. I have been following them over the past few days and i finished them today. Really looking forward to the next one.

Just one question: I tried to get the game states working with this new code and i had some problems. Menu -> Game works but after Game->Pause, it crashes. Is this code supposed to be working correctly with the gamestates?

Sorry about that, i wasn't claiming the code to not work, i was just asking for a simple solution to be already made for the people who try and do it by them selfs but keep running into errors because of our own faults.

Well either way, i spent about 2 hours running through my code and reading through these over and over again. I've managed to get it all running fine now.

Love what you've done so far, and this is really helping me understand the basics of game design.

---

Okay just a small question. I knew how to move sprites before using the whole gameobject approach.

Hi! I'm programming a game inspired in your tutorials. It's very easy the way you teach us
But I have a problem: when the vector has much objects the game starts to run very slowly. How can I fix it?
Sorry for my bad English...
Thanks for the tutorials

is this another basic example that is going to be built on?:
player = new Player();
player->Load("char.jpg");

the reason I am asking is because when I thought about having multiple objects getting created with the same image should I have already loaded that image in some where before hand and be passing in a pointer to it instead?