Creator has Game object model and not Entity Component System (ECS)?

[laser]

Now as I study more ECS I see that Cocos Creator follows approach after Unity GameObject model (or Component model) but not ECS.

At first I also did confuse these two, but now I have got more or less understanding of ECS, although I am not sure that I fully understand Cocos creator approach.

Some comparison of component model vs ECS can be found in this video:

Although devs say that Creator is ECS: Any tutorials for entity component system using Cocos Creator? :)

As far as I know even Unity does not provide true ECS and currently trying to actively develop into that directions. They have some steps on the way which is job system and etc, but it is not yet ECS as far as I know.

As well as they agree of performance degrations due to non-ECS approach (huge number of unnecessary update() methods): https://blogs.unity3d.com/2015/12/23/1k-update-calls/

That is why I want to clarify a little bit about cocos.

For ECS we need:

• Entity - empty object that role is only as a container for list of Components
• Component - data holding object (or sometimes empty if we use only class type for behavior change).
• Systems - place for update method that can change Entity structure and interact with corresponding components

Now cocos developers say that Components and Systems are united into “cocos component” and entity into node. But, is it valid to call it ECS now?

There shouldn’t be one-to-one correspondence between Systems and Components, for example, let’s say I have meteorites which has positions, moving randomly in 2d box and some of which are destroyed on contact. In total 100 meteorites, 5 normal, 5 destructible.

Then I will have Components: PositionComponent, DestructibleComponent.
Then 5 Entities with PositionComponentand 5 with PositionComponent and DestructibleComponent components.
And 3 systems:

• RandomWalkSystem which updates only PositionComponents
• CollisionSystem which iterates only Entities which has DestructibleComponent and compute collisions, remove Entity from list and/or split Entity into pieces of smaller size etc…
• RenderSystem which draws objects based on PositionComponents.

our update(dt) will have form:

update(dt) {
   RandomWalkSystem.update(dt);
   CollisionSystem.update(dt);
   RenderSystem.update(dt);
}

The efficiency comes from the fact that we can notify each needed system about Entity which adds corresponding component. Systems iterate only through entities that contain related components and avoid iteration over remaining.

Now returning back to cocos creator, I do not see how it is possible case for current implementation. I had 3 systems and 2 components, in creator on other hand components and systems are the same thing. Moreover, Node is and entity that not only has components but also positions, angles, etc – a pieces that should be moved to some system components.

Am I missing something? How to implement ECS with cocos creator if I am wrong with above. Thanks.

[jare]

Now cocos developers say that Components and Systems are united into “cocos component” and entity into node. But, is it valid to call it ECS now?
Now returning back to cocos creator, I do not see how it is possible case for current implementation. I had 3 systems and 2 components, in creator on other hand components and systems are the same thing. Moreover, Node is and entity that not only has components but also positions, angles, etc – a pieces that should be moved to some system components.

No. Actually, Creator is just node-component. We’re not going to support pure ECS at this time.
Do you really need ECS? In JavaScript, ECS is not as efficient they claim. Because it is very difficult to implement data-oriented design in JavaScript, and there is no multi thread support yet. ECS is an anti-pattern, it puts higher demands on programmers, it’s not appropriate for everyone.

[laser]

Do you really need ECS? In JavaScript, ECS is not as efficient they claim.

Yes, I am considering ECS because of only two reasons: clear design which helps programmers in the end, and efficiency (but that is measured only for C# and Unity). I have patterns and designs for game logic that is based on ECS approach. But during analysis and study cocos2d structure I see that it is in-applicable. Although probably I can simulate it (but with worst performance than expected). Or another approach is to forget about ECS, but the code and logic starts to look cumbersome (it always tends towards godclasses).

I have the feeling that cocos creator is very close. Just one step away from ECS. Obviously, I do not know about performance beforehand. The approach where systems calls only related components (and not every node/component update function) sounds more efficient to me.

Because it is very difficult to implement data-oriented design in JavaScript

I am using Typescript =) But what do you mean by that? data-oriented the whole point of Component and Node-Component also data oriented. Right?

ECS is an anti-pattern, it puts higher demands on programmers, it’s not appropriate for everyone.

Unfortunately, I haven’t heard about it as anti-pattern. Can you show example of it. I know only about impossibility to hide data (https://softwareengineering.stackexchange.com/questions/372527/isnt-an-entity-component-system-terrible-for-decoupling-information-hiding) but decoupling is a huge gain.

Moreover, I recently read a series of game designs/patterns from one company. https://pixonic.com/en
Unfortunately, it is only in Russian: https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fhabr.com%2Fcompany%2Fpixonic%2Fblog%2F413729%2F

Their arguments for ECS are quite strong. Obviously they are big company, with high level product and a probably a lot of code. Yet, what they explained as pros/cons looks reasonable. For example, for client they generate Unity project for designers to work, same code written with ECS they use to generate server-side logic (it is a 3d shooter, so you need compute damage, health, etc at server). Imagine you just switch off renderer system (and some other codes) and you can use same code at a server. They managed to make better object serialization to send over network. And serialization is simple because all data is in Components, which are pure data objects.

[jare]

I have patterns and designs for game logic that is based on ECS approach. But during analysis and study cocos2d structure I see that it is in-applicable. Although probably I can simulate it (but with worst performance than expected). Or another approach is to forget about ECS, but the code and logic starts to look cumbersome (it always tends towards godclasses).

Agreed. EC + S has a clear design, Cocos Creator is close to it. But when I said, ECS is anti-pattern, I was talking about the Pure ECS.
In Pure ECS, entity is just an id, it don’t have any data. Most components are lightweight, like NameComponent, RotationComponent, HealthComponent, …etc. You might split your datas into many trivial components for keeping memory(cache) friendly. The worse is, most systems are lightweight too, such as DragAndDrop_Pressed, DragAndDrop_Moving, DragAndDrop_Confirmed, … etc. You have to split your logic into many small systems, and use many dummy components for translating states triggered between those systems. Remember, you should also take care of the system’s execution orders. It seems Unity encouraged developers to use its ECS in this way, so I think Unity is kind of pure ECS.