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".

 

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

 

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

 

Why would anything, in Unity, be not serializable?

 

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.

 

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

private Type type;

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.

 

A variable.

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

 

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?

 

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.

 

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.

 

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?

 

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.

 

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.

 

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.

 

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.

 

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 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.

 

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.

 

@OP

Serialization is the process of taking an object in memory and converting it into a stream of bytes (a byte array). Those bytes can then be saved to disk as a file, transferred across the internet, placed in a database, or really anything you do with a stream of bytes.

The format of that stream of bytes is determined by the serialization engine used. Just like a txt, doc, rtf, etc all can store text documents, there formats are different. So too can 2 different serialization engines despite storing the same general data.

Any given engine can also have multiple formats. Just like Microsoft Word can save to different formats, so to can something like Unity. When it serializes objects it can due so a binary, yaml, or json.

Unity uses serialization for various tasks. It serializes the layout of a scene to disk as a '*.unity' file. It serializes prefabs as a '*.prefab' file. The state of your components when serialized is often placed in these files.

If you open the yaml for a prefab you'll see something like this (much longer, I've snipped out large portions):

Code (csharp):

1.  
2. %YAML 1.1
3. %TAG !u! tag:unity3d.com,2011:
4. --- !u!1001 &100100000
5. Prefab:
6.   m_ObjectHideFlags: 1
7.   serializedVersion: 2
8.   m_Modification:
9.     m_TransformParent: {fileID: 0}
10.     m_Modifications: []
11.     m_RemovedComponents: []
12.   m_ParentPrefab: {fileID: 0}
13.   m_RootGameObject: {fileID: 1427283817627408}
14.   m_IsPrefabParent: 1
15. --- !u!1 &1004563719413356
16. GameObject:
17.   m_ObjectHideFlags: 1
18.   m_PrefabParentObject: {fileID: 0}
19.   m_PrefabInternal: {fileID: 100100000}
20.   serializedVersion: 5
21.   m_Component:
22.   - component: {fileID: 4703541420559822}
23.   - component: {fileID: 114047302809239072}
24.   m_Layer: 11
25.   m_Name: FX
26.   m_TagString: Untagged
27.   m_Icon: {fileID: 0}
28.   m_NavMeshLayer: 0
29.   m_StaticEditorFlags: 0
30.   m_IsActive: 1
31.  
32. ########## SNIP #################
33.  
34. --- !u!114 &114047302809239072
35. MonoBehaviour:
36.   m_ObjectHideFlags: 1
37.   m_PrefabParentObject: {fileID: 0}
38.   m_PrefabInternal: {fileID: 100100000}
39.   m_GameObject: {fileID: 1004563719413356}
40.   m_Enabled: 1
41.   m_EditorHideFlags: 0
42.   m_Script: {fileID: -1991421567, guid: a8c78d74a98c0bc46ae90e875babbdaf, type: 3}
43.   m_Name:
44.   m_EditorClassIdentifier:
45.   _order: 0
46.   _spawnMechanism:
47.     _spawnPool: {fileID: 0}
48.   _effectPrefab: {fileID: 198201411434012254, guid: d4746526ea186124b9a52f920a30b8d3,
49.     type: 2}
50.   _duration: 0
51.   _spawnAsChild: 1
52.   _onSpawnedObject:
53.     _yield: 0
54.     _targets: []
55.  
56. ########## SNIP #################
57.  

It basically goes through and lists off the gameobejcts, and the components attached (Transform, MonoBehaviour, etc). And the values of the serialized fields for those given components.

It often uses uid's for referencing things like what scripts, objects, and other unity type objects are referenced by these values. So if you have a field/variable that references a GameObject, it will store the uid of that GameObject in here which is a serialized equivalent of a "reference".

You can see this specifically here:

Code (csharp):

1.  
2.   _spawnMechanism:
3.     _spawnPool: {fileID: 0}
4.   _effectPrefab: {fileID: 198201411434012254, guid: d4746526ea186124b9a52f920a30b8d3,
5.     type: 2}
6.  

_spawnPool points at nothing (null)
_effectPrefab points at some other prefab which can be found by that fileID and guid.

...

Not EVERY field is serialized though. Otherwise this file would be full of information that is not necessary. Increasing file size, and increasing the cost/time to serialize/deserialize. So instead unity only serializes that which needs to be serialized.

There's 2 layers to this.

