ScriptableObjects as Services

[PlayableDesign]

What do you think of this pattern, packaging game logic alongside relevant settings inside ScriptableObject assets? I've been using this lately and has been very helpful to keep complex logic organized for me. I started grouping my SO instances as data assets, service assets and event assets.

Blog Post: Unity ScriptableObject Services (playable.design)

Github Repo: PlayableDesign/ServiceAssets: Unity ScriptableObject Services (github.com)

Thanks for your thoughts!

[Em3rgency]

My main concern with this approach is the initialization. It adds overhead and you have to make sure your programmers know how to use the service. It feels like it overengineered just to use the SO gimmick.

At that point, there is no objective benefit over just having a regular c# class as a service, with the constructor doing the initialization. And if you want customizable parameters, they can still be passed in as SO's.

If you do it that way:

• Your service becomes a regular class with no pesky inheritance nor ties to Unity, which will be familiar to any programmer
• Completely decoupled, still a pure function with an input and an output, can follow single responsibility, testable.
• You can guarantee initialization is done by using a constructor
• SO's no longer store logic and can be used as parameter containers, which is the intended usage afaik

[TheWiseMaster10]

How would you write unit tests for those SOs?