That’s a very weird limitation that complicates project structure very much, it makes grouping classes a pain.
With plain single-class scripts it doesn’t hurt much, but when I have two unity classes that describe the logic of a single object type, they should go together, but I must put them into separate files and it becomes very uncomfortable to work with them. For example, a MonoBehaviour (ViewModel) and a ScriptableObject that holds its data (Model) and many other ViewModels and Models that extend these two classes respectively that make up the hierarchy of object types in the game, so I want them to be contained in pairs. If I replace the ScriptableObjects with plain C# classes, then I still need to name the files where they are contained with MonoBehaviour’s name and I lose the built-in serialization. So, it becomes “SomeObjectVM.cs” at best and this file would contain “SomeObject : Model : System.Object” and “SomeObjectVM : ViewModel : MonoBehaviour”. The letters “VM” make no sense in the naming of a file, because the plain model is the “main” part of the object. What makes it worse is that I just see no point in why this limitation even have to exist. Maybe it has something to do with Unity’s old scripting languages, but there is no reason to keep such a big inconvenience now. Unity’s devs probably could allow script assets to contain multiple actual scripts, just like multi sprites work.
Hope I explained my case sufficiently good…
There is a reason it works like this: this is how each Monobehaviour/ScriptableObject class gets their own GUID, which allows them to be referenced by the serialization system.
In theory, it could probably be possible to extend the system to scan for all MB/SO classes in a script and treat them as sub-assets like sprites, but this sounds like it would be more brittle since it would only take a rename to completely lose all the references to a class.
This is solvable with proper IDE integration, just have “Rename class” action alter the corresponding meta, so GUIDs are kept
Please remember that this is a limitation only if you attach the class in a GameObject at design time. If you add/use it in runtime (with AddComponent), you can have many classes on same file.
I don’t think they will invest any time for a use case that is considered a bad coding practice by most professionals, every C# coding guideline suggests the “1 class per file” rule
That’s not good, now the project depends on having a working IDE extension to not break when editing script files.
Thanks for pointing this out! This may help me. But it still would be nice if they added proper support for this
What you’re asking for is considered a bad practice.
In most cases you should have only one class per file.
Otherwise both readability and maintainability of the code will suffer.
Also, you don’t have to move every single bit of data to the ScriptableObject.
Prefabs exist for a reason.
That’s a good point. Currently you have to rename the file and it’s meta to preserve references, if this change will be introduced you would have to edit the meta contents
My case requires that models (which store actual data, which is saved to disk) can live outside the scene and I use prefabs for designing view models (well, rather not models, but view, since view model is the class that controls a game object and view is the game object itself), that link with data models. View models provide visual representation of models’ data and respond to its changes. Maybe it is a bad practice, but not in all cases. Having all parts of the object’s logic is good for designing links between object’s look and its data
Do all these classes really need to be MB/SO? For plain C# classes you’re free to organize them as you see fit, and if you need them to be editable in inspector you can make them serializable as well, so you could have some MB components which are just think wrappers designed to associate your plain C# classes with scene game objects.
ViewModels are MonoBehaviours (they control animations and various values displayed on objects and handle some input events) and Models are ScriptableObjects or plain C# classes to store object states
This way I’m already kind of solved the problem, the pairs are grouped into single files. The engine support just would allow me to properly name each file (drop the “VM” prefix). I created this thread purely to know the reasons of this limitation and the possibility of its removal in the future
This.
Yes, you’ve explained it well enough, but a use case of “I prefer to do things this way” is not good justification for the time and effort it would take to change everything. If you had no choice but to work this way it would at least be understandable but all you want it implemented for is to satisfy a personal desire.
Imho this was properly answered by:
and
and
In addition to that: NOT implementing the feature you desire does not have to have been a conscious act by the devs. It may just be a side effect of all the things mentioned above.
Thanks, I got it