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

1–10 of 151 posts

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

#2

Post by willvarfar »

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 everything is set up in code and decided at compile time instead?

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

#3

Post by SigmundA »

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…

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 the closer to a full blown DSL it is and you might as well just use a mature scripting language instead.

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

#4

Post by CyberDildonics »

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…

Are you asking if that is a downside? Yes, it is a significant downside since fundamental parts of a game would need recompilation which means slow iteration on things that need to be iterated on a lot.

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

#5

Post by Waterluvian »

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

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

#7

Post by RMPR »

SigmundA wrote: post #3
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…

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…

> Its kinda like the config file vs code as config debate

I had trouble parsing this because I was reading "vs code" as visual studio code.

> 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 the closer to a full blown DSL it is and you might as well just use a mature scripting language instead.

I think using a mature scripting language is just a matter of transferable skills. People may be more reluctant to learn yet another language just to mod your engine. Especially if it's a one-time thing.

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

#8

Post by dagmx »

SigmundA wrote: post #3
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…

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…

To note though is that those config files aren't meant for modding. They're meant as easy ways for the gameplay designers themselves to tweak things without needing to rebuild the whole game each time.

They just usually ship as side effects of that process, because no body really cares that much for single player games.

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

#9

Post by benjaminjackman »

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…

> One downside to godot’s inheritance is everything is set up in code and decided at compile time instead?

That's not really the case because Godot can load scenes at runtime. The scene format itself (.tscn files) is text based[1] (which is also nice for version control) and could be edited by hand, then loaded into the game at runtime. Though since the Godot editor is open source and totally free it would probably be better just to ship that with the game. It's also really easy to extend so custom game centric plugins that modify the editor itself are also easy to write.

1: Here is a sample scene file, just to give a sense of the format:

    $ cat enemies/bandit/BanditSpread.tscn

    [gd_scene load_steps=2 format=2]

    [ext_resource path="res://enemies/bandit/BanditBase.tscn" type="PackedScene" id=1]

    [node name="BasicBandit" instance=ExtResource( 1 )]
    fire_period = 0.85

    [node name="VK-001" parent="Sprite" index="6"]
    visible = true

    [node name="LG-Anger" parent="Sprite" index="8"]
    modulate = Color( 1, 3.1875, 6, 1 )

    [node name="ProjectileWeapon" parent="Hardpoints" index="0"]
    projectile_spread_degrees = 60.0
    projectile_variance_degrees = 0.0
    num_projectiles_min = 6
    num_projectiles_max = 6
Post reply on HN