Add entity component system in cocos2d-x

cocos2d-x
#81

Each component has a static cid, since components are stored in an external array…

#82

Thanks.
It is more efficient to have an id.

PS: i also added comments of Unity at top of the thread. I am not familiar with Unity, so please correct me if there is something wrong.
Thanks.

#83

this.
productivity - performance tradeoff and correctness in top of it

#84

Unity gets around this by not calling methods if they do not exist. For example, if your script does not provide a FixedUpdate method, then it won’t be called. The downside here is that if you provide an empty method, it will get called, so you have to make sure you clean up your code and remove any empty methods, to avoid wasting cpu.

This is a result of the engine (and the compiler) not being able to discern an empty method and remove it. This is why I think an explicit opt in is better than brute force, or opt out.

#85

@zhangxm

I edited a little bit the post with the description.

#86

How did it resolve it?
Do it in compiling phrase to determine it?

#87

Thanks.
It looks better.
And i will continue to add comments of other systems.

#88

C# has reflection, so they can tell if a method exists at runtime, but not whether it is empty or not.

#89

Today I reviewed entity-x, entity-fu, read Ray Wanderlich post and Misconceptions of Component-Based Entity Systems.

My take is, if we want to implement a high performing ECS (and must do it with performance in mind):

Entity-x seems to be a complete implementation, with performance in mind. Entity-Fu seems to simpler, but on the other hand seems to be easier to understand.
Both of them are complete ECS, they are not just “Component Based Architecture”.

Tomorrow I take a look at Godot and re-read Apple’s.

1 Like
#90

But it also need to check it in runtime, right?
And it will cost CPU time though i am not sure how it will cost CPU.

#91

it should be way more efficient to call a virtual in C++ than using C# reflection to see if a method exists

#92

Yep, entity-x is a full ECS, it uses templates everywhere. It is hard to understand. All the same type of component are memory continues, because components only include POD.

I think ECS is a kind of Component Based Architecture. It is a special CBA.

After reading Ray Wanderlich post, i think the benefit of CBA are:

  • Put related codes together. For example, can put physical related codes together.
  • Can enable/disable a feature in runtime.

But if there is a system to work together with components, then it will be more powerful.

#93

This site collects many useful information about ECS.

1 Like
#94

personally I do not like t-machine articles neither Artemis approach. There are a lot of performance loses with Artemis implementation. You can have a look but it is not a good ECS.

I would recommend instead bitsquid blog:
http://bitsquid.blogspot.com (see 2014 posts)

1 Like
#95

I haven’t look into Artemis yet, but could you give some examples why you don’t like the articles, the Artemis approach and what the performances loses are?

I’m curious what Autodesk makes out of Stingray(after their acquisition of bitsquid).

#96

In a CBA approach, the “component” and “system” are coupled. The behavior is defined in the component.
In a ECS, there are entities, there are components, and there are systems. the components are just POD, and the systems are in charge of dealing with the PODs.

If implemented correctly, ECS should perform faster than CBA due to the data locality and no virtual functions… perhaps it uses less events/callbacks as well.

Thanks. I’ll read it today.

#97

I might sound a bit rude saying is “not a good ECS”. I should have say is not performant enough :stuck_out_tongue:

Artemis is based in Java and the C++ implementation I saw some time ago had the same sin: Components are virtual stuff, denying a lot of goodies from ECS. They also rely on using hashmaps and other containers which are really bad for cache coherence to access components.
There were more bad stuff but I can not remember. I will rephrase what I said: is not a bad engine but you could design a way better ECS engine. If you are using any virtual in components then you are not designing an optimal ECS. Virtuals of course are ok in systems.

And t-machine.org readings are good stuff. But I remember the guy from t-machine went a bit too far with ECS, last readings sounds a bit like die-hard ECS (and ECS is just a design tool!). For example I remember disliking specially its bomberman example and some articles seemt a bit vague. When I coded my own ECS I found bitsquid articles way better and very clear. If you have time to carefully read through all the ECS stuff over the internet then yes, go for everything! But my 2cts is to focus instead on better sources like the bitsquid one.

I’m sorry I can not bring strong data to support my feelings on this :smile:

BTW. @ricardo how are you planning to incorporate a pure ECS system to cocos2d-x while mantaining backwards compatibility? I mean, It would be really cool to have such a core for the engine but I’m curious on the compatibility stuff.

#98

Implementing a complete ECS in v3.x and being 100% backwards compatible seems to be challenge. For example, the Render System, cannot be a System in v3.x if we want to be backward compatible.
However we can say that the Render System is not a system, and people should use the Scene nodes instead. I don’t see that as a major issue…

The physics system is another thing that seems to be impossible to implement without breaking compatibility. Currently the Physics2D code is hardcoded in Sprite.

I’m not sure yet, since I want to do more research on this, but my feeling is that for v3.x a Component Based Architecture would be better our users. And for v4 implement a complete ECS.

1 Like
#99

Do we want it to be? :smile:

So there are two options:

  1. Keeping backward compatibility at all costs, but being limited in
    evolving the engine to the next level
  2. Drop the backward compatibility and enable all the voodoo and magic

I would love seeing that 3.x will be 1 and 4.x will be 2., but I guess this is just an option for 5.x.

#100

I am going to bump my previous post and state that we should leave all the nodes in place and implement a set of components that work with Node in parallel. We can deprecate the old nodes and migrate to the CBS version over time.

1 Like