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

71–80 of 151 posts

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

#71

Post by Vaskivo »

Jasper_ wrote: post #36
Vaskivo wrote: post #13

Earlier quoted context omitted.

While ECS means you're using a "data driven" approach, you can have a "data driven" approach without having to use ECS. It's all about having configuration data separate to the logic. And use this data to setup and build the game elements. Here's a couple of videos I created: How to start with Data Driven Development in Godot: https://www.youtube.com/watch?v=ZG__fXSp74c What I can do with it in my game, One Way Dunge…

ECS is commonly described as "data-oriented", not "data-driven". It's confusing, yes, but the have separate and unrelated meanings in the game development space. The former is a methodology for building engine systems that are cache-friendly, the latter talks about workflows that are more flexible to artists and developers. You can use ECS without "being data-driven", and you can use data-driven workflows without ECS…

> You can use ECS without "being data-driven", and you can use data-driven workflows without ECS.

True, I've read about ECS being used for one or both of those purposes.

My first contact was ECS was as a composability pattern. So, in a "high level" purpose, as an alternative to inheritance. It was also described as "Game Object - Game component" pattern.

See http://gameprogrammingpatterns.com/component.html, specially the sidenote in http://gameprogrammingpatterns.com/component.html#no-bj%C3%B....

There's the "performance" ECS, where it tackles data locality.

And the "game element definition and configuration" ECS, where it solves a high level problem of building game elements. On the "game developer" level, Unity works like this.

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

#72

Post by EamonnMR »

Waterluvian wrote: post #5

As a beginner not thinking too much about performance, ECS is beautifully elegant and easy to reason about. However I found it nearly impossible to integrate into libraries/engines that aren't made for it. I really wanted to use React for my complex RPG UI and PhaserJS or Pixi for I/O, but the state management paradigms just didn't work together (for me at least).

I feel your pain. I wanted to combine AngularJS and BabylonJS for a GUI heavy RPG but it proved impractical.

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

#73

Post by gurkendoktor »

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.

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://github.com/NoelFB/Celeste/blob/c32f134d210fcf710d750...

Say about the length of the file what you want, but isn't it actually better for caching that all of the Player's instance variables are in one object, and not stored in components somewhere else?

(Now, maintainability is another issue. But I've always found Ruby-style mixins much easier to reason about than the toy ECS systems I've seen.)

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

#74

Post by remram »

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 Godot is both. A lot of built-in nodes are meant to be extended (like KinematicBody) and a lot of them provide features via adding components (like RayCast or Area or Timer or AudioStreamPlayer).

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

#75

Post by tpxl »

zemo wrote: post #57
Wesxdz wrote: post #50

I'm developing a mobile game in Godot that would require thousands of nodes. The lowest hanging fruit optimization is simply ditching GDScript and nodes altogether for a C++ module or GDNative. ECS imo is a requirement for non-trivial games, and I don't think any game editor has it together here because of the tendency to prioritize accessible fast iteration in early stages over performance and scalability. So they s…

> the tendency to prioritize accessible fast iteration in early stages over performance and scalability well, I'm glad you're describing the way you see the tradeoffs, I just have a hard time seeing how hanging your hat on the ability to eek out every little bit of resource optimization at the expense of early iteration is a worthwhile tradeoff for the majority of gamedevs. Running the game at a worse framerate or re…

That counts for nothing if you have to rewrite everything from scratch 3/4 of the way in. Don't get me wrong, I like my iterations, but if your game runs at 20 fps it's simply not going to be good.

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

#76

Post by gugagore »

linkdd wrote: post #31
gugagore wrote: post #16

I might have an easier time following if there were some small code examples. For example, the article mentions that for simplicity some components require other components to exist. That sounds like something that cannot be encoded in the type system of most languages, whereas the fields present in classes within a class hierarchy are encoded in the type definition. A code example would help me figure out if I'm fol…

In C# and Unity, you have the class attribute "RequireComponent" which will automatically add the dependent "MonoBehaviour" when this one is added: [RequireComponent(typeof(RigidBody))] public class MyObject : MonoBehavior { /* ... */ } This is not really in the type system, but still, if your language provide some meta-programing features, it can help the developer makes sense of your code. This kind of dependency i…

I think I know the answer, but I'll ask explicitly.

Suppose we have two components: A and B. A is defined to `RequireComponent` B. If I do `has(object, A) && has(object, B)` then can the C# compiler compile away the check for B given the check for A, turning it into just `has(object, A)`?

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

#77

Post by ratww »

zemo wrote: post #57
Wesxdz wrote: post #50

I'm developing a mobile game in Godot that would require thousands of nodes. The lowest hanging fruit optimization is simply ditching GDScript and nodes altogether for a C++ module or GDNative. ECS imo is a requirement for non-trivial games, and I don't think any game editor has it together here because of the tendency to prioritize accessible fast iteration in early stages over performance and scalability. So they s…

> the tendency to prioritize accessible fast iteration in early stages over performance and scalability well, I'm glad you're describing the way you see the tradeoffs, I just have a hard time seeing how hanging your hat on the ability to eek out every little bit of resource optimization at the expense of early iteration is a worthwhile tradeoff for the majority of gamedevs. Running the game at a worse framerate or re…

The performance advantages of ECS are a bit of a red herring. There's not much of a tradeoff when it comes to speed of iteration.

The origins of ECS are in the work of Scott Bilas and Adam Martin, who weren't seeking performance improvements, but rather a way to allow non-technical teammates to iterate faster. This thing was revolutionary in the late 90s/early 2000s because suddenly you didn't need an army of increasingly expensive programmers just to get simple things done.

The performance boost was discovered much later when people found out that ECS could naturally benefit from data-oriented design. Performance is a nice-to-have but is far from being the raison d'être of ECS. It still makes sense to to have ECS or EC (or even just non-inheritance-component-based, like Unity) without the performance advantages of data-oriented design.

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

#78

Post by cztomsik »

TLDR the article says that nodes are just a "frontend" and the real work is done by backend which is data-oriented anyway.

tensorflow has python frontend and that is "slow" too, yet it doesn't matter because most of the work is done in C++ and python just compiles that graph to something lower-level

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

#79

Post by bogwog »

gurkendoktor wrote: post #73
DominikD wrote: post #44

Earlier quoted context omitted.

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

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.

That class you linked to is a mess because it seems like all state is mashed together into a single class. One way to clean this up is to implement an object-oriented state machine, so that state variables and logic are organized into classes instead of being a conditional soup in a giant update function. Here's a good article on that: https://gameprogrammingpatterns.com/state.html

But that game shipped and it worked, and that's really all that matters.

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

#80

Post by SigmundA »

dagmx wrote: post #8
SigmundA wrote: post #3

Earlier quoted context omitted.

Many engines have scripting languages allowing modding using full turing complete languages rather config files LUA is a common one in games. Its kinda like the config file vs code as config debate. If I where modding something I would rather have a full programming language than just a config file, but the config file does make it easy to do simpler things without breaking stuff, the more complex the config becomes…

To note though is that those config files aren't meant for modding. They're meant as easy ways for the gameplay designers themselves to tweak things without needing to rebuild the whole game each time. They just usually ship as side effects of that process, because no body really cares that much for single player games.

Usually scripting engines in games are there for the exact same reasons, moddability again being a side effect.
Post reply on HN