> 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

What I think he's referring to is that you cannot compose new entities that consist of a different mixture of data. I cannot create a ProjectileWeapon that also plays audio, without changing the class to also inherit from an audio node type.

In Godot, you could create a ProjectileWeapon and then add a sub node that plays audio. I don't think that Godot's design limits what you can do at all, there's just a different way of doing the same thing.

Sure you can solve it by basically adding more objects to the world. That's not different from any other engine, but littering your scene graph with nodes because the alternative is inheriting from more things really isn't good.

As much as godot wants to claim their nodes are lightweight, ending up with so many redundant tramsforms, vtables and more (see their Node3D class) just shows how inflexible it is. Again in engines like Unity you can take the exact same approach, they just allow you to author entities without this redundancy.

To add: the blog specifically mentions that using inheritance is used for better re-use, but the need for having this composition through nodes would take that away. I know this might not be your specific point, but it ironically makes it seem they don't see this as an alternative.

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 Dungeon: https://www.youtube.com/watch?v=PqZwKahZ3cU

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.

> You can use ECS without "being data-driven", and you can use data-driven workflows without ECS.

True, I've read about ECS being used for one or both of those purposes.

My first contact was ECS was as a composability pattern. So, in a "high level" purpose, as an alternative to inheritance. It was also described as "Game Object - Game component" pattern.

See http://gameprogrammingpatterns.com/component.html, specially the sidenote in http://gameprogrammingpatterns.com/component.html#no-bj%C3%B....

There's the "performance" ECS, where it tackles data locality.

And the "game element definition and configuration" ECS, where it solves a high level problem of building game elements. On the "game developer" level, Unity works like this.

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.

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.

Usually scripting engines in games are there for the exact same reasons, moddability again being a side effect.

A nitpick: "Lua". It is not an acronym.

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

Tiberian Sun's technology is really unique and cool and I wish they'd open source it so I can see how they did everything. The 2d lighting really have it a distinct atmosphere.

Approach it like a mid 90s demo coder. Alphas, light maps, shadow casting.

The coolest 80s trick was rotating the palette to get moving water.

Starcraft does this for it's map animations. Each player in the game has a different color (so you can tell who's units are who's) and on some level that color is implemented as an index into memory, so if you set the player color above what the designers intended you can end up with wonky colors and (if memory serves correctly) some indices can land you in the rotating palette and give you subtile animated colors on your units. Most where just garbage memory though. This leads to a crash too because unlike most units the special 'flag' unit (for capture the flag) has a different portrait for each player color. It's also indexed by player color, so if you click on a flag of an invalid-color player, it crashes the game. This lead to fun maps like 'dont click the flag' but also woe in long running maps where players could click crash flags by mistake. Again, if memory serves, the crash was fixed by some hacks people would use in Roleplay maps (vision hacking allowed you to stack buildings) so RP map makers would include then anyway. Units to use as labels where at a premium in RP maps, you see...

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.