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

111–120 of 151 posts

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

#111

Post by drawkbox »

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.

I agree and like your style.

Messaging is ideal for decoupling, sending/receiving data and it makes networking parts of the game much easier.

Every game engine or system I use I set it up this way. I always make my components or entities data backed so when people say you can't have data-oriented in GameComponent systems it seems they haven't done much game development. I usually have most of it in JSON and in previous engines INI was popular (Unreal still uses this for some and lots of custom engines). I have always separated data from the objects, lots of people do not and that is why this is a major debate along with all the talk around it due to Unity adding their ECS. Data should always be separate from code and hopefully merged at runtime.

The benefit of ECS is performance alone and usually only really needed for high performance real-time or physics heavy games for parallel performance and essentially pre-optimized for batched mutations or changes, everything else can be done across the same from messaging to data backed entities/objects/components and more.

I do wish engines were better as abstracting these elements away. Lots of the systems start leaking into the engine which is supposed to abstract these elements away in a good pluggable/versioned/atomic game engine.

Like what Garry said about Unity [1], too many things are leaking up to the game developer creating all these debates and issues and incompatibilities. The fact this isn't just a switch or setting to switch from GameComponent to ECS is a problem. Same with incompatible renderers and more, those should be wrapped and pluggable with the same surface level method signatures and objects. Underneath is where all the tech needs to go. Leaky abstractions are a problem across the software world right now.

Atomic systems with facades that wrap complexity and are able to be swapped beneath the surface are fading and making things more complex than needed. The job of engineering is taking complexity and making it simple, not the other way around.

[1] https://garry.tv/unity-2020

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

#112

Post by turndown »

hypertele-Xii wrote: post #95
Kiro wrote: post #26

Earlier quoted context omitted.

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 ob…

In this context, what do you mean by sparse? Simply that similar data is not packed together?

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

#113

Post by Athos_vk »

bogwog wrote: post #68
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 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…

I would say it is 100% not Unity's fault. As someone else posted, there's a t-machine blog posted and that entire blog has been filled with ECS with that specific term for years. But aside from that it has been a heavily discussed thing for many years in the gamedev scene. There's a wikipedia page on it, showing a bit of history from well before 2017, but you will find most on it on gamedev.stackexchange and gamedev.net. It probably predates the start of Unity in its entirety.

Also, to be fair, they really do refer to it as DOTS -> Data Oriented Technology Stack (granted, it includes more than just that), but I'm not sure if and when they changed that. Their community just seems to keep calling it ECS regardless.

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

#114

Post by rahkiin »

gurkendoktor wrote: post #93
bogwog wrote: post #79

Earlier quoted context omitted.

> 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 ti…

The player can be just one component, until you split things to reuse them.

But imagine a simple 2d game: whag are you reusing on a lot of entities? - collision size - sprite to render and render properties - position on grid - maybe also a velocity, maybe an acceleration

With ECS it becomes trivial to make a system that iterates over all entities with a sprite and a position, and draws them. Another system can adjust the position with the velocity. Notice how we can create non-moving entities by not having the velocity component at all. Also notice how we can easily add a rendered sprite to any entity without changing any code.

I know this scales well as it gets more and more popular also for larger games.

Bonus: This data is all located together so iterating over Sprite+Position is very cache friendly. And if a system only reads and writes data to the entity jt can also be parallelized.

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

#115

Post by Agentlien »

The article makes more than a few baffling statements beyond the core argument regarding ECS.

The claim of Godot having similar tools as other engines certainly caused me to raise an eyebrow.

The strangest in my mind, however, is trying to downplay the importance of the performance advantages by claiming games with many objects are rare. I currently work on optimising a game which falls somewhere between indie and AAA. We have thousands of objects active at any given time.

I also dislike the statements regarding compute. I love compute shaders and use them whenever I can, but they're basically unusable from a performance perspective on both mobile platforms and Nintendo Switch.

(Edited from a Reddit comment I made regarding this article)

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

#116

Post by [deleted] »

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…

[deleted]

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

#117

Post by apineda »

hertzrat wrote: post #107
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…

Not about ECS, but speaking of components: I’m developing an unreal engine game and component based programming has been a dream. You end up with the opportunity to create so many pieces of code that are able to be dumb and that don’t need to know about the rest of the system. Then you add come control code that is also as dumb and blind (in a good, decoupled sense) as possible and the whole application comes togethe…

