Add built-in serialization-support for dictionaries(with editor)

Add the ability to serialize dictionaries with the built-in editor. This feature is important for creating user-friendly configurations through scriptable objects and sometimes for configuring mono-behaviours.

Currently, my projects always depend on external or self-written solutions like this asset: Serialized Dictionary | Utilities Tools | Unity Asset Store.

Despite their usability, it’s hard to trust and maintain these solutions. Therefore, it would be perfect to have such a feature built-in in Unity.

It’s not too hard to implement. Unity already uses Newtonsoft.Json for internal workings, which supports such functionality. Even without that, such functionality can be constructed over the existing API using the same techniques as the mentioned asset above.

It would be ideal look for editor:

2 Likes

If that were the case we would have had this since 2010-ish. :wink:
This has been requested and discussed up and down ever since. By this point I’m confident it’s never going to happen.

All the SerializedDictionary implementations commonly split the dict into two lists during serialization. This works fine with less than 100 elements and a few scripts using this. But go above 1,000 elements or a larger number of uses and it trashes editor performance.

I’ve come to be accustomed to not serialize dictionaries and fared really well so far. The two separate, synchronized lists solution works well enough if you wrap it in your own class rather than subclassing Dictionary<> while keeping the number of elements low. This will serialize out of the box but you still need a custom Inspector drawer if you want the key/value pairs next to each other.

The above can also be emulated with a List where Stat is:

[Serializable] public class Stat
{
    public StatType Type;
    public float Value;
}

Now the UX for this list may be a bit awkward but custom tooling with UI Toolkit and data binding would fix this.

1 Like

To be honest, Unity should be able to add this on the serialisation end. If they can add in proper by-reference serialisation, they can add in support for dictionaries.

The issue is the inspector side of things. The SerializedObject/SerializedProperty system is getting way to unwieldy and is honestly no longer fit for purpose. We still don’t have built-in inspector support for [SerializeReference] that was added in 2019! And the reason is it’s just not possible without major hacks with the existing system, or it gets a major overhaul.

That said, it is unnecessary to use a dictionary when looking up from a very small collection. Using one to only have 5 values isn’t going to get you any advantage over using a regular array/list, so you can just use what we already have in that case.

If you do really care about serialising and drawing dictionaries, then Odin Inspector/Serializer is the best choice for this.

2 Likes

Agree, the issue is unlikely with the serialization itself but with the UX side of things, and possibly a number of other things too. I‘m mainly thinking that it would introduce developers to more issues where iterating over the keys or values has no defined order … and this trickles down into the GUI.

On the GUI side a user expects the order to remain fixed, which would make it all the more confusing that on the code side the order is undetermined. Or you suffer a performance penalty due to sorting.

These are not unsolvable problems, though. Odin Inspector, I believe, checks for IComparable<T> on the keys first and sorts based on that. Otherwise I believe it’s just a general sort based on the ToString() value. Though been a while since I looked through the source of the dictionary drawer. Though it has the advantage of its drawer system supporting generics, whereas Unity’s does not.

Ultimately the issue is that the SerializedObject/Property system isn’t flexible enough for more complex collections.