• Download latest source code

In this tutorial, we'll be building a game engine from scratch. It will be entirely modular.
A module will be a small piece of logic that will encapsulate behavior or hold data. We'll be able to add or remove modules from our game objects at run time. The game objects themselves will be a part of a tree structure. Nodes will also be able to be added to or removed from the game tree at run time.

Motivations

It seems counterintuitive but Game programming breaks inheritance. Let's say you're writing an RPG. You design an Item class and an Enemy class. The Enemy class contains all the methods and logic for movement. They can walk around on their own accord and you've even implemented physics so an enemy can fall off a cliff or something. Later on, you realize you also want the Item class to be able to move die to physics, heck it would even be neat to have a spell or something to animate items so they sprout legs and walk around. Well, you already wrote all this code for Enemy movement, but you clearly can't make the Item class inherit from the Enemy class since an Item clearly isn't an Enemy so you have no choice but to rewrite all the movement logic in the new class. And it doesn't stop there. Movement isn't the only behavior we might want the two disparate classes to share. What about taking damage? Maybe you can smash an item to pieces. So now we rewrite the damage taking behavior for the Item class. Soon the whole thing is an unmanageable mess of spaghetti code.

Instead we'd like to be able to define movement behavior that we can simply add to any class in our game. Enter modular programming. With modules, we can do just that. Inheritance works out better as well; we can define a Movement module and then create a PhysicsMovement module and a WalkingMovement module which inherits from the Movement class.

I hope I've convinced you that this is an endeavor worth pursuing. Enjoy the tutorial!

Latest source code

Next