GED Blog #4 - Game Engine Design Fundamental

Game engine is designed to create games for developer. It often handles various data for different purposes such as calculating physics, displaying models, or playing an audio, etc.. Although each task can have a manager to deal with all sort of related tasks, things might get slow when the CPU has to constantly jump between different classes. Therefore, we talked about how to optimize the game engine by organizing the data in a better way during one of the lectures.

Nothing helps to explain things better than using an example. Therefore, we analyzed Mario Kart and saw what kind of data an engine had to deal with and how could we structure them in a way that it would be easy for the engine to handle.

Firstly, let's examine the things that are going to appear in the game. There are karts, map, and items, and each of them has some components.

Each kart would have physics, some attributes, and the mesh; each map would have mesh, collision detection, and triggers for events; and there are also items in the game that have mesh, and behaviour since they would perform different effects. So, now we know what data is there, but how are we going to sort them? Well, according to what we have, we would store them into an array like the following.

Let's say there are 4 karts, 4 maps , and 2 items. Each [] would store each object's component's data. However, since we want to optimize the engine, we would have a game object manager to handle all these components because since different objects would share the same component, it would be more efficient to group them together in an array and update them all at once rather going into each object and update them because it will significantly reduce cache thrashing allowing the CPU to just process a steady stream of data. In that case, instead of listing what kart, map and item have, we would list game object has mesh, physics, attributes, etc., and make an array for each of them.

The physics component array.

The mesh component array.

The attribute array.

Other components such as collision and behaviour would also follow the same format. Then, it will easier for the engine to update them because by updating an array, it updates all the same component in the scene, which is so much easier. The coding for it can be something similar to the following.

It checks and update each object that has the component of physics, but bewared of 'if' statement because it is bad for something that has to update all the time. We can also use it to update the mesh using component->draw();

DOP & DDP

The above methods are called Data Oriented Programming, aka DOP, where developers focus on designing the structure of the code. There are another similar method called Data Driven Programming, aka DDP, where developers try to remove as much code as possible to favour datas, allowing them to have more space to do whatever the users want them to.

Hopefully in the near future I will have more time to look into them and see how they can help game engine achieve different things, but before that, I will conclude my blog here.