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

51–60 of 151 posts

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

#51

Post by bogwog »

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 a traditional ECS", but I don't get what he means by that? Combining nodes with incompatible hierarchies is hardly composition, and is just what you typically have to do when using inheritance.

Inheritance-based entity systems are not always terrible, and even though I tend to hate them, I use them quite a lot in my projects where an ECS would be overkill. If designed for a particular project, you can usually be more productive, and write cleaner and less code with inheritance.

However, for a general purpose engine like Godot, that's a bad choice IMO. The flexibility offered by an ECS far outweighs all benefits of an inheritance-based system.

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

#52

Post by cma »

Jasper_ wrote: post #33
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.

The performance benefits comes from the "Systems", which is very infrequently talked about. Most uses of the term "ECS" are actually "Entity-Component" (EC), which has been around for a long, long time. The goal is to have "Systems" which operate on "Components", and "Entities" are completely out of the picture. The idea behind Systems is that they operate on a continuous block of memory: for (auto &damagable : damag…

To go along with the parallel thing, you can imagine both of those loops are much easier to vectorize too compared to if each a was acting on objects with the damage stuff and position stuff combined in one structure.

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

#53

Post by WhatIsDukkha »

If you are making a game, instead of a game engine, you can have your cake and eat it too -

https://godot-rust.github.io/

Allows you to pair Rust with Godot comfortably via gdnative.

Then use one of the good ECS systems in Rust like -

https://github.com/amethyst/specs

or (archetype style ECS)

https://github.com/amethyst/legion

To get spun up on ECS in Rust I suggest -

http://bfnightly.bracketproductions.com/rustbook/chapter_0.h...

This won't get you a godot project but will get you a basic concepted game you can then port into godot-rust.

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

#54

Post by jmiskovic »

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.

Could you elaborate the way your system worked in Lua? Was the table itself an Entity, and which meta-methods would link with component? What kind of querying capabilities did a System have?

I've seen metatables used often to implement inheritance, but not the ECS yet.

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

#55

Post by HelloNurse »

Jasper_ wrote: post #33
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.

The performance benefits comes from the "Systems", which is very infrequently talked about. Most uses of the term "ECS" are actually "Entity-Component" (EC), which has been around for a long, long time. The goal is to have "Systems" which operate on "Components", and "Entities" are completely out of the picture. The idea behind Systems is that they operate on a continuous block of memory: for (auto &damagable : damag…

Entities aren't out of the picture: those "damagable.damage_this_frame" and "movable.velocity_this_frame" attributes need to be assigned in a previous step, with lookups from component to entity and from entity to component. For example, a collision detection and handling step could iterate over all physical objects and, in case they collide, assign damage to the damageable component of the same entity and/or alter velocity of the movable component of the same entity (if appropriate).

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

#56

Post by dexwiz »

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…

Composition does not strictly imply inheritance. A DOM tree is a perfect example of composing nodes without inheritance.

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

#57

Post by zemo »

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 render setting so that you can tune the gameplay early, get through many different gameplay design iterations, and get the artists and sound people working sooner seems like it would be of value to more teams than something highly performant that makes it harder to experiment and iterate. (on the ECS vs inheritance point I'm in agreement.)

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

#58

Post by teamonkey »

johnnycerberus wrote: post #35
vvanders wrote: post #29

Earlier quoted context omitted.

Because not every engine slaps a fancy ECS tag front and center, the pattern evolved concurrently in industry (and we all had games to ship). If you look really carefully you'll find structured column databases have similar properties since when you optimize for speed cache misses are your number one enemy.

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

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

#59

Post by Jare »

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 TreadsMovement component, a Turret component, a Wheels component, a Chassis component, etc. Each contains the data and behaviour for what they represent. You compose them together at runtime inside Entity objects to create tanks, cars, etc at runtime. Popularized by Scott Bilas' engine for Dungeon Siege. This is classic Unity. Most used from 2005 to today.

ECS: data-oriented where components are data-only, and behaviour logic lives in systems that act on a set of instances that contain certain subset of components. Entities are just ids for the set of components that make up the data for a given active object in the game. Entities and Components are best understood as a database which systems query and select from.

I don't know enough Godot to be sure if it's Inheritance or Component, but I know I left "classic" inheritance based behind almost 20 years ago and would never want to go back. Even back in 1997, the Commandos 1 engine was already half Component-based (but it took us a while to refine the Component model and intercommunication).

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

#60

Post by bogdanoff_2 »

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.

Computers are much faster when they operate on things that are laid-out contiguously in memory, instead of jumping around following pointers.

You need to use a programming language like C++ to be able to this. In JavaScript, all objects are pointers, so there's no way to do this.

Google "data-oriented design" to learn more.

Post reply on HN