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

81–90 of 151 posts

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

#81

Post by mhh__ »

bogwog wrote: post #51

I'm going to have to give a hard disagree. I've been making my own engines for a long time, and have used many different engines for a longer time. Inheritance-based entity systems are often a pain in the ass to work with, a massive pain in the ass to debug, and tend to invite shitty hacks to get around the shortcomings of the inheritance model. The article says that "Godot does composition at a higher level than in…

So what does Jai do that is different?

For performance at least my focus is usually on eliminating information-lossy interfaces i.e. try to keep the hot loops where the compiler can see them

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

#82

Post by UnpossibleJim »

yellowapple wrote: post #63
Shorel wrote: post #34

Earlier quoted context omitted.

From the article: Using ECS Nothing prevents you to use an ECS solution in Godot. In fact, I strongly suggest to check Andrea Catania's fantastic work on Godex, which aims to bring a high performance ECS pluggable implementation.

That paragraph really should've been the focus of the article, front and center - and from there an explanation on why it ain't built-in.

I'm a fan of Godot, so I'll state that in the beginning, so I'm biased. But I took a look at her(?) GitHub page and wondered why there isn't more effort being put into this branch. Even from his own words, ECs is a more efficient style when a large number of objects/nodes are involved, or when optimization becomes important.

At the moment Godot is really only viable as a 2D engine, as it tends to bog down when used as a 3D game engine even though it has all but replaced the default Blender engine (their recommendation). So in order to get a viable 3D project, a user would have to use an experimental ECS version (no offense to the creators, they are working hard and I do have high hopes for this project. I'll most certainly be experimenting with it) using the C# version, which is still fairly new.

Now, the fact that a small group of devs can make an indy project/proof of concept with Blender and Godot, or students can make a group portfolio that is viable - these things are AWESOME. Granted. But it still comes out of a quasi Frankenseinian lab as they have chosen to go with OOP instead of ECS, it seems, even though a path does seem laid out before them.

P.S.

here's the link to the ECS project:

https://github.com/GodotECS/godex

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

#83

Post by linkdd »

gugagore wrote: post #76
linkdd wrote: post #31

Earlier quoted context omitted.

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)`?

Unfortunately no.

IIRC, all "RequireComponent" does is allow you to omit the "add(object, B)" when you "add(object, A)".

A simple example of this is when you add A to the object, then edit A to require B. The Unity Editor won't add B automatically (which is in fact a pain).

NB: removing A will not remove B, and B won't be replaced if it existed before.

I usually use "RequireComponent" whenever I have a "GetComponent()" in my behaviour just to make sure I have an initialized value.

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

#84

Post by lxdesk »

bogwog wrote: post #51

I'm going to have to give a hard disagree. I've been making my own engines for a long time, and have used many different engines for a longer time. Inheritance-based entity systems are often a pain in the ass to work with, a massive pain in the ass to debug, and tend to invite shitty hacks to get around the shortcomings of the inheritance model. The article says that "Godot does composition at a higher level than in…

Godot doesn't expose inheritance to scripting AFAIK; it's strictly a convenience used internally to describe the core nodes. When you script Godot to make complex entities, it's through composition of arbitrary nodes in arbitrary hierarchies, often encapsulated as scenes. References are mostly done by relative path, and the scripting language has sugar to make this a convenient process.

So, yeah, try it. It's the best system I've encountered for the general-purpose use-case, and I've designed a fair few myself.

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

#85

Post by dividuum »

jonhermansen wrote: post #64
johnnycerberus wrote: post #25

Earlier quoted context omitted.

Kind of providing an ECS-based game pre-2016, before Factorio, Minecraft Non-Java, They Are Billions and Overwatch (as I was told in a comment) got released?

For anyone curious to know more about usage of ECS in Overwatch, check out this GDC talk from one of the developers: https://youtu.be/W3aieHjyNvw

Awesome talk. Thanks for linking.

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

#86

Post by jasonwatkinspdx »

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…

Cosigned. I did level design on a game in the Unreal 1 era. The cosmic inheritance hierarchy was a regular annoyance.

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

#87

Post by ephimetheus »

vvanders wrote: post #28
jvanderbot wrote: post #14

Personally, deep object ontologies make my eyes glaze over. Its not like these objects evolved in the wild and their ancestry is somehow interesting. Give me interface definitions any day. ECS is nicer for that.

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)

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

#88

Post by JesseMeyer »

mhh__ wrote: post #81
bogwog wrote: post #51

I'm going to have to give a hard disagree. I've been making my own engines for a long time, and have used many different engines for a longer time. Inheritance-based entity systems are often a pain in the ass to work with, a massive pain in the ass to debug, and tend to invite shitty hacks to get around the shortcomings of the inheritance model. The article says that "Godot does composition at a higher level than in…

So what does Jai do that is different? For performance at least my focus is usually on eliminating information-lossy interfaces i.e. try to keep the hot loops where the compiler can see them

Jai is a programming language and not a game engine.

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

#89

Post by pcstl »

johnnycerberus wrote: post #17

All this hype around ECS started when Minecraft, Factorio and They Are Billions proved that the paradigm works, though that is just a small percentage of games that can benefit from ECS. The rest should use the classic OOP model. I really don't see how a game like Dota, CSGO or your average Battle Royale will be better with ECS. I agree with the article. There are libraries enabling ECS for you if you are not looking…

I believe ECS is in fact quite a bit older than that. As far as I can tell, ECS first started being talked about by AAA developers who were trying to find efficient ways to deal with the memory hierarchy in modern computing platforms (it got quite big specifically with the PS3, which had a very hard to deal with memory layout that could totally kill game performance). ECS allows data to be processed in a very cache-effective manner.

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

#90

Post by CreepGin »

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'm not sure Unity is at fault here. Most people in the game dev business knew about what ECS is (Entities + Components + Systems) long before Unite Austin 2017 (when Unity first announced their upcoming entities package).
Post reply on HN