Irrlicht and Entity-Component

[AReichl]

Hi,

lately i read about Entity-Component-Systems. My question is HOW to apply such a concept together with Irrlicht.
In Unity for example every Entity at least has a Position-Component (and more components for Movement, Physics, Sound, Rendering, ...).
In Irrlicht i would not know how to to that. The Position is stored in the Node, so unless i have the Position-Data twice (one set in Entity and another one in the Node) i would have to read them from the Node, change something and the write them back into the Node (Physics and Sound would be the same somehow). So far so good. But what about the Rendering-Component? That's the job of the SceneManager of Irrlicht. I cannot tell every Entity to draw itself because then i end up with writing my own SceneManager. Or i just skip the Rendering-Component and render everything the normal way (with drawAll()).

?

[chronologicaldot]

.... o_O
What's the point? It's usually best to use something in the way it was designed, and when you need to do something else, make a work around.
In a way, objects in Irrlicht do have a rendering aspect (or "rendering component" I suppose) - they control what happens when their render() function is called. The scene manager just sorts lists so everything renders in order. You can write your own implementation of ISceneNode for more control.
If you find the built-in scene manager too rigid, you may have to write your own. That's what I ended up having to do.

[REDDemon]

First note that Entity-Component is not always usefull and In fact it is actually overused many times.

You should try to use it in a simple game to learn how it works and then just put in your bag like any other pattern, of course it is a rather advanced pattern (like MVP) so it may take some time before you get grasp of it.

Basically you have Entity, Components and Systems.

Components are simply structs with Plain Old Data (float, int, char) that are really easy to serialize.

Entities are just logical groups of components

A System is just a specialized class, a sort of "method" that acts on multiple components instead of only 1.

When you look at pre-existing code you can probably find trace of something similiar, for example if you take the irrlicht videodriver and replace the "draw" method with a method that take a list of MeshBuffer and materials you actually created a ECS out of it (of course wouldn't be better lists are "collected" in automatic way?)

The ECS frameworks are actually designed in a bit smarter way of course, instead of passing around references of objects the system already provide to you reference to all components, infact this is the best advantage => you do not have to spare a lot of pointers around wich results in the fact you no longer need Reference Counting (you have only 1 reference inside the ESC framework) and you use less memory.

Of course it is not always possible to adapt a ECS system, in example it is possible to have a ECS scene graph, it is more convenient however having something like ISceneNodes of irrlicht, of course no one forbids you interact scene nodes with a ECS.

an ECS system is possible only when you can actually think a world made of indipendent compoents, it may be tempting to make for example a Component based rendering engine, but that makes no sense because actually Shader, Textures and Mesh are DEPENDENT components (in example a shader require a number of textures and a vertex format to work correctly), of course a "Renderable" can be a component of its own istead of trying to break it for no-sense.

It is usefull in a videogame, think to oblivion, you have many world objects, their aspect is indipendent by their item ID and their collision box, so actually even if the player see a sword on the ground it actually have 3 components:
Aspect,
Collisionbox
ObjectID
(eventually magic properties).


Also note that ECS usually can cause more bugs if used improperly (think to Minecraft creepers, wich developers says they were born from a bug, probably they attached the TNT component to a monster, I think it is more a urban legend but it give the idea about ECS).

If you can't think the world of indipenent components drive away from ECS