Odin Serializer Quick Start

Enable Odin Serialization in Unity classes

The primary way of using the Odin Serializer is by extending the existing serialization of Unity classes such as the MonoBehaviour or the ScriptableObject classes.

- Implementing The Odin Serializer

Using the Odin Serializer API manually

You can use the Odin Serializer independent of Unity classes. These tutorials are great place to get started.

- Serializing Without SerializedMonoBehaviour
- Making Save Games With The Odin Serializer

Are You In The Know?

Here you can find some tips and tricks and generally good to know information related to the Odin Serializer.

- On Odins Serialization Procotol
- Serializing Dictionaries

Odin's powerful serialization system will only kick when directly implemented. For custom MonoBehaviours and ScriptableObjects this is as simple as just inheriting from of the SerializedMonoBehaviour, the SerializedScriptableObject or one of our other Serialized- classes.

If you cannot inherit from these classes, then you can also manually implement the Odin serializer in your own Unity types. You can find a guide for this here: Implementing The Odin Serializer.

It is important to understand that when using Odin like this, Odin will try to avoid serializing any field that Unity should already be serializing by itself. This is determined at the level of the root serialized object.

To demonstrate this:

public class ExampleScript : SerializedMonoBehaviour
    // Unity will not serialize. Serialized by Odin.
    public Dictionary<int, string> FirstDictionary;

    // Unity will serialize. NOT serialized by Odin.
    public MyClass MyReference;

public class MyClass
    // Despite the OdinSerialize attribute, this field is not serialized.
    public Dictionary<int, string> SecondDictionary;

It is important to understand that Odin does not override the existing Unity serialization here; it merely extends it. This means that a class can have both Unity and Odin serialized properties. See On Odins Serialization Procotol.

The FirstDictionary field will be serialized by Odin, because Unity will not serialize it, and because the ExampleScript is the root object of the serialization. (All SerializedMonoBehaviour or SerializedScriptableObject are always the root serialization objects.)

The SecondDictionary field will, in spite of the OdinSerialize attribute, not be serialized. The MyReference field in the ExampleScript class can be serialized by Unity, and therefore Odin will skip it. Since Odin skips the MyReference field, none of the members in the MyClass type will even be considered by Odin.

In this case the solution is simple. You can just force Odin to serialize it instead:

[NonSerialized, OdinSerialize]
public MyClass MyReference;

The NonSerialized attribute prevents Unity from serializing the field, and the OdinSerialize attribute forces Odin to serialize it. With this the SecondDictionary field in the MyClass class will now be serialized by only Odin. If you had only added [OdinSerialize] without [NonSerialized], then both Unity and Odin would be serializing the same field, which could lead to both subtle errors and the unnecessary duplication of data in your asset.

See the guide on On Unitys Serialization Procotol for an more in-depth guide on what Unity can and cannot serialize.

This website is brand new and built with the Odin 2.1 beta in mind. This means you might discover some features such as attribute expressions that are only available in the beta.

You can download the 2.1 beta from here and read the patch-notes here.