Building an Efficient Game Engine with OpenGL: The Power of ECS

yuv — Mon, 15 Jul 2024 00:42:00 +0000

I've continued developing my engine and added:

A physics engine
An improved interface
The ability to add objects to the scene dynamically
The ability to change the transformation (position, size, and rotation) of objects in the scene dynamically
An Entity Component System (ECS)
Local lighting and multiple lights
Shadows

Each of these features is interesting and could have its own dedicated post. However, in this post, I'll primarily discuss ECS, which stands for Entity Component System.

ECS

An ECS is a system for managing entities that allows you to create entities composed of individual components.

In the simplest and most practical terms, let's assume we have a computer game. Instead of creating a class for a character in the game that represents the character, we do not create a class. Instead, we take each component that belongs to the character and add it to the entity. This way, the entity is composed of its smaller parts and is not definitively defined, allowing us to add or remove components as needed.

The system allows users to create entities, destroy entities, save them, and get all entities with a specific attribute, such as all entities that can be drawn on the screen.

The problem this system aims to solve

this system aims to solve multiple inheritance. Let's say we have a game with a character and a character class in the code that describes many details about it. Within the class, there are relevant fields such as the 3D model of the character, speed, weight, and any other parameter we want the class to contain.

So far, everything is fine. Now, let's assume we want to create a character with a parameter that doesn't exist in the original class, and we want to keep the original character class (without changing it) and also add new attributes to the class. We would use inheritance and inherit the fields and functions from the original character class to the new character class, or we might even create a parent class from which every character with different parameters inherits.

Theoretically, this solution is correct (it works), but it's not scalable. In a situation where we have two characters with different parameters, we would need to maintain two different classes. But what happens if we have 20 different characters? It's the same code in all those classes (which is why we used inheritance to avoid code repetition), but each has slightly different attributes. If we think of these attributes as components, it would be nicer if, instead of inheriting, we assembled an entity from all those components that differ between the classes.

That's essentially what such a system does. It allows us to group components and treat them as an entity. Based on the different components that the entity has, we know how to interact with it (we don't have a class or an instance for the entity, we don't know what this entity is, but we know what components it contains and interact with it accordingly).

Such a system implements the composition design pattern. I attached a video for those interested, showing concrete code examples of how switching to composition makes the code more readable, maintainable, and workable.

What you can see in the video:

At the beginning, you can see me moving the red cube using the widgets that appear next to it when it is selected. In this scene, you can also see the shadows moving with the cube. When I press play, the scene starts running, and the physics engine kicks in, causing objects to fall to the ground.

Around the objects with physical properties, like the floor and the cubes, green lines appear when play is pressed. These are for debugging purposes.

Later, you can see me playing with local lighting, changing its colors and position. A few frames later, you can see what happens when a bunch of cubes are dropped and how their interaction looks, with some falling off the platform.

you can follow me for more at

x.com

Real-Time 3D: My Journey in Building a C++ OpenGL Rendering Engine

yuv — Sat, 13 Jul 2024 20:02:33 +0000

What is a Rendering Engine?

A rendering engine abstracts the process of drawing objects on the screen. It uses the GPU to convert logic (e.g., a 3D model) into a 2D image displayed on a screen.

Motivation:

I've always loved graphics, especially in video games. As a child, I was fascinated by how future graphics would look and how realistic they could become. Besides my personal love for graphics, it's a challenging field. The development of graphics involves interesting mathematical challenges (linear algebra) and requires efficient, optimized coding, often in fast "low-level" languages like C++.

Game Development:

Beyond the engine and its basic supported capabilities, I developed a scene/game - a kind of maze in a 3D world with impassable objects. I implemented the A* algorithm to find the shortest path between two points. The algorithm is an extension of Dijkstra's algorithm and is widely used in video games, such as finding a path between a player character and a target.

Challenges:

Implementing the algorithm was slightly challenging despite its simplicity. The algorithm searches a graph, but I didn't have nodes; I had a 3D world with infinite points. Therefore, I had to convert the world into nodes by defining squares on a map, with each point belonging to a specific square.

Optimization:

Deciding the size of the squares was critical. If a blocking object partially occupies a square, should the whole square be considered blocked? Reducing the size of each square increases accuracy but slows down the algorithm. For example, with a 64x64 grid (4,096 squares), reducing the square size by half increases the grid to 128x128 (16,000 squares), significantly impacting algorithm speed and data structure choice.

Debugging Tools:

OpenGL is a state machine, making it hard to debug or understand its current state. While it provides basic output for incorrect input, understanding why things don't appear on the screen as expected is challenging. Hence, I decided to develop visual debugging tools to display each square on the map, mark objects and their occupied squares, and visualize algorithm paths. This decision saved time by providing visual confirmation of what was happening on the screen.

Video Demonstration:

The attached video demonstrates dynamic lighting, various backgrounds and textures, model loading, and a scene with a sofa, computer, and other elements. Towards the end, a penguin aims to reach a bench along the shortest path. The A* algorithm is visually represented, with red nodes indicating closed nodes and green nodes representing the shortest path. The algorithm operates instantly, but the animation is intentionally slowed down for clarity.

Note: I later updated the interface, so the video is from before the change. Therefore, the images of the engine are different.

I will be publishing more of my journey, so you are welcome to follow me at https://x.com/yuvSouce.

DEV Community: yuv