[dkersten]

ECS is entrenched in rogue development in general, at least going by r/roguelikedev. It (or at least a component architecture, if not fully blown ECS) seems to be a good fit since these style of games tend to have a lot of composition (in items, effects, behaviour).

Personally, while my experience is a bit limited, I quite like the ECS style. It just makes logical sense to me as a way of composing entities from different parts. The implementation details (cache friendliness or whatever) are not important to me since I've never made anything of a scale where it matters, but that style of developing/designing how things act and interact is logical to me personally. I haven't watched Bob Nystrom's talk yet though (or, actually, I may have, it seems familiar, but I don't remember any details. I plan to watch it tonight).

With that said, many people find the Godot style more natural and it certainly is nice too.

[dkersten]

So after watching Bob Nystrom's talk: I have actually seen it before, its a very good talk and I definitely agree with him and with his solutions. But, as he even says himself, its not a replacement for ECS if you need that kind of complexity, just that for what he was doing its overkill and that depending on what you're doing it may also be overkill, and that his simple solutions solved those particular problems really well for him, in a way that is much simpler than ECS. I completely agree with that.

Of course, he didn't go into much detail about when you might need an ECS other than "when you have something graphically complex" (paraphrased), I would extend that to include: 1) when your entity modelling is becoming a performance bottleneck, 2) when your entities are becoming complex enough that you want to have anything become anything; you could build on what he proposed to make this work by making more complex and flexible components but at some point using an ECS may well just save on effort, especially if you use an existing one like what Bevy has or EnTT in C++, 3) your logic can naturally decompose into systems that operate on sets of components and you have a lot of components to operate on.

In all three of my additions, scale is a factor. If you only have 10 entities, then you can solve all 3 with less effort in other ways. Similarly, if you only have 10 components or 10 systems, its not such a big deal. If you have tens of thousands of entities, a hundred components and a few dozen systems, then an ECS is probably the right choice.

For me, I like the ECS style. I also like the solutions proposed in his talk. I'm also not planning on writing my own ECS ever but using existing ones (I've tinkered a lot with EnTT in C++).

[codetrotter]

I’ve not yet used Godot. What is the Godot style like? And are there some documents about it and example code of it?

[meheleventyone]

Godot uses a hierarchy of nodes, you can think of it as one step further than entities being composed of components. The hierarchy and how nodes operate on it define the game. In practice though you end up with things that look very entity like IMO so it’s not that different.