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

101–110 of 151 posts

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

#101

Post by vvanders »

johnnycerberus wrote: post #94
teamonkey wrote: post #58

Earlier quoted context omitted.

> 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.

https://docs.unrealengine.com/en-US/ProgrammingAndScripting/...

The "S" in unreal is a tick. It's been about a decade since I last worked with Unreal but there was very much the concept of systems that processed batches of things in areas where performance was a concern.

Keep in mind that ECS is a design pattern and just like any design pattern applied blindly you can end up in a worse place than you started. A FactoryDispatcherQueuePatternImpl helps no one despite using many design patterns. When it comes to ECS it's much more about the spirit than the letter of the law.

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

#102

Post by pjmlp »

ratww wrote: post #77
zemo wrote: post #57

Earlier quoted context omitted.

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

ECS like systems were well known in CS even before that.

"Component Software: Beyond Object-Oriented Programming", 1998

https://www.amazon.com/gp/product/0201178885

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

#103

Post by pjmlp »

vvanders wrote: post #24
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…

Sorry but we were doing ECS long time before that in the industry. I remember doing it back on the PSP with Lua(meta-table -> component mapping) and a backing in house C++ runtime. It was pretty widely known in industry as a way to have cache locality and made it out to the broader dev community a good while after.

As I mentioned in another thread,

"Component Software: Beyond Object-Oriented Programming", 1998

https://www.amazon.com/gp/product/0201178885

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

#104

Post by pjmlp »

johnnycerberus wrote: post #25
k__ wrote: post #21

Earlier quoted context omitted.

I had the impression this was already state of the art in 2007 when I started my CS degree.

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?

Not a game, but standard software models,

"Component Software: Beyond Object-Oriented Programming", 1998

https://www.amazon.com/gp/product/0201178885

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

#105

Post by vvanders »

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…

Yup, this is spot on(with a mix for some systems that did a bit of data only components for the real perf critical stuff together with the more business logic components).

Your dates are right too, at least from my experience during '04~'12. Being on the tail end of that inheritance based approach was brutal and was so happy to leave it behind.

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

#106

Post by Jare »

CreepGin wrote: post #90
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'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).

It would be fair to attribute the ECS naming (specifically, making "Systems" an integral concept to the, ahem, system) to this from 2007: http://t-machine.org/index.php/2007/11/11/entity-systems-are...

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

#107

Post by hertzrat »

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 together in 1/10th the effort of a more coupled and fragile inheritance heavy approach. You can actually change things without breaking everything and you can actually understand what something does by reading 1-2 source files instead of 40.

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

#108

Post by teamonkey »

johnnycerberus wrote: post #94
teamonkey wrote: post #58

Earlier quoted context omitted.

> 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.

Not so. The physics system works on all physics components. The renderer system works on all rendering components. The networking system work on all components that are enabled for network replication.

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

#110

Post by hertzrat »

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?

Basically, in game dev, small differences in performance lead to a very noticeable effect on frame rate. In this case, cache misses are a big deal and their impact really adds up. ECS is a way structure your data to minimize cache misses and to theoretically make your multithreading easier too - in both cases by putting the data in one place (ie, removing state elsewhere), and making it easier to control when and how data gets modified
Post reply on HN