How to become a game engine developer

I started blogging about Game Engine Development a few years ago. I started doing so because the educational materials on game engine development were limited and most books on the subject were too dense.

It took me a lot of trial & errors to figure out how to develop a game engine. Now that I have developed one, I know the learning path that you need to take to become a game engine developer.

These are the steps:

Step 1: Learn Linear Algebra

First, learn Linear Algebra. No, I don't mean Algebra taught in middle school. I mean Linear Algebra concepts such as Vectors and Matrices. Focus on learning vector and matrices operations, especially dot product, cross product, space transformations.

Step 2: Learn C++ (or any language you want)

Next, learn how to program. I suggest learning C++. At this point, you don't have to be an expert in coding. But do learn about classes, methods, inheritance, polymorphism and encapsulation.

Step 3: Develop a Math Engine

Then, use your knowledge of vectors, matrices, and coding to develop a math engine. Operations such as Dot product, cross product and space transformation are used extensively in game engine development.

Step 4: Learn Computer Graphics

Now comes the fun part. Get acquainted with Computer Graphics concepts, especially the Rendering Pipeline and Shaders. Avoid coding and using the OpenGL API for now. The OpenGL API is confusing to understand if you have limited knowledge of computer graphics concepts.

Step 5: Learn OpenGL and do a lot of projects

Once you feel comfortable with Computer Graphics concepts, learn about the OpenGL API and OpenGL Shaders. Do as many projects as possible. Learn how to render characters, how to rotate and translate characters. Learn how texturing and lighting works with OpenGL. Again, this is the fun part, and I suggest doing as many projects as you can.

Step 6: Learn Design Patterns

The next step to becoming a game engine developer is to learn API architecture. A game engine is simply an API, a framework, that takes care of all the rendering, physics and mathematical operations. It is paramount that you develop an API that is modular, flexible, maintainable and adaptable.

To develop an API, you will need to learn Design Patterns. The most common design patterns are Singleton, Observer, Strategy, Composite, Factory among others.

Step 7: Develop a Rendering Engine

At this stage, you are ready to combine your knowledge of Linear Algebra, Computer Graphics, OpenGL and Design Patterns to develop a rendering engine.

Step 8: Review Newton's Laws of Motion

Once you have completed the rendering engine, is time to work on the hardest part of the engine, i.e., the Physics Engine.

The good news is that you don't need to be a physicist to develop a Physics Engine, but you do need to know Newton's Laws of Motion and how they are implemented using algorithms such as the Runge-Kutta algorithm.

Step 9: Learn Computational Geometry Algorithms

A game engine is not a game engine without collision detection. To develop a collision detection system, you need to learn about Computation Geometry algorithms such as GJK, BVH, and Sutherland-Hodgman. These algorithms are used to detect if a collision occurred, where did it occur and which objects are most likely to collide.

Step 10: Develop a Physics Engine

Once you are acquainted with the algorithms mentioned above, you should be able to develop a physics engine with a collision detection system.

Step 11: Develop a game, Test & Repeat

Congratulations, you now have a Game Engine. Develop as many games as you can and test the game engine as much as possible. Fix bugs, implement new features, develop games and repeat. Trust me; this is the best part of all.

Books to get started

Here is a list of books to help you get started:

3D Math

1. 3D Math Primer For Graphics and Game Development

Rendering Engine

7. OpenGL Superbible: Comprehensive Tutorial and Reference
8. Graphics Shaders: Theory and Practice, Second Edition

Physics Engine

1. Physics for Game Developers: Science, math, and code for realistic effects
2. Game Physics Engine Development: How to Build a Robust Commercial-Grade Physics Engine for your Game
3. Real-Time Collision Detection

Hope this helps

Should you develop a game engine or a game?

As someone who developed a 3D game engine from scratch, you may want to listen to what I have to say.

If your goal is to learn what makes a game engine tick, then go ahead and develop an engine. It is the best thing you can do. I guarantee you that you will become an expert in computer graphics, OpenGL, Linear Algebra, and computational geometry algorithms.

However, developing a game engine is an INSANELY complicated task. It took me about four years to develop the basic framework of the engine. That's right. Just to develop the basic framework of a 3D game engine took that long. By "Basic" I mean that the engine has a collision detection system, a physics engine, rendering engine, animation system, a Digital Asset importer, etc.

To test the features of the engine, I decided to develop a full blown soccer game. It is still a work in progress. Here is a video of the latest game update:

Here is another video that showcases what the engine can currently do:

And here is one of the very first demos showcasing the basic framework:

All in all, it has taken me about four years to develop the engine. However, the engine is not complete yet. There are bugs and issues with it. As I work on the soccer game, I'm finding more and more issues.

