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
Top comments (0)