I don’t like ECS because it always conflates to using components as messages for systems that have nothing to do with Entities. I much prefer using a message system. A message system can quickly abstract the engines view from the core logic of the game and allow for the messages to be dispatched across network making networked games easier to work with.
Why isn't Godot an ECS-based game engine?
41–50 of 151 posts
Re: Why isn't Godot an ECS-based game engine?
#42I 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…
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…
A nitpick: "Lua". It is not an acronym.
Re: Why isn't Godot an ECS-based game engine?
#43Based on their previous opinion on Vulkan, in 4 months they will announce moving to ECS.
Re: Why isn't Godot an ECS-based game engine?
#44I 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.
Re: Why isn't Godot an ECS-based game engine?
#45As 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).
One of the nice things about ECS is how easy it is to integrate into an existing structure. In the engine case you just make your existing object hierarchy one component type, and whatever subsystem you're making ECS into its own component. At a library level you just wrap that library's per object state in its own component.
What issues did you have?
Re: Why isn't Godot an ECS-based game engine?
#46All 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…
Total Annihilation (1997), Thief (1998), Dungeon Siege (2002), and many others used ECS and their developers wrote about it long, long before Minecraft and others.
Re: Why isn't Godot an ECS-based game engine?
#47Earlier quoted context omitted.
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…
> Do you know if there is a formal term for this kind of dependency chain and update order scheduling is called?
ECS might make this an independent-enough concern that techniques from build systems would be applicable. See "Build systems a la carte" [0], for instance, which captures the (an?) essence of build systems as managing a graph of dependent dataflow processes. (In ECS, the dataflow would be mediated by the database of component tables, just as in Make the dataflow is mediated by the filesystem.)
[0] https://www.microsoft.com/en-us/research/publication/build-s...
Re: Why isn't Godot an ECS-based game engine?
#48Personally, 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.
there is avoiding object trees, there is ecs, then there is not doing either of those things, which is often the best and simplest option. no need for a fancy ecs system if you have like five entities
Re: Why isn't Godot an ECS-based game engine?
#49ECS at the game engine level has never been particularly interesting to me, but it is a good way to structure complex game logic. This shouldn't be tightly coupled with the game engine anyway, so I don't find the different architectures awkward. Godot's node-based structure makes a ton of sense for what it does.
The main reason ECS became popular is because of the performance benefits, and the tasks that get the most benefit from that are the ones core to the engine such as the rendering pipeline and physics engine. Personally I think Godot's system is much easier for the end user than an ECS. I am not much of a fan of OOP (I use a functional language at work) but I do think OOP is a good fit for games and UIs.
Re: Why isn't Godot an ECS-based game engine?
#50I'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 stay in the comfort zone of scene tree hierarchical representation. I'm planning to move to Jai or build a PureRef-like visual ecs editor with libclang ast reflection and hot reloading so I can escape.