About scriptable object architecture and the implementation of generic unity objects

[Ivan-Vankov]

Hello!
I have been a fan of the idea of scriptable object architecture ever since I first saw Ryan Hipple's talk on the matter.
This project is by far the best implementation of that idea that I have seen.
I've tried integrating several scriptable object architecture projects into my workflow.
However when my projects reach a non-trivial size I always reach roadblocks that I am unsure how to overcome.
I want to ask you about those roadblocks and how you would go about overcoming them.
I would also like to ask some questions about the specifics of this project.
I will ask one queation at a time so that this discussion doesn't become too bloated.
Question 1: Why generate dlls for generic unity objects instead of just generating class files directly?
Is it to make sure people don't modify and potentially break them?
The whole process takes about 5 seconds per type. It is instant every other time you reuse that generic unity object type but still, 5 seconds is 5 seconds.
I have tried to implement a scriptable object architecture project myself and I just generate the file directly under a directory in the assets folder.
The file generates pretty much instantly, I just wait for the domain to reload.

[SolidAlloy]

Hi, thanks for such interest in this project. I'm glad it comes in handy for someone.

About DLLs: yes, it was primarily done to make so that C# projects don't get cluttered with auto-generated scripts and so that there are no issues when you refactor your generic classes. My first implementation of generic scriptable objects was through plain scripts, and as I worked with them, it quickly became apparent that some refactorings may mess up the code in generated scripts in ways that are sometimes hard to fix. When you just change the name of the generic class, it's usually not a problem, but if you change the name of a generic parameter and some namespaces, and god knows what else, it may lead to compilation errors in the generated scripts that are hard to fix. And there may be hundreds of generated classes. The plugin can't recover from the failed compilation state because no C# code will work if the project does not compile. On the other hand, when you create a DLL, and it contains some failed code, it usually does not throw errors until someone tries to use this code. And even if it has invalid code, the Unity solution compiles successfully even without the failed DLLs, so you can track issues in generated classes and re-generate the DLLs.

Long domain reload time when a concrete type is generated: it happens because of two reasons, and both are caused by Unity, so unfortunately I cannot resolve them from my end.

• When a new DLL is generated, I make it not referenced by any assembly definitions. Logically, it should not trigger any recompilation because no dependencies of C# projects were changed. But Unity recompiles all the assembly definitions for some reason, and that's why the domain reload is slow.
• If a generic scriptable object script has a custom icon, this icon will be set for all the generated concrete classes too. Unity doesn't let me generate a DLL and set a custom icon for it in one go, so I do it after the DLL is generated and the domain is reloaded. Switching an icon on a script or DLL causes a new domain reload. Gladly, it is an empty domain reload where no scripts are recompiled, but still, it is a dumb action that has no effect. I reported it to Unity to which they replied that it is a core system that will take too much effort to rewrite. So I figured better wait 1-2 seconds for those initial generations of concrete classes than discard the idea of seeing all those fancy icons on variables, scriptable events, and so on.

Of those 5 seconds, the actual code generation takes maybe 200-300 ms, no more. Everything else is the excessive domain reloads and recompilations caused by Unity.

[Ivan-Vankov]

Guess we will just have to live with those initial load times.

Question 2: How should you handle nested variables?

The classic example for a variable is an implementation of player health with Variable<int>. This, however, is a toy example. In a real game the player health would be a class onto itself, so Variable<PlayerHealth>.
Lets say PlayerHealth has a collection of modifiers (-20% debuff, +10 flat buff and so on).
If we want to display and change them in UI we can make them variables.
So in PlayerHealth we can have Reference<List<Reference<Modifier>>>.
Uh oh, we can't have variables with nested generic types (at least I think we can't, it was written in the documentation that it was not supported although technically possible).
We can make List<Reference<Modifier>> into its own type, ModifierRefList.
Uh oh, nested variables are not displayed properly.
I have opened an issue about this.
There are actually more problems than specified in the issue.
ModifierRefList implemented as:

[Serializable]
public class Modifier {}
[Serializable]
public class ModifierRefList : List<Reference<Modifier>> {} 

Does not have its initial value displayed at all:

However, even if it did display properly it would be awkward to work with.
If you wanted to see the first modifier you would have to click the "initial value" foldout of the PlayerHealth variable, then the foldout for the ModifierRefList, then the "initial value" foldout again, then the foldout for the first element in the list and finally then the "initial value" foldout of the modifier.
That is 5 clicks compared to the 2 necessary if PlayerHealth was a regular scriptable object with no Reference fields.

The scenario I have laid out has many problems.
They all become worse the more you nest variables.
I asked about a subset of these problems in the unity atoms discord and was told to just avoid nested variables and "keep it simple".
That was quite disheartening.
I had decided to abandon variables altogether and just use events and constants, however I want to ask you how you would approach these problems and if they are really solvable.

[Ivan-Vankov]

@SolidAlloy Are you ok? You haven't been active on github for a while.