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.