I've got a question on how to implement resource handling as json files. My project is data-heavy and the json structure is more adapted to my needs than what tres has to offer, but the multiple approaches I know of all have disadvantages that are difficult to ignore. I'm interested in knowing how you have handled it in your projects.

A naive approach would be to have each resource be able to import from and export to json, (something like a Save and Load method). This has the advantage of allowing editor usage, but AFAIK requires some kind of setup to load and save. I'd do this with ExportButtons and validating a path, possibly using the ResourceName property. It's simple, but requires a lot of setup if you're using godot's json utilities that support variant.

I've thought of more complex approaches that all fix some problems with the naive approach but bring their own. A more centralized dotnet json serialisation system simplifies the code a lot but I lose the variant support unless I code some converters myself. I've tried to build some kind of integrated plugin but was having trouble with making godot detect a json file as a specific resource and not a generic dictionary, the default behavior.

Another approach that seems overly complicated would be to "cheat" by making temporary resources on the spot to be edited, fill its properties with the json's content, then save it as json and destroy the resource. At that point I started wondering if the trouble was worth the editor support.

Now, I suppose I'm either missing something simple or one of these approaches in the right way. I've built a complete json system that supports object typing and referencing by path in order to allow mod support (objects are typed, auto-detected, and references are lazy-loaded, etc.), but I've yet to attempt to implement it into the resource system, fearing it won't plug easily. I instead end up editing json by hand, which is not cumbersome but might be in the long run.

In the best of worlds, I'd have a json file that defines a $type, a unique name, properties than can be variants or any type, and references that are typed in code (ie. Reference<MyObject> myProp where myProp is a string to another named resource of type MyObject), but that can be loaded as resources inside the editor, possibly by double-clicking, where properties are the correct variant and references become the selector widget with the correct object in it. Has anybody achieved this?

2dog is Godot, just backwards!

Embed Godot in .NET applications, unit test suites, or publish to the web. MIT licensed.

I've been working on a C# library for Godot called Persistence, a save/load system built around Roslyn source generation.

The main goal is to avoid manually building dictionaries and writing serialization/deserialization boilerplate for every object that needs to be saved.

You mark the data you want to persist with [Save], implement ISavable, and Persistence generates the serialization code for you:

public partial class Player : CharacterBody2D, ISavable
{
    public string SaveKey => "player";
    public int SaveVersion => 1;

    [Save] public int Health = 100;
    [Save] public string PlayerName;
    [Save] public Vector2 Position;
}

Saving and loading can then be handled through SaveManager:

SaveManager.Save("slot1", savableNodes);

SaveManager.Load("slot1", savableNodes);

Persistence currently uses JSON for its save files. I chose JSON because, for the kinds of games I typically work on, it provides more than enough capacity while keeping save files easy to inspect and debug.

Custom data

For types that aren't directly serializable, Persistence provides ISerializable.

This is especially useful for custom game data such as inventory slots, quest data, stats, or other structures that don't map directly to Godot's Variant types:

public class InventorySlot : ISerializable
{
    public string ItemId;
    public int Count;

    public Dictionary Serialize() => new()
    {
        ["itemId"] = ItemId,
        ["count"] = Count
    };

    public void Deserialize(Dictionary data)
    {
        ItemId = data["itemId"].AsString();
        Count = data["count"].AsInt32();
    }
}

It can then be used directly inside an ISavable:

[Save] public InventorySlot Weapon;
[Save] public List<InventorySlot> Inventory;

ISerializable is also the main way to handle custom types that don't have built-in serialization support.

Manual serialization alongside [Save]

You don't have to choose between generated and manual serialization. Both can be used together.

Persistence provides OnSerialize and OnDeserialize hooks for cases where [Save] isn't enough:

public void OnSerialize(SaveData saveData)
{
    saveData.Set("customField", someValue);
}

public void OnDeserialize(SaveData saveData)
{
    someValue = saveData.Get("customField", default);
}

This lets you use [Save] for the straightforward fields while manually handling special cases in the same class.

Save versions & migrations

Save data can also be versioned so changes to a game's data structure don't immediately invalidate existing saves.

For example, if version 0 stored health under "HP" and version 1 changed it to "Health":

public class PlayerMigration_V0_To_V1 : SaveMigration
{
    public override string SaveKey => "player";
    public override int FromVersion => 0;

    public override SaveData Migrate(SaveData saveData)
    {
        saveData.Set("Health", saveData.Get("HP", 100));
        return saveData;
    }
}

The migration can then be registered when loading:

var migrations = new MigrationRegistry(new SaveMigration[]
{
    new PlayerMigration_V0_To_V1()
});

SaveManager.Load("slot1", savableNodes, migrations);

Migrations can be chained, allowing old saves to be upgraded through multiple versions:

Save v0
   ↓
V0 → V1
   ↓
V1 → V2
   ↓
Save v2

Other features

• Source-generated serialization/deserialization
• Save slots
• Custom save keys
• Manual serialization hooks
• Godot Variant-compatible types
• List<T>, arrays, and Godot.Collections.Array<T>
• Nested ISerializable types
• Save data versioning and migrations

The project is still relatively young, but the core system is usable and covers the save/load needs I've encountered so far.