An engine requires a lot of maintenance and time; time that could be better spent developing your game instead. Thus, if you just want to develop a game, use an existing game engine instead.

You may be curious how a game engine works. If that is the case, I wrote several articles on game engine development that should give you a pretty good idea how it works.

How does a game engine works?

How does a rendering engine works?

How does a physics engine works?

And if you are interested, you can get a copy of my eBook: Components of a Game Engine

Enjoy

Implementing team formation-Soccer Game v0.0.4

This week was a very productive week for the development of the soccer game. As you can see in the video, I implemented most of the 11 players per team. Currently, I'm missing the goalies.

I improved the performance of the game by disabling shadows and collision detection on all but three players; dribbling player, receiving player and defender. Thus, at any time, the engine only renders a shadow to the player currently dribbling, the player who will get a pass and the defender. The same logic was applied to the collision system. Only three players have collision detection enabled at any time. Doing so improved the performance by 20%.

You may say that doing so will reduce the aesthetics of the game, and you are right. However, when you play a soccer game, your eyes are mainly focused on the controlling player and the defender. Your vision ignores all other players' aesthetics.

I also improved the AI of the game. Supporter players no longer go out of bound whenever they search for a good passing angle. The same logic applies for defenders. They are smart enough not to go out of bound.

Additionally, I added a feature that controls the strength of the kick depending on how long you press the game buttons. The longer you press the buttons, the stronger the pass; thus the farthest the ball will travel.

Implementing the 4-4-2 team formation

Up to now, I have been developing the soccer game with relatively few game characters. The reason was obvious. I was focused on implementing the properties of individual players and not the team properties.

However, this week I focused on implementing intelligence into the team as a whole. My first task was to apply "Formation" logic into the game.

There are several formations used in soccer. I decided to use the 4-4-2 formation. That is four defenders, four midfielders and two forwards.

The idea of a formation is the following:

When the team is in attacking mode, the formation should spread out; thus creating space.

In contrast, when the team is in defending mode, the formation should shrink; reducing space. Notice that no matter the mode, the team should always keep the 4-4-2 structure.

Since at any time, the game characters could be running towards a passing angle or defending positions, it made sense to implement separate game objects that serve as reference points for the players.

These game objects (formation objects) would spread out or come together depending on the state (attacking/defending) of the team. Each player is assigned a formation object and would use the position of the formation object only as a reference. The formation objects are shown as squares in the image below.

Doing so keeps the structure of team compact and resembling a 4-4-2 formation throughout the game.

Thanks for reading.

Computing Defending Positions-Soccer Game v0.0.3

This month I worked on implementing a bit of intelligence into the soccer game. The AI system can now determine the best position for a player to receive a pass. Alternatively, the system can also determine the best defending positions to intercept a pass.

The video below shows these implementations:

Computing Passing Angles

Passing angles are important concepts in soccer. Players are always scanning their surroundings looking for passing angles to reach. Passing angles is also an important concept for the dribbling player. If the dribbling player can spot a good passing angle, the chances of scoring a goal increases.

In the mobile game, I implement a method that scans 36 segments, each 10 degrees apart. Thus, forming a circle with the dribbling player at the center.

The system does interception tests of each segment against nearby players of the opposite team. If a segment intercepts one of these players, the segment is discarded as a passing angle. If it does not intercept a player, it is kept as a possible passing angle.

In the end, the system tries to select two segments whose angle with respect to the dribbling player is 45 degrees and 135 degrees, respectively.

The system then sorts the players closest to these segments and orders them to move to these passing angles.

Computing Defending Positions

Passing angles are not only important for a team who is in possession of the ball, but also for the defending team. As a defender, learning to read passing angles is crucial. And even more important is positioning yourself in a spot where you can intercept the pass.

The system determines defending positions by scanning the movement of the supporting players. And orders the defending players to move towards the passing angle. However, the defending players do not position themselves between the dribbling players and the supporting players. Instead, the defending players stand between the supporting players and the goal.

Determining a Time Interval

In a soccer game, players are constantly scanning for passing angles and defending positions. In a mobile game, the AI system scans for passing angles and defending positions at a set interval. There is no point in scanning for these items continuously.

The key is to find a balanced time interval to compute these elements. If you make the time interval too long, you will miss good passing angles and defending positions. If you make the time interval too short, you will make unnecessary computations; since players don't move around instantly.

Unfortunately, there is no formula to find the best time interval. The time interval to compute the passing angle and defending positions is determined through experimentation.

Thanks for reading

Implementing a State Design Pattern for an A.I. System

As you may know, I decided to develop a mobile soccer game using my game engine. The reason is quite simple. I want to test the features of the game engine and hopefully find as many bugs as possible.

