Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why isn't Godot an ECS-based game engine?

godotengine.org

Post reply on HN
Print view View original

91–100 of 151 posts

Re: Why isn't Godot an ECS-based game engine?

#91

Post by an_opabinia »

Jare wrote: post #59

I'm a bit confused between there's a hugely popular place between inheritance-based entities and ECS (Entity-Component-System), which is what you could call a "Entity-Component system) (notice spelling) or perhaps a Component-based entity composition system. Inheritance based: you derive Vechicle, then derive Tank, Car, etc. This was most used from 95 to 2005 as teams moved to C++. Component based: you create a Tread…

> I'm a bit confused between there's a hugely popular place between...

Godot is a Unity clone. Unity has copied a lot of things, including Flash (and therefore Shockwave), where this "attach scripts to stuff" architecture actually came from.

Re: Why isn't Godot an ECS-based game engine?

#92

Post by vvanders »

ephimetheus wrote: post #87
vvanders wrote: post #28

Earlier quoted context omitted.

Yup, "has a" vs "is a". From my experience in gamedev the former is a lot more common than the latter. Had an engine where each entity could only have one mesh object since it was a part of the base entity type rather than a component. Led to a lot of multi-entity shenanigans that were brutal from a sync/off-by-one-frame perspective.

Might be wrong here, but isn’t that also a limitation for most component column based ECS implementations? (I mean each entity can have only one instance of each component)

