Support the creation of GDExtensions with C# / Add API for loading additional dotnet assemblies via C++ and hostfxr

[LouChiSoft]

So I would like to preface this discussion that I don't have a super in depth knowledge of Godot's architecture or technologies other than hostfxr other than the fact that they exist and a vague idea of what they do. With that out the way some backstory:

I like the ECS programming pattern. Yes I know Godot doesn't need ECS and this isn't going to be a discussion about how Godot should change to be ECS. I don't think it should. But I wanted to add support for ECS via the Flecs library. It recently got a 4.0 update and looks very exciting.

There is a great example of using Flecs in Godot here, but it's limited in scope and functionality. It basically requires the user to write all their components, systems, etc. in C++ and then use the editor to manage them. I wanted something more flexible, something that you can use GDScript to write new components, systems, the whole 9 yards.

My issue is that in Flecs to add a component to an entity it uses a concrete typing, e.g. a struct called Position. An entity can only have 1 position and trying to set an additional one would cause the first one to be overwritten. To my knowledge in GDScript when a user extends a type, e.g. a Component type, in the C++ side of the code you don't get a new type. You get a "Component with some extra bits". This means that if I was to define a Position component and a Rotation component in GDScript and tried to add them to an entity they would overwrite themselves.

That led me to an idea that could fix the above issue. Flecs has a fairly robust C# bindings library that enables you to use C# types as components. That means in theory you could take a component defined in GDScript and use the System.Runtime.Emit namespace to convert that at runtime to a real type and pass that real time to Flecs as a component. It's more levels of indirection than I would like, but at the end of the day you would only need to do the creation of these types once at start up and then you can instantiate them as many times as you want.

But to do this you would need some method of loading a dotnet DLL at runtime to and enabling the additional code in the assembly. I was thinking a similar system to how you define new types in C++ where you would still have to register an "entry_point" to the DLL and all the types you want to provide.
Alternatively instead of having a whole system for loading dotnet DLLs at runtime, maybe adding an API that can be called from C++ to load your DLL and then have to manually write all the glue code yourself as if it was a C++ GDExtension might be a good starting point. Again, not super familiar with the architectures of these technologies to know if this is possible.

Would love to hear discussions around this, thanks.

[AThousandShips]

See also:

• Godot C# GDExtension Roadmap Discussion #7895

[LouChiSoft]

I have seen this, but it was A) locked because of some bad discussions going on. And B) to my knowledge was more focussed on converting C# language support into an extension itself so that you can just include it in your project rather than needed a "mono" version of the game engine. Or am I mistaken on that last part?

[AThousandShips]

I'm not sure not my area, but also possibly related:

• Auto generate C# bindings for gdextensions #8191

[LouChiSoft]

Also seen, but again unless I am mistaken this is about automatically creating bindings for native GDExtensions so that they can be called from C#. I do appreciate the links though.

Actually my proposal might inadvertantly help with that last issue since it would add code that enables calling C# extensions

[octanejohn]

related
gdextention c#
https://github.com/raulsntos/godot-dotnet

friflo ecs c# godot
https://github.com/friflo/Friflo.Engine.ECS-Demos/tree/main/Godot

fenn tiny ecs c# godot
https://github.com/outfox/fennecs/tree/main/demos/godot

[LouChiSoft]

gdextention c#
https://github.com/raulsntos/godot-dotnet

This! This is exactly the sort of thing I want to be able to do. I will take a look, thanks. I do still personally think that it should be supported in the engine as a native feature, since C# scripting itself is a native feature (sort of anyway)