I'm curious about emergent problems that are difficult to diagnose with many systems operating seemingly independently. Systems interacting in odd ways, and ordering of systems (dependency ie one system MUST run before another). Do these come up?

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

#118

Post by w_t_payne »

Athos_vk wrote: post #113
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…

I would say it is 100% not Unity's fault. As someone else posted, there's a t-machine blog posted and that entire blog has been filled with ECS with that specific term for years. But aside from that it has been a heavily discussed thing for many years in the gamedev scene. There's a wikipedia page on it, showing a bit of history from well before 2017, but you will find most on it on gamedev.stackexchange and gamedev.…

DOTS is not ECS. "Unity Classic" is ECS. DOTS is a more cache-efficient architecture designed to support larger numbers of entities.

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

#119

Post by moron4hire »

The Entity-Component system is not really about composition over inheritance, mostly because "Inheritance vs. composition" is not an either-or choice, but also a little bit because Entity-Component is not really even the best way to perform composition, if greater composability is your only goal.

The choice of inheritance vs. composition is not a dichotomy, it's a spectrum. There are certain properties of your program that are better modeled through inheritance, and others that are better modeled through composition. You end up using both in the vast majority of systems.

Classical object-oriented GUI frameworks have a Button class that inherits through a chain of classes that add greater refinement of behavior. See [0]: System.Object -> Component -> Control -> ButtonBase -> Button.

But you don't create such a hierarchy for something like a login form. A login form will inherit from Form [1] and use composition of subcontrols to create its behavior. You'll have a few textbox controls, a few labels, and a couple of buttons composed with the login form.

And neither is an Entity-Component system really all that great of a composition system. You end up having to query the system for cross dependencies at runtime a lot, as there are no compile-time, static guarantees that any particular component will exist. Something like Inversion of Control with Dependency Injection can give you a better workflow for getting dependent components together in the same place.

Incidentally, building a project in an Entity-Component system (or any composition-based system) does not prevent one from being able to utilize inheritance, either. I'm not even aware of any composition systems that don't use inheritance heavily, actually. For example, Unity's ScrollView [2] component has the chain System.Object -> CallbackEventHandler -> Focusable -> VisualElement -> ScrollView.

An Entity-Component system is really much more about creating ad-hoc objects. Game design is notoriously finnicky. There is no schema or "shape" of fun. You tweak and reorganize and tear apart and recombine things until it just "feels" right. So Entity-Component makes it possible to create and compose objects on the fly, with fairly reasonable performance.

So these statements like "I turned away from inheritance 20 years ago and I'm now all about composition", they just don't make sense. "Inheritance vs. Composition" is not something you think about at the application level. It's something you think about at the functional unit level, and make the choice separately for every functional unit.

[0] https://docs.microsoft.com/en-us/dotnet/api/system.windows.f...

[1] in WinForms that'd be: System.Object -> Component -> Control -> ScrollableControl -> ContainerControl -> Form

[2] https://docs.unity3d.com/ScriptReference/UIElements.ScrollVi...

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

#120

Post by hertzrat »

apineda wrote: post #117
hertzrat wrote: post #107

Earlier quoted context omitted.

Not about ECS, but speaking of components: I’m developing an unreal engine game and component based programming has been a dream. You end up with the opportunity to create so many pieces of code that are able to be dumb and that don’t need to know about the rest of the system. Then you add come control code that is also as dumb and blind (in a good, decoupled sense) as possible and the whole application comes togethe…

I'm curious about emergent problems that are difficult to diagnose with many systems operating seemingly independently. Systems interacting in odd ways, and ordering of systems (dependency ie one system MUST run before another). Do these come up?

You’re right, they do. You add a layer on top that is in charge of worrying about those interactions, and it works pretty smoothly in my experience, but even then there can be some challenges from multiple pieces of code trying to use that controller code to do contradictory things. But I think you end up in the same situation with all big apps, and in this setup at least some of your code is still easy to reason about. It’s still several layers of abstractions. Command pattern with a good entry-in-progress-exit lifecycle is another system to add on top that helps things stay flexible and easy to work with later on
Post reply on HN