Developing a mobile soccer game has introduced me to the world of Artificial Intelligence. Although I am not an expert in A.I., I have learned a valuable lesson; An A.I. system uses a state machine, and this state machine should be implemented as modular as possible.

State machines are taught using if-then or switch statements. Although such implementation is OK for small projects, it also leads to spaghetti code in complex projects.

A better way to implement a State Machine is with a Design Pattern known as State Pattern. The pros of using such pattern are that your State machine becomes modular and flexible. That is, you can remove or add as many States into your code without making it a chaotic mess.

Let me show you how to implement a State Pattern.

Note: You can download the project on my Github page so you can follow along.

Create an Abstract State Class

First, implement an abstract State class as shown below:

Abstract State Class

class StateInterface {

public:

    virtual ~StateInterface(){};

    virtual void enter(Player *uPlayer)=0;

    virtual void execute(Player *uPlayer, double dt)=0;

    virtual void exit(Player *uPlayer)=0;

};

The "execute" method will perform your "State" operations. The "enter" and "exit" methods are useful methods in an A.I. system. For example, you may have a 3D model that as it enters the "state", it waves his hand. Or it performs a goodbye gestures as it exits the "state."

Implement the concrete State Classes

Then, implement the concrete state classes. In this instance, let's implement a "Walking" and "Running" state class.

Walking State class

void WalkingState::enter(Player *uPlayer){

    std::cout<<"Player entering Walking State"<<std::endl;

}

void WalkingState::execute(Player *uPlayer, double dt){

    std::cout<<"Executing Walking State"<<std::endl;

}

void WalkingState::exit(Player *uPlayer){

    std::cout<<"Player exiting Walking State"<<std::endl;

}

Running State class

void RunningState::enter(Player *uPlayer){

    std::cout<<"Player entering Running State"<<std::endl;

}

void RunningState::execute(Player *uPlayer, double dt){

    std::cout<<"Executing Running State"<<std::endl;

}

void RunningState::exit(Player *uPlayer){

    std::cout<<"Player exiting Running State"<<std::endl;

}

As explained earlier, the "execute" method is the heart of your State operation. It is in this function where most of your logic resides. Moreover, this method will be called continuously until a change of state occurs.

You may notice that the States are implemented as Singletons. You don't have to implement the State classes as singletons, but I usually do.

Implement a State Manager

The State Manager class is responsible for changing the states and keeping track of previous states. This is shown in the snippet below:

State Manager Class

void StateManager::update(double dt){

    currentState->execute(player, dt);

}

void StateManager::changeState(StateInterface *uState){

    //keep a record of previous state
    previousState=currentState;

    //call the exit method of the existing state
    if (currentState!=NULL) {
        currentState->exit(player); 
    }

    //change state to new state
    currentState=uState;

    //call the entry method of the new state
    currentState->enter(player);

}

Before changing to a new state, the manager keeps a copy of the current state. It then calls the "exit" method of the current state. Changes to the new state and calls the "enter" method of the new state.

After the "changeState" method has completed, the manager enters the "update" method, where it continuously calls the "execute" method of the current state.

Putting it all together

Let's implement a simple class called "Player." This object will hold a pointer to the State Manager object. It will also contain a "changeState" and "update" method. Note that these methods delegate its operations to the State Manager member. See snippet below:

Player class

Player::Player(StateManager *uStateManager){

    stateManager=uStateManager;

}

Player::~Player(){
}

void Player::update(double dt){

    stateManager->update(dt);
}

void Player::changeState(StateInterface *uState){

    stateManager->changeState(uState);

}

Finally, let's put the State Pattern in action.

In the "main" function, let's create a state manager object, a player object and let's change the player object state as shown below:

main() Method

//Create a State manager object
    StateManager *stateManager=new StateManager();

    //Create a player object
    Player *player=new Player(stateManager);

    //Change the state of the object to a RUNNING state
    player->changeState(RunningState::sharedInstance());

    //call the update method
    player->update(1.0);

    //Change the state of the object to a WALKING state
    player->changeState(WalkingState::sharedInstance());

    //call the update method
    player->update(1.0);

When you run the project, the output window will show the player entering, executing and exiting the state as shown below:

• Player entering Running State
• Executing Running State
• Player exiting Running State
• Player entering Walking State
• Executing Walking State

If you want to add a new state, you simply create a new state class, without having the need to modify the if-then/switch statements commonly used in state machines.

State Patterns make the implementation of a state machine very flexible, modular and clean. If 100 years from now, you need to add more states to your project, you won't have to modify the inner workings of your application. Instead, you just create new state classes.

Hope this helps