1) Defining what types are serializeable with the [System.Serializable] attribute. This informs unity that you want unity to consider it when serializing. Note that all objects that inherit from UnityEngine.Object are inherently serializable since unity's serialization engine treats them in this special "reference" manner.

2) Defining if a field/variable should be considered serialized using the [SerializeField] attribute. All public fields/variables of a UnityEngine.Object, or a type declared as [Serializable] are treated as serialized. If you want to explicitly tell it to be serialized use the [SerializeField] attribute, if you want to explicitly tell it to NOT serialize use the [System.NonSerialized] attribute.

Only serialize that which you need to. Otherwise you're adding unnecessary bloat to your serialized objects.

...

There are other places serialization is useful then just unity saving your scene/prefab data.

For example save files.

You may want to serialize a save token to disk. You might define some save token like so:

Code (csharp):

1.  
2. [System.Serializable]
3. public class SaveToken
4. {
5.     public int Lives;
6.     public float Score;
7.     public int Ammo;
8.     public int Level;
9.     //...
10. }
11.  

And then you might use the JsonUtility to serializes one of these objects into json:

Code (csharp):

1.  
2. {
3.     "Lives": 5,
4.     "Score": 100000,
5.     "Ammo": 100,
6.     "Level": 5
7. }
8.  

This can be saved in a *.json file (or txt, or honestly any extension... extensions don't force anything, but that's another topic all together).

Then you can deserialize that file later (next game) and recreate a SaveToken from it.

NOTE - this SaveToken will have the same data in it. But isn't necessarily the same object. This is obvious if you load it the next day after reloading the program. But if you were to serialize and then deserialize all in the same session... the 2 objects will be distinct.

This is why Unity has to perform special tricks to store UnityEngine.Objects by reference in its serialized representations.

This is also why you can't nest serialized types in NON UnityEngine.Objects like so:

Code (csharp):

1.  
2. [System.Serializable]
3. public class Foo
4. {
5.     public int Id;
6.     public Bar BarRef;
7. }
8.  
9. [System.Serializable]
10. public class Bar
11. {
12.     public int Id;
13.     public Foo FooRef;
14. }
15.  

A Foo refs a Bar refs a Foo refs a Bar refs a Foo refs a Bar refs a Boo. Serialization does not distinguish them as unique objects with identity and instead will infinitely nest in on itself.

This pertains only to NON UnityEngine.Objects, as I've said, Unity has a special case for those.

...

This all has to do with Unity's serialization though.

Serialization is not unique to Unity. Lots of programs serialize data. Most programs that create files do serialization since that file is most likely a serialized representation of some data.

Like 3dsMax or Blender model against data in memory and then serialize them into *.max, *.fbx, *.obj, etc files.

This also means you can use alternative serialization engines in your games. For example in my games I use the .net System.Serialization framework for serializing and wrote a custom json formatter for it:
https://github.com/lordofduct/space...ree/master/SPSerialization/Serialization/Json

The rules that this engine uses sort of overlap with Unity's rules (since Unity hijacks the System.Serializable, and System.NonSerialized attributes). But that's just because Unity decided to recycle existing attributes rather than define their own.

But this engine doesn't know how to properly treat UnityEngine.Objects so can't really serialize those. Also its default behaviour about what fields/variables get serialized differs, for instance all fields, regardless of access modifier (public/private/protected/internal), will be serialized unless explicitly told not to with [System.NonSerialized].

...

TLDR;

Serialization is the changing of object data into a byte stream that can be save to disk, database, sent across the internet, or used in any manner a byte stream can be used.

Unity uses serialization for many tasks, usually for us developers we're concerned with its saving scene/prefab/asset files.

Serialization is not unique to Unity, and can be done in numerous ways. You may use it for save files, or for packing data and sending to a server.

 

One more random note: Unity found serializing things difficult because their system had to work synonymously between C#, UnityScript, and Boo. The later two pigeonholed them to have fewer serialization options. Now those have been fully removed, they will be able to eventually look at adding more choices to serialization.

 

I never considered that...

Some of the lacking issues in unity's serialization has driven me nuts. I never bothered to stop and think about it from a UnityScript/Boo perspective.

I hope they do remedy some of my biggest issues with their current system. Things I'd love to see done different:
1) Allow serializing by object type, not by field declared type... thusly allowing things like interfaces.
2) Add a serialization context to the serialization callback so that you don't have clutter up your class with data containers used only for serialization.

 

