Make object serialization/exporting by interface a first class citizen

[PereViader]

Could not find any open discussion on this topic. There is however an issue from 2019.

When dealing with the implementation and referencing other objects, Godot4 introduced a great feature where Exports reference Nodes by their type directly instead of needing to get them by path.

This would be a step after that.

public interface ISomeFeature
{
}

public partial class SomeNode : Node, ISomeFeature
{
}

[GlobalClass]
public partial class SomeResource : Resource, ISomeFeature
{
}

public partial class TheGame : Node
{
    [Export] public ISomeFeature SomeFeature;
}

With the engine supporting this cleanly, game code could be way cleaner and have more of a plugin architecture where they just need to know the implementation of the other types.

Something similar can be implemented with abstract classes, but then things become harder. Not to mention that there is no way then to have the interface be either something located inside the same scene or on a shared resource.

The idea behind this is that you could for example have something similar to this

public interface IFood {}

public partial class Apple : Resource, IFood {}
public partial class Grape : Resource, IFood {}
public partial class Pizza: Resource, IFood {}

And then similar to what this project, and what godot already does, have a dropdown where you can easily create a new instance or reference an existing one from the Project.

Relevant image from the implementation we have in Unity for this (https://github.com/Guillemsc/ImplementationSelector)

Godot's way of handling references is even better than unity as it could allow for scene embedded/referenced asset, something which unity can't easily do in their current serialization strategy.

[PereViader]

I tried to fake this by doing the following but without luck.

[GlobalClass]
public partial class SerializableObjectInterface<T> : Resource
    where T : class
{
    [Export] public GodotObject GodotObject { get; set; }

    public T Value
    {
        get => GodotObject as T ?? throw new InvalidCastException();
        set => GodotObject = value as GodotObject ?? throw new InvalidCastException();
    }
    
    public static implicit operator SerializableObjectInterface<T>(T value)
    {
        return new SerializableObjectInterface<T>()
        {
            Value = value
        };
    }
    
    public static implicit operator T(SerializableObjectInterface<T> value)
    {
        return value.Value;
    }
}

public interface IFeature
{
    void Play();
}

public partial class TheGame : Node
{
    [Export] public SerializableObjectInterface<IFeature> Feature { get; set; }
    
    void _Ready()
    {
        Feature.Value.Play();
    }
}

It seems that the type GodotObject can't be used to serialize anything from the inspector.

[timothyqiu]

ISomeFeature is a C# feature. Godot can only handle things that Variant recognizes.

Something similar can be achieved by overriding _get_property_list() / _get() / _set() in tool script mode to add / remove properties dynamically.

If you're just dealing with Resources, inheriting from a common base class and marking the export variable as common base class is enough I think.

[PereViader]

ISomeFeature is a C# feature. Godot can only handle things that Variant recognizes.

Yes, c# interfaces are not something currently supported by variant in Godot. This is precisely the feature request this discussion starts.

If you're just dealing with Resources, inheriting from a common base class and marking the export variable as common base class is enough I think.

Again, this discussion is proposing adding the ability to export anything just by the interface and not by the final target type / common base class. An interface is something even further abstracted that would provide even more flexibility on the implementation side. A common base class is something that can sometimes not be doable or even when doable might not be desired.

Something similar can be achieved by overriding _get_property_list() / _get() / _set() in tool script mode to add / remove properties dynamically.

I will look into this further to see if this could be used for such workaround. Thank you!
Regardless of possible workarounds, having the functionality come natively from Godot would be desirable.

[megonemad1]

would it be possible to create a validation for general exported node/resource such that inspector elements like these:

would only allow the specified interface to be added as an instance reference or default to null?

[PereViader]

This is precisely what I was trying to achieve in my first comment. I think it would be good enough. Just have some type to restrict referenced Godot objects that satisfy some type. I couldn't do it and have not investigated further.

[megonemad1]

is see well, this is a bump then for the feature exsisting

[poohcom1]

I am 100% in favor of this.

As a workaround, I wonder if this can be achieved with a C# addon/library using source generators. My idea is that we can use an attribute to generate a class that exports a plain Node, and then use an EditorInspectorPlugin to create a custom Node picker that enforces the interface.

Let's say we use an attribute like this:

public partial class MyNode : Node2D
{
    [ExportInterface]
    public IComponent Component { set; get; }
}

It would generate this:

// MyNode.generated.cs
public partial class MyNode
{
    [Export]
    private Node _component;
    // Call this in _Ready()
    // Not sure if this can be automated
    public void WireComponents()
    {
        Component = _component;
    }
}

And to enforce the interface, we can do something like this:

[Tool]
public partial class InterfaceExportInspectorPlugin : EditorInspectorPlugin
{
    public override bool _ParseProperty(GodotObject @object, Variant.Type type, string name, PropertyHint hintType, string hintString, PropertyUsageFlags usageFlags, bool wide)
    {
        // This service will use reflection to figure out if it's an interface export
        if (_attributeAnalyzerService.IsExportInterface(@object, name))
        {
            // Add a custom Node picker that highlights only valid implementations
            AddPropertyEditor(new CustomNodePicker(_attributeAnalyzerService, @object, name));
            return true;
        }
        return false;
    }
}

This last part might be a bit difficult because of godotengine/godot#80693, so we will have to use reflection to figure out what attribute and interface belong to a property.

I tried to implement this and was able to get the attribute reflection working, but got stuck on the generator so I kinda gave up. Curious if anyone else might be able to implement this or have ideas for simpler ways to achieve this.

[PereViader]

I really like the idea of using a source generator to get close to the implementation. However using node as the backing serialisation type would not let Resources that also implement the interface be part of the solution 🤔

The way I usually structure data driven systems makes use of this Polymorphic Resource serialisation strategy extensively. In my ideal world, this would let us work with nodes and resources at the same time and completely transparently.

You commented if this innit method could be called automatically I don't think it would be possible unless inheritance is added into the mix and even then _ready would become virtual. Thinking about it, maybe it would be cool to have some attribute that lets us hook some methods to be called before _Ready?

Ideally, all of this just happens during de/serialization so that we don't need to add any code that retrieves the object during runtime

[poohcom1]

However using node as the backing serialisation type would not let Resources that also implement the interface be part of the solution

This should still be possible, but we'll probably need two types of exports to cover both case. Script component can have Node as a base while resource components can use Resource.

I did some exploration and it looks like using [Export] in generated source doesn't work. Seems like Godot source generators doesn't see our sources, so those properties get ignored when exported. We could still work around this by using a [Tool] class so we can use _GetPropertyList() to manually insert properties, but I don't like the idea of turning all my nodes to tools as that can get quite messy.

However, this may still be possible if we use an extra resource/node class to act as a "container" class. Since these are separate from whatever node you're using, we can make them tools without affect our current nodes. I made a poc for this:

// Container
[Tool]
[GlobalClass]
public partial class ComponentContainer : Resource // This can also be a Node
{
    [ExportNodeInterface] // Source generators detect this and generate nodepath getter/setters
    public IComponentA ComponentA { get; set; }
    [ExportNodeInterface]
    public IComponentB ComponentB { get; set; }
}

// Main node
public partial class TestNode : Node
{
    [Export]
    public ComponentContainer Components { get; set; }

    public override void _Ready()
    {
        base._Ready();

        Components.WireComponents(this);
        Components.ComponentA.DoSomething();
        Components.ComponentB.DoSomethingElse();
    }
}

With source generation, we can generate all the required logic in ComponentContainer to wire and cache nodes, so performance shouldn't be an issue. At this point, it is rather messy/hacky having to create a separate object to contain all the interfaces, but I don't know of a better solution without turning everything into tool nodes. I'll keep exploring this since I'm not too bothered by the limitation (in fact I like having my exports separate from the main node because it makes them less prone to being reset).

[PereViader]

I don't have time to properly review your implementation, and must say that I still don't know how this tooling and custom area of the engine works. Having that said, and given my current workflow in unity, I think one of this two changes would be beneficial.

A- Rename attribute from ExportNodeInterface to ExportInterface. If it is to be compatible with both resources and Nodes, it would make sense. Also shorter :D

B- Given that you mention that an intermediate [Tool] class is needed, would it be possible to have a reusable tool class that can be used instead of the user needing to create it every time forcefully?

[Tool]
public Interface<T> : Resource
{
      [Export] public Node node;
      [Export] public Resource resource;
      [Export] bool isNode;
      
      public T Value => isNode ? (T)node : (T)resource; //There might be a way to do this better?
}

public partial class TestNode : Node
{
    [Export] public Interface<IComponentA> ComponentA { get; set; }
    [Export] public Interface<IComponentB> ComponentB { get; set; }
}

if this is possible here are pros and cons

Pro:

• No need to create a custom Tool class
• No need to add anything on _Ready to do the wiring

Con:

• Syntax is not as clean

[poohcom1]

Some updates:

I've done some further testing and explored other solutions. Ultimately, the source generation solution is the only one that worked, but it still has some quirks (compilation leads to value resetting). I wrote a few details on various solutions I've explored (including the one you've suggested) in the project readme in case you're interested.

Since I couldn't find a solution I'm satisfied with, I'll probably leave this to the Godot devs for now. My main use-case is for node exports, so I can already kinda do that with GetNode() or abstract classes. Maybe if others have alternative ideas I might look into this again.

[PereViader]

Very nice job!
Hopefully the work you've put in will take us closer to a proper integration 👏

[megonemad1]

Coming back to this post, I realised that Godot via gdscript doesn't have this feature but it does attempt to use it with functions like has_method being used to hack the concept of contracts / interfaces into the language.
My conclusion is Godot needs a contract syntax that simplifies multiple lines of has method checks required to write reliable code.

Having a gd interface could be a case of defining a gd script that has all the functions you care about but nothing
else then asking if an object quicks like that gd script. This would fulfill the above and create the needed functionality to match c#

[poohcom1]

FYI I've made a proposal for this: #8722. After a few weeks of working on an addon I think I have a pretty good idea of how this can be implemented in core. Let me know if there is anything I've missed in the proposal.

[megonemad1]

Came back as I saw this and it seemed like a good add to the bonfire
https://youtu.be/pBs6c902P0Q?si=lGlI0iyNomBbVNAY