Depends on the ECS, most systems I've worked in will let you do two addComponent calls of the same type and then they'd just get added to the array of components to batch process. This is really common for mesh components (although there's usually mechanisms to specify dependency/ordering to avoid off by one frame issues).

Re: Why isn't Godot an ECS-based game engine?

#93

Post by gurkendoktor »

bogwog wrote: post #79
gurkendoktor wrote: post #73

Earlier quoted context omitted.

I've heard this so often, and I still don't quite get it. Let's say most of my game objects have a "Position" component, and all the X/Y coordinates are now in one big integer pool. With this setup I can now add 5 to each object's X position really efficiently. But what's the use case for that? Particle systems, and what else? My game objects always look more like Celeste's Twitter-infamous Player class: https://gith…

> With this setup I can now add 5 to each object's X position really efficiently. But what's the use case for that? Particle systems, and what else? Physics, AI, animation, etc. A player controller is not a good candidate for that type of optimization because they tend to have very complicated logic that needs to interact with many different game systems. Also, you don't usually need to have more than one or a few. T…

> Physics, AI, animation, etc.

That sounds good, but how would this look like in practice? For the sake of simplicity, let's assume I write a 2D game with classic spritesheets for animation frames. With an ECS, I can pool the animation state of each object into the animation system, and basically execute "anim_frame = (anim_frame + 1) % num_frames" for all objects in one speedy loop.

But game object animations are tied to game logic, and as soon as an object depends on its anim_frame in logic that is outside of the animation system, the cache benefits are moot.

Maybe I'm not thinking big enough in terms of how many "dumb" objects are in the game in proportion to the ones that have lots of logic (like the player).

Re: Why isn't Godot an ECS-based game engine?

#94

Post by johnnycerberus »

teamonkey wrote: post #58
johnnycerberus wrote: post #35

Earlier quoted context omitted.

Yes, I understand that ECS is probably good for more low-level stuff like particle-like systems. But what about gameplay-code? Unity ECS is mostly about that, to think in a data-oriented way about your gameplay programming. The thing that bothers me is why huge commerical engine like Unreal Engine or idTech don't even lift a finger about that? About structured column databases, the same thing could be said about Lisp…

> why huge commerical engine like Unreal Engine or idTech don't even lift a finger about that? https://docs.unrealengine.com/en-US/ProgrammingAndScripting/...

But according to the documentation, that is just a OOP-hierarchy in which they separate the concerns, they miss the S in the ECS.

Re: Why isn't Godot an ECS-based game engine?

#95

Post by hypertele-Xii »

Kiro wrote: post #26
Tyr42 wrote: post #19

Earlier quoted context omitted.

Hmm, if you only have one system, then yes, those are the same. But if you have multiple systems (say collision detection, physics, damage/health, control(ai or player)) you can then build things up lego brick style. For example, a basic wall will just participate in the collision detection system and nothing else, but now it's easy to add in breakable walls by giving them a hp value and defence value for the damage…

Yes, thank you! It certainly seems like a good and flexible way of structuring your game but I still don't understand where the performance benefits the article speaks of come from.

JavaScript gains no performance benefit from ECS because JS arrays are dynamic and sparse. The performance benefit comes from dense, contiguous data (structures of arrays, instead of arrays of structures) in languages that allow that.

Consider the difference between:

  object 1
    property A
    property B
  object 2
    property A
    property B
and:

  property A of object 1
  property A of object 2
  property B of object 1
  property B of object 2
If you need the property A for all objects, in the first example we have to jump over the property Bs. In the second example all property As are next to each other.

Re: Why isn't Godot an ECS-based game engine?

#96

Post by beaconstudios »

djur wrote: post #69
bogwog wrote: post #68

Earlier quoted context omitted.

I know what you mean, and that confusion is 100% Unity's fault, because they call their data-oriented entity system "ECS". Back in the day, composition was referred to as "component-based entity systems", which makes perfect sense. But then Unity came in and called their data-oriented one "entity component system" for reasons I will never understand. Why not just call it "data-oriented entity system" or something lik…

The confusion is worsened by people interpreting it as "[an] (entity component) system" or "[an] ((entity) (component)) system", when it's actually "[an] Entity–component–system [architecture]". That is, it's not a system of entities and components, it's an architecture comprising entities, components, and systems.

it's not surprising given that "entity component system" is synonymous with "thing behaviour environment". It's using the most meaningless generic terms possible. It's like when companies use a tagline like "using innovative practices to deliver results for our clients".

Re: Why isn't Godot an ECS-based game engine?

#97

Post by johnnycerberus »

jbluepolarbear wrote: post #41

I don’t like ECS because it always conflates to using components as messages for systems that have nothing to do with Entities. I much prefer using a message system. A message system can quickly abstract the engines view from the core logic of the game and allow for the messages to be dispatched across network making networked games easier to work with.

Can you give an example of a message system for game dev? Do you mean something similar to message passing in Erlang?

Re: Why isn't Godot an ECS-based game engine?

#98

Post by georgeecollins »

Jare wrote: post #59

I'm a bit confused between there's a hugely popular place between inheritance-based entities and ECS (Entity-Component-System), which is what you could call a "Entity-Component system) (notice spelling) or perhaps a Component-based entity composition system. Inheritance based: you derive Vechicle, then derive Tank, Car, etc. This was most used from 95 to 2005 as teams moved to C++. Component based: you create a Tread…

I think it is more inheritance than ECS, but not religiously OOP.

Having used Unity and Godot, I really like the architecture of Godot. But Godot is not nearly as fully functioned (yet).

Re: Why isn't Godot an ECS-based game engine?

#99

Post by sitkack »

EamonnMR wrote: post #70
willvarfar wrote: post #2

I first met ECS when modding an RTS called Tiberian Sun. The units were all defined in ini files and you specified the components for each unit eg the difference between a building and a moving piece was whether there was a movement component etc. And a small but vibrant modding community grew up around it. Everything was dynamic, read from data definitions when the game loaded. One downside to godot’s inheritance is…

Tiberian Sun's technology is really unique and cool and I wish they'd open source it so I can see how they did everything. The 2d lighting really have it a distinct atmosphere.

Approach it like a mid 90s demo coder. Alphas, light maps, shadow casting.

The coolest 80s trick was rotating the palette to get moving water.

Re: Why isn't Godot an ECS-based game engine?

#100

Post by sitkack »

DominikD wrote: post #44
samwestdev wrote: post #18

I don't really understand what's the advantage of ECS compared to OOP composition. Anyone here can shed some light on the matter?

Short story: data is aligned in a way that favors batch processing. Less branching, great setup for SIMD or GPU processing.

It also translates to a relational model, selection, join and projection.
Post reply on HN