@lordofduct THANK YOU!!! That's the kind of description and explanation that restores hope in the human race's ability to communicate. Exceptional. CHEERS!

@kdgalla, THANK YOU!!!, that's well said, and from about the same abstraction I see programming's "science-iness"

@Nigey THANK YOU!!! that's exactly the insight needed to understand why serialization isn't as ubiquitous as it might otherwise (or normally) be expected to be, considering what it provides. This, for me, was the roadblock I couldn't see to understanding why it is the way it is.

---------
I hope this helps others as it has me and/or I can repay this in some way, at some time... when I might know something others don't... unlikely

"I know boats!"

 

Using attributes is frowned opon in the business world. Unity will get there eventually. We use Newtonsoft in our game which is a better json serializer

edit: We are offcourse forced to use it for Mono Bs

 

Sorry. Almost none of this makes any sense to me.

I can read the words, and they make sentences, but I lack the context and wisdom of a programmer.

 

You're not missing much. Many of his statements involving "business world" and "enterprise" only apply there.

 

Probably

I remembered a flatfile serializer that I inherited from some devs at a bank (Flatfiles are a big thing in the banking world still to this date). I dont remember the synstax exatly but it was something like

Code (CSharp):

1. [Flatfile]
2. public class MyType
3. {
4.    [Column(Length = 10)]
5.    public string Name  { get;set; }
6. }

Problem was the entire domain had a dependency to flatfiles because of this. I refactored it to use a fluent syntax instead. (Dont remember the exact syntax, but something like);

Code (CSharp):

1. FlatFileMapper
2.    .Map<MyType>()
3.    .Column(mt => mt.Name)
4.    .Length(10);

 

If more game devs applied the same principle we do in the business world QA would not be the big problem it is today in the gaming industry

 

I've used business software. Lots of it. Across the board, the QA in business and enterprise is worse than anything else I've seen. It's as if "computer scientists" and "software developers" are drawn like bees to the flowers of unaccountability and freedom from responsibility provided by the labyrinthian and byzantine systems and procedures of enterprise. They may well have, also, played a role in making it so.

I'm not suggesting Unity doesn't have more bugs and caveats, peculiarities and oddities, require more workarounds and constant consideration of its armies of foibles, inefficiencies and systemic problems than other creative software. It does.

But making sweeping statements about QA in business and enterprise software being better than that of produced games can only come from someone with a narrow perspective of both.

 

If this had never transpired in this manner, would it be possible to consider making serialisation somewhat automatic, and universal to any and all forms of things that can be made (and used) within Unity?

Sort of like "if you need it serailized, it can be done..." for all things, at all times, to and from storage in any states. Or something like that, so that it wasn't ever needed to be considered a process with rules and limitations, just an option.

 

They had a big conversation over this when explaining their logic behind removing UnityScript. It hindered a lot of what they could do. One of the key limitations was what they could serialize. As I recall they do not automatically serialize data. It's converted to C++. There is logic to implement for serialization to work. However, in that talk I mentioned, they said part of their intentions was improving what could be serialized. I expect this in some future update.

 

I come from the business world.

We use attributes.

As with any tool that has the potential to be abused, teams will usually have rules surrounding them. Just as they have rules surrounding just about every other part of the language. And I bet there are teams that bar them out right so not to give their juniors any wild ideas about attempting to meta program with attributes or something like that.

But they're still used. Sometime they're required.

Just like with Newtonsoft Json, which has attributes.

 

So does Entity framework, but Microsoft recommend the Fluent mapping for good reasons.

 

Your opinions, they're full of such well formed arguments abounding with evidence. Such a breathe of fresh air from those who post implied allusions to the intents of others and their positions of authority.

I just read @Deeeds response after posting mine.

I think they nailed it right on the head. So I'm just going to repeat that:

:applause:

 

If you reply to a person quote his message otherwise you might not get a response since the person will miss it.
You shouldn't question authority so i dont really need to give any reasons.

But I did give you reasons it pollutes the domain with dependencies.¨

You just executed a classic argumentum ad hominem, cute.

 

I flaunt in the face of authority by not quoting their posts!

I like that you picked up on my ad hominem... yet you failed to see why I used it. Captain argument from authority.

 

