Menu

Object Oriented Programming

Let's says you have learned a programming language and you have experience with a graphics library (like SFML). You have been practising and even make a Pong/Tetris clone. Now you want to step up, and make your own game.

All starts with an "idea".

It doesn't need to be unique or original. But it has to make sense in your head. An action game, or a platformer, strategy, or any genre you like. Then grab a pencil and start writing you "idea" down on paper. Make a list of features you want in your game, how you want it to be.

Afer that, you need to convert this "idea" on paper to a Data Structure or Design that can be programmed. I know it's easy to say, but you have to know that beign a programmer means to translate human thoughts and ideas to logic structured statements that a computer can understand.

Now is when you have to decide the design approach to your game. Defining classes, structures, functions, etc. There are many design patterns, each one with pros and cons. As a programmer, you have to know and decide which one is best for you. I will talk about Object Oriented Programming (OOP) and basic Entity class Hierarchy.

The main idea behind is to create a small class called [Entity] who has the basic variables like id, type, position... and use it to derive more sub-classes based on it.

#include <SFML/Graphics.hpp>

class Entity
{
	Entity() { m_id = 0; m_type = 0; }

	// functions
	int getID();
	int getType()
	void setPosition(float x, float y);
	...

	int m_id;
	int m_type;
	sf::Vector2f m_position;	// SFML vector has coordinates x,y
}

For example, let's say you want to do a side-scrolling platformer. It has the player moving around and jumping, enemies attacking you, coins or power-ups to grab, objects and other things that are part of the level, etc.

So we need a [Player] [Enemy] [Collectible] [Object] classes. Two of this classes has something in common, [Player] and [Enemy] can move around (in this example [Collectibles] and [Objects] are static). Also, each enemy may have different kinds of weapons or attacks, and the player too. We make another class derived form [Entity] called [Actor]

class Actor: public Entity
{
	Actor() { m_life = 10; m_speed = 50.f; };

	// functions
	...

	int    m_life;
	float  m_speed;
	Weapon m_weapon;	// active weapon for attacks
}

Now we create the [Player] and [Enemy] classes:

class Player: public Actor
{
	Player() { m_id = 1; m_life = 100; m_speed = 80.f; m_coins = 0; };

	// functions
	...

	int m_coins;
	std::vector<Skill> vSkills;	// double jump, extra damage...
}

class Enemy: public Actor
{
	Enemy() { m_type = 5; m_life = 50; m_speed = 25.f; };

	// functions
	...

	int m_drop;
	AI  m_AI;	// enemy behavior controlled by scripts
}

And finally we can simplify the last two classes in one, because the only difference between a Collectible and an Object is the ability of the player to collect them. So we can create a [Object] class and add a bool variable to know if it's a Collectible.

class Object: public Entity
{
	Object() { m_collectible = false; };

	// functions
	bool isCollectible();
	...

	bool m_collectible;	// if can be picked by player
}

The example is very simple but is pretty self explanatory. All classes has only what it needs and we avoid to duplicate code writing to every class an id, type, position... variables and the corresponding functions to work with them. This design approach works very well if you have a well defined structure.

In fact, this design is what I used in my game. I have an [Entity] base class, an [Actor] [Object] [Bullet] class derived from [Entity] [Player] [Enemy] derived from [Actor]. Potions and any other drops are [Objects] using the same bool variable mentioned before.

The next step will be creating the Engine wrap this classes inside the game logic. Using STL containers or even smart pointers if you need so. Something like this:

// Engine.h
{
	...
	
	Player m_player;
	
	// vector of objects in the level
	std::vector<Object> vObject;
	
	// vector of enemies alive
	std::vector<std::unique_ptr<Enemy>> vEnemy;
	
	...
}

On a future article I will cover the game engine design more in deep, and the logic behind it.

This is just one of many design patterns. I can't tell you which one is better for you. My advice is: If a design/code makes sense for you, it will be easy to work with. You don't need to over-complicate things making complex data structures.

Read more about Object Oriented Porgramming here: en.wikipedia.org/wiki/Object-oriented_programming






AVAILABLE ON STEAM





Icons made by Lorc. Available on Game-Icons.net