Terminology: What does "serializable" mean in Unity terms?

I see it thrown around every where, for just about everything. Somethings are, somethings can be, somethings aren't, somethings don't/won't.

But I can't find exactly what this means, nor ALL of its possible meanings and prowess/abilities for all the different things that can be described as "serializable".

2 Likes

Does this help? https://en.wikipedia.org/wiki/Serialization

1 Like

It’s literally just the action of translating data from one format to another. Within the context of Unity it’s transforming it in and out of formats that Unity is capable of working with.

https://docs.unity3d.com/Manual/script-Serialization.html

1 Like

[quote=“Ryiah”, post:3, topic: 712197]
It’s literally just the action of translating data from one format to another. Within the context of Unity it’s transforming it in and out of formats that Unity is capable of working with.

https://docs.unity3d.com/Manual/script-Serialization.html
[/quote]

Why would anything, in Unity, be not serializable?

2 Likes

There are costs associated with serialization. Transforming the data takes processing power as well as other resources depending on the purpose. Serialization is typically performed when you want to send data to storage (eg saving your game), across a network (ie multiplayer), and so on.

Beyond that there are limits to the serialization system and what it’s able to handle. You can extend the capabilities of the system yourself though if you need to be able to serialize data it normally cannot.

2 Likes

[quote=“Ryiah”, post:5, topic: 712197]
There are costs associated with serialization. Transforming the data takes processing power as well as other resources depending on the purpose. Serialization is typically performed when you want to send data to storage (eg saving your game), across a network (ie multiplayer), and so on.

Beyond that there are limits to the serialization system and what it’s able to handle. You can extend the capabilities of the system yourself though if you need to be able to serialize data it normally cannot.
[/quote]

If I start with a simple example, this might help explain my confusion.

Is not serialized. So what is it?

Yet this is:

[SerializeField]
private Type type;```

In this case, it seems to mean "expose in Inspector", but this doesn't seem to be nearly all that serializable actually means. It seems to also mean that the state of anything/things are changed.

I don't get why this is the case. It's as though I am missing a complete block of knowledge about why serialization exists, and what it is for/about.
2 Likes

A variable.

It means it’s exposed in Inspector AND the value its set to will be saved in the scene file.

1 Like

[quote=“AcidArrow”, post:7, topic: 712197]
A variable.

It means it’s exposed in Inspector AND the value its set to will be saved in the scene file.
[/quote]

Yes, I get that it’s a variable.

My blankpoint… why isn’t everything accessibly accessible, everywhere, within Unity, by design?

It’s a game engine. It doesn’t exist to serve another purpose, so why does serialization even exist, shouldn’t everything be saveable, editable and accessible, by design?

Is there a root problem that serialization solves, that’s caused by some other design consideration that I’m probably completely unaware of?

1 Like

Say I have a float, that I don’t really care about its value, because the value I care about is dependent on other stuff and is calculated somewhere in the script, why should that value be saved in the scene file, making the file larger, which will then make it take longer to load? (I mean one float will not matter at all, but I hope you can see that if everything was saved, it would quickly add up).

Serialization is not a mysterious thing. If you have a, say a boolean with SerializeField, that you have set to false in the inspector, then Unity will simply write somewhere (where the rest of the things related to the script are) in the scene file:

myBool: 0

That’s all.

1 Like

[quote=“AcidArrow”, post:9, topic: 712197]
Say I have a float, that I don’t really care about its value, because the value I care about is dependent on other stuff and is calculated somewhere in the script, why should that value be saved in the scene file, making the file larger, which will then make it take longer to load? (I mean one float will not matter at all, but I hope you can see that if everything was saved, it would quickly add up).

Serialization is not a mysterious thing. If you have a, say a boolean with SerializeField, that you have set to false in the inspector, then Unity will simply write somewhere (where the rest of the things related to the script are) in the scene file:

myBool: 0

That’s all.
[/quote]

I get that serialization might not be a mysterious thing. But it’s reason to exist, and the manner in which it’s so particular, that’s a little mysterious. To me.

If serialization is really about the ability to save and edit a thing, well… that’s the entire point of everything in a computer; that it be saveable and editable.

So, again, I’m sorry if this seems retarded, but why isn’t everything, as a matter of due course of usage, editable and saveable, and therefore serializable?

What is serialization bringing to the table that requires it to be a special thing/way that’s required to be specified?

or… what are the advantages of something not being serializable?

There’s something I’m fundamentally missing in terms of why serialization needs to be.

I gave you an example…

Also I’m not sure why you’re saying editable. It’s more or less just saveable.

But again, in the context of variable fields in Unity, let’s say:

private float somevalue = 6f;
(private is optional actually, they are private by default)

means I have a float that has the value 6. And everywhere I use this script, it will be initialised to that value.

[SerializeField]
float somevalue = 6f;

Now every scene file I use this script, will write to its .scene file

somevalue: 6

Or actually, not 6, it will write whatever value it has in the inspector. To it could be any value.

So two things:

  1. Now all my scene files are larger, and I may not want that, because they take longer to load.

  2. Now that value is not initialized as 6 everywhere. It is initialized to whatever it is in the inspector in each file. And if I actually rely in the script to this value being 6, I have just opened myself to errors, because someone might edit it in the inspector and it may not be the same value everywhere.

[quote=“AcidArrow”, post:11, topic: 712197]
[SerializeField]
float somevalue = 6f;

Now every scene file I use this script, will write to its .scene file
[/quote]

Please excuse this naive and stupid question.

Does this mean there’s a strong relationship between serialization and scenes?

And this brings up another question… scenes are specific containers with storage, not referencing things stored?

[quote=“AcidArrow”, post:11, topic: 712197]
I gave you an example…
[/quote]

Sorry, I missed it. What example, and what does it demonstrate that I’m failing to grok/consider?

Sorry, again, yes… I do need things spelt out. Much of the docs and tutorials I’ve read, and still this is not clear, to me.

1 Like

Seriliazation in much more broad terms is, me saying “Hey, keep a note that tomorrow is Monday” and you taking a piece of paper and writing “Tomorrow is Monday”. BAM you just serialized something!

That’s serialization in general.

Now, specifically for the [SerializeField] property, yes it has a lot to do with the scene files.

Open up a .scene file in a text editor, it’s pretty readable.

Other than that, I don’t know how to spell it out more for you. I gave you another example. Maybe rephrase the question, since I’m not really sure how to spell it out more.

2 Likes

[quote=“AcidArrow”, post:14, topic: 712197]
Other than that, I don’t know how to spell it out more for you. I gave you another example. Maybe rephrase the question, since I’m not really sure how to spell it out more.
[/quote]

How to write an example, an example:

The following example demonstrates how an example parallels, via analogy and metaphor, the use of examples:

All mammals breath air, and need oxygen. Some mammals are able to swim. Some mammals live on land, some in the sea. All mammals that live in the sea can swim. Some mammals that live on land can swim.

All data needs storage. Some data can be edited in Unity, some data lives in Unity, some lives on your computer. All data that lives in Unity can be serialized, some data that lives on your computer can be serialized.

btw, my example might be well and truly flawed, and wrong. I don't yet know enough about serialization to make a good/correct example, and am somewhat hoping any corrections to my example might help me better see where I'm failing to understand serialization of/in/for Unity.

[quote=“Ryiah”, post:3, topic: 712197]
It’s literally just the action of translating data from one format to another. Within the context of Unity it’s transforming it in and out of formats that Unity is capable of working with.
[/quote]

Which data is Unity unable to work with? And, further to this, if it’s unable to work with it, how is it able to serialize it?

If you want data to be stored in a file, so you can read it later, you serialize it. If you want Unity to store data in the scene file, you serialize it. Or it can just live in a script.

That's the best I can do. Maybe someone else will drop by.

1 Like

I only have a very high-level understanding of how it works, but the way I understand it is: C# has a specific way that it stores structured data in memory for it's own immediate use. This is not necessarily the same format as other systems so if you pass that data around, C# has to dump the data to some standard format that other systems can translate (i.e. serialization).

For one thing, the Unity run-time engine is compiled from C++, which handles data differently than C#. ~~Therefore any data in your scripts that you pass to, or is returned from, a Unity engine method must be serialized.~~ Edit: Oops, that part is not true. not sure where i got that idea:sweat_smile: Thanks to lordofduct for pointing that out. As others have mentioned, you also need to serialize data if you want to pass it to the inspector or send it to a file, etc.

Objects are not always serialized by default because scripts will typically contain plenty of objects that do not need passed to the Engine, saved nor exposed in the inspector.

1 Like

[quote=“kdgalla”, post:19, topic: 712197]

For one thing, the Unity run-time engine is compiled from C++, which handles data differently than C#. Therefore any data in your scripts that you pass to, or is returned from, a Unity engine method must be serialized. As others have mentioned, you also need to serialize data if you want to pass it to the inspector or send it to a file, etc.


[/quote]

The serialization has nothing to do with passing data between C# scripts and the C++ compiled unity engine.

C# can easily share the memory addresses of its data. Sharing data structures between the 2 is fairly straightforward. Both ends just need to know the data structure’s layout in memory is all, which for the sort of data we transfer between the 2 it does… like string, floats, ints, etc. There is overhead of course, but it’s not due to serialization.