This is literary the best explanation of what it means to serialize data. A easy way to see this in action would be to compare a PDF document to a Word document. Two different formats but the same text. Their are many ways to serialize data into many different formats such as XML, Text, JSon etc. If you want to see the "magic" in action, create a simple class and save it or "serialize" it to a XML format and then import it and de-serialize it back to the original class or "format". Your literately just transforming your data into a new format. This can have many uses and allows your data to be more dynamically stored & accessed. I hope this makes sense.

 

The way I understand it, serialization give anybody who has access to the Inspector, to edit whatever that was serialized. Othewise you need access to the code files to change or modify them.

once

Code (CSharp):

1. Type type

is declared you need to set it's value in Start or in some function as may be required. But if it is serialzed you can edit it direct in the Inspector withut touching the code files and accidentally screwing them up. It gives Non Coders the ability to edite code variables etc.
If my understanding is wr

 

Hopefully really simple explanation of why something could not be serialised:

Imagine you have a timeOfDay timer.... you might have loads of really complicated logic that sets its current time. When the server sends the timeOfDay to thje client, it doesnt send the whole "Timer", it would send the "timeOfDay.currentTime" value. In this instance, the serialize just ran the function, and serialized the output.


Now, in this example, you could probably write a version of the "TimeOfDay" timer, in Javascript or any other language, in this case, you could actrually write a "timeofDay" serialiser after all

However, if the object in question was some complicated Unity3d Object with hooks into the OS via directX etc. Then you would never be able to write the exact same object in Javascript. If you can you are a genious and too rich to be sitting here!. In this case... you may not be able to write a "Serialiser" from unity to JS. Maybe it would serialise ... Player.CurrentPoisition.X instead.

 

This is an old thread, but I just wanted to clarify:

• Unity serializes public fields by default, but not private ones.
  
  
• This is why we can see public fields in the editor, and why we can't see private fields.
  
  
• Therefore, private fields need to be serialized, (i.e. have the [serializable] attribute added) in order to be visible in the editor.

Hope this helps anyone reading about this.

 

Damn, I had the exact same question. I'm like why do I see examples of code randomly throwing the word serializable on a field like why do only certain variables require this special privilege? After reading through I think I understand, it a lot better. The randomly throw, is not so much random but the developer's choice. It may be for whatever reason, but what it does is it allows private variables to be displayed on the inspector. For other's to enter/see the values, or just as a quick way to watch variables I guess. I just have to know that, it is one of the possible ways to improve load scene speed.

 

This is not really true. Private fields need to have [UnityEngine.SerializeField] attribute.

Which is something you can apply to public fields as well. A good practice, because it communicates clear intent, instead of letting everyone stumble in the dark. Implicit serialization is a great blunder by Unity: their early ideas about what would come across as user-friendly collided heavily with how most of these decisions turned out to be sources of major confusion among its users.

Pure C# classes and structs need to have [System.Serializable] attribute to be serialized via fields. So you've mixed the two attributes.

 

This is already an old and relatively long thread, and everything that warranted explanation is already basically explained in posts #2 and #3 and that was five years ago. Regardless, if anyone reads this and cares about these kinds of explanations, I'm willing to shed some light on why Unity actually uses serialization.

I think I saw a post above where someone asked 'what's the point in translating something that's already known'. Well, here's the answer:

Unity's editor is full of assets, objects, relationships, cross-references, and loose data.

During its uptime, most if not all of these things are somewhere in RAM, acknowledged by the main software, ready to be presented, while being logically and logistically connected with the system. When you decide to shut it down, however -- including the situations in which one environment needs to shut down before another loads up (like hitting Play) -- Unity simply needs a save game file, to a) reliably switch the context, b) refresh internal state.

Serialization is a means of translating the volatile data and relationships that live in the memory (volatile because they're only associated via transient locations in memory), into a much more permanent and standardized file storage, which in case of Unity, mostly comes in the form of YAML, a simple, human-readable file format. Thus "reconstructing" means that Unity is able to deserialize this data back to assets, objects, relationships, cross-references, and loose data. It can effectively regenerate dynamic state from static file organization, which is an incredibly powerful feature for a potentially complicated piece of software.

This makes the editor more secure and allows you to be more independent of its internal volatility, because it relies on two modes of data storage, one for speed and distributivity and the other for portability and reliability. Plus you get to distribute its state over the network, produce a backup of, contain it in a version control system, or even edit manually. Having a hybrid programmable environment where the non-coded state of the editor can be dumped to a fixed source file is the engineer's wet dream, and honestly the only way to produce a fully sustainable machine for serious development.

 

Those are really good questions. And I don't see good answers to them

 

You should read this thread you posted in then.

 

Serialization is about transportability.

Could you just save the state of your program? Sure. That's how "save states" in emulators work, they just dump the current state of the program into a file. Of course this works great for old consoles whose work RAM is in the kilobytes. Even the Playstation only had a couple megabytes of work RAM (2MB for work ram, 1MB for video ram). Downside though? All you have is the state of the program. It literally brings you right back to where the program was at that moment.

What if I did that for my word processor? Or for my 3d modeling software? I wouldn't just be saving my document, I'd be saving the state of Open Office or Blender! I hope you have Blender too! And I better only have ONE model open else I have everything else in there as well. Good ol' fat file full of models as well as the entire Blender display including the mouse position? Wat?

But I just want an .fbx file of just the correct data that is my model. I don't need all that other stuff.

Also... what if I'm on a completely different platform? What if you're on an x86 system with Windows and I'm on an ARM system with MacOS? Does Blender on MacOS know how to handle the memory state from the x86 system? Is the x86 big or small endian to my big or small endian? Is it 32-bit or 64-bit? WHAT IS GOING ON???

This is the usefulness of serialization. It allows you to define what data you want stored and how you want it stored so that it can be transported.

And maybe you're like "well I don't need it to transport to another platform, I just need it to save to disk for later". OK. That's fine. That just means you need a less complicated version of saving to disk. Hey... maybe that "save state" approach will get the job done! The point is... you need to pick SOMETHING. And that choice of how you're translating your work memory to storage data is.... serialization.

So... I feel like this sentence right here is emblematic of the disconnect people are having.

The screwdriver that screws the screw.

You see the word "serializable" and think this is serialization. When it's just one kind.

Why mark something serializable? Because that's the way that the serialization system that uses that attribute expects to be used.

Not all serialization systems are like that. Newtonsoft Json.Net doesn't require any attributes to tell it to serialize a thing. You hand it an object and it will reflectively serialize what it can! It is explicitly exclusionary in that it will exclude only that which it can't serialize or it's told not to serialize.

Unity's built in serialization system on the other hand has to be told what to include. It has some default inclusions (like public fields), but for the most part we tell it to serialize via the attributes. I ain't going to lie... the rules of the Unity serialization aren't exactly consistent in inclusion vs exclusion. But that's not serializations fault... that's Unity's fault! And Unity isn't the only way to serialize data!

You could write your own serialization however you want!

If your game only requires storing the player's lives count, the current score, and the current level. You could pack that all into 12 bytes. 3 ints stored in memory. Hell maybe even less... if your life count could never exceed 255, and there is < 255 levels. You could pack it into 5 bytes (1 byte for lives, 1 byte for level, 4 bytes for int score). Heck if you limit it further you could make it even more compact no more than 10 levels or 10 lives and a score less than 65K? You could store that all in 3 bytes... 2 for the score, and half byte for lives, and half byte for level.

And your program would just need to know that's the format, to parse it (deserialize) as such, and place the data into work memory as needed.

This right here is how old games saved stuff. When you saved your game to a memory card back in the day... those memory cards had VERY LIMITED storage space. So games would save the data in very compact custom formats!

...

If you don't like that you have to mark something serializable... well in the case of your own save files, pick a new serialization system! Heck, write your own!

In the case of Unity's scene/prefab/asset serialization. Welp... pick a new game engine then! Cause that's just how Unity does it! Is it right? Eh... doesn't matter. It's just how it's done here.

The benefits of doing it the way Unity does it are not some rules of the gods saying this is how serialization is always done. They're this because that's how Unity wants it done. Just like if you come into my grandmother's house you're expected to take your hat and shoes off. Why? The shoes are so you don't track mud, and the hat is because... tradition. That's just how it is. She thinks it's rude for you to wear a hat inside. Centuries ago there was a reason that someone came up with and it has stayed within the culture she is from and no one knows why... it just IS.

And guess what... in programming we sometimes have those same traditions. Sometimes we just do things certain ways because that's the way it's been done. Sure you could make arguments in favor or against... but you can never get the "correct" answer cause it's all dumb. Hence why programmer communities will complain until the cows come home about how THEIR way of programming is better than YOUR way of programming.