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

31–40 of 151 posts

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

#31

Post by linkdd »

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 is not a "type dependency" IMHO, since the data are independent of each other. It's more like a "logic dependency", where the logic of one System requires the logic of another System.

It is the systems you want to apply to an entity that will dictate what components it needs.

Since it can change during runtime, this cannot be statically typed.

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

#32

Post by dkersten »

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?

Dungeon Siege, although the slides where this was revealed seem to no longer be online. Additionally, here is the blog post from 2007 that largely introduced the concept in the form we know now, based on the Dungeon Siege talk and others: http://t-machine.org/index.php/2007/09/03/entity-systems-are...

Although, arguably, Dungeon Siege's component architecture is different from what we call ECS today.

EDIT: I found the slides: https://www.gamedevs.org/uploads/data-driven-game-object-sys...

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

#33

Post by Jasper_ »

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.

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 : damagables) {
        damagable.hp -= damagable.damage_this_frame;
        damagable.damage_this_frame = 0;
        if (damagable.hp
Simple toy example, but by splitting up the data based on what acts on them, we have two loops that are very cache-friendly. Each of those two loops is called a "System".

The System is the key part of ECS that makes this work. Just splitting off components and still using a virtual update function isn't going to get you any performance benefits, but it's still most of what I see when I see "ECS" talked about online. In fact, making components contiguous while leaving your updates to be whole-entity-at-a-time is going to make your cache coherency worse!

Entities, then, are actually not "container objects", but often just uint32's -- all of their data is inside the Components. The database analogy: The Entity is just a primary key tying together a database of tables (Components). The tables can be acted on, sometimes in parallel, by Systems (UPDATE queries), regardless of the originating Entity.

Actual Systems in practice have dependency chains and other things, to make sure that updates are done in the right order, scheduling mechanisms, and ways to make cross-component talking safe, and performant.

Unity's GameObject is not ECS, despite it being an "Entity-Component" model. Their new DOTS stack is, but it has tradeoffs for that performance.

Put simply, "EC" is a way of structuring your data classes to not rely on inheritance, "ECS" is a way of structuring your algorithms that act on those data classes to not require virtual methods.

The rest of this thread has similar misconceptions, and even the original post makes some errors too. Sadly, this misinformation is widespread, and it's not really correctable at this point. Oh well.

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

#34

Post by Shorel »

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.

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.

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

#35

Post by johnnycerberus »

vvanders wrote: post #29
johnnycerberus wrote: post #27

Earlier quoted context omitted.

That's nice, but why all the game engines and libraries introduced it only recently? Defold, Unity ECS, etc.?

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 Lisps like Clojure which match the RMDB data model. But people still find it hard to grok it, hence the low adoption rate.

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

#36

Post by Jasper_ »

Vaskivo wrote: post #13
willvarfar wrote: post #2

I first met ECS when modding an RTS called Tiberian Sun. The units were all defined in ini files and you specified the components for each unit eg the difference between a building and a moving piece was whether there was a movement component etc. And a small but vibrant modding community grew up around it. Everything was dynamic, read from data definitions when the game loaded. One downside to godot’s inheritance is…

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.

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

#37

Post by Pulcinella »

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…

Yeah there is definitely some mental namespace pollution between EC and ECS where, as you described, you have “EC systems” (Entity-Component systems) and “ECS systems” (uhh “Entity-Component-System systems”).

Actual Systems in practice have dependency chains and other things, to make sure that updates are done in the right order, scheduling mechanisms, and ways to make cross-component talking safe, and performant.

Do you know if there is a formal term for this kind of dependency chain and update order scheduling is called? I’m interested in ways this kind of checking can be done at compile time, or at least a run time guarantee that things won’t be done in the wrong order and fails to compile/generates run time errors when you have a cyclic dependency rather than having to map that all out by hand.

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

#38

Post by johnnycerberus »

dkersten wrote: post #32
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?

Dungeon Siege, although the slides where this was revealed seem to no longer be online. Additionally, here is the blog post from 2007 that largely introduced the concept in the form we know now, based on the Dungeon Siege talk and others: http://t-machine.org/index.php/2007/09/03/entity-systems-are... Although, arguably, Dungeon Siege's component architecture is different from what we call ECS today. EDIT: I found th…

Thanks, I will check them out. I'm out of the loop when it comes to older games since for me game development is only a recent hobby. I'm developing Big Data stuff mostly with Java and Scala, but I have been playing with data-oriented stuff in Clojure, hence my interest.

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

#39

Post by ralusek »

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

Do you mind elaborating a bit? My understanding is that ECS would be providing data in a way not unlike most web applications do, such that building a React UI over that data model should be quite easy.

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

#40

Post by dkersten »

johnnycerberus wrote: post #38
dkersten wrote: post #32

Earlier quoted context omitted.

Dungeon Siege, although the slides where this was revealed seem to no longer be online. Additionally, here is the blog post from 2007 that largely introduced the concept in the form we know now, based on the Dungeon Siege talk and others: http://t-machine.org/index.php/2007/09/03/entity-systems-are... Although, arguably, Dungeon Siege's component architecture is different from what we call ECS today. EDIT: I found th…

Thanks, I will check them out. I'm out of the loop when it comes to older games since for me game development is only a recent hobby. I'm developing Big Data stuff mostly with Java and Scala, but I have been playing with data-oriented stuff in Clojure, hence my interest.

Funnily enough, I came to it in reverse: I learned about ECS years ago (from the tmachine series of posts, posts about Dungeon Siege, and others I can't remember) and became interested in Clojure's data-oriented stuff because of my interest in ECS. Although, I became interested in and used Clojure already, due to its focus on immutability and functional programming, before people really started pushing the data-oriented aspects, so it was an easy evolution for me.
Post reply on HN