

However, it's worth noting that when used that way they don't contain state themselves- the state for the AI is stored as a POCO externally, created and held in the MonoBehaviour, and passed into the SO every frame as needed to process state changes. It goes against their nature as "data bags" for sure, but there's something to be said for the techniques used in that "Pluggable AI" tutorial series. I've actually come around just a little on ScriptableObjects for logical processing. I've read the literature, I understand the stated reasons, but I've used them for years, they have a valid place. I don't know where this "singletons are devil spawn" stuff starts from. These can be highly useful in Unity and there's plenty of tutorials out there about using them in the C# and Unity context to find important parts of your game in the scene. One thing you didn't mention is interfaces. Even OnEnable/OnDisable doesn't really work, not in the way you expect, so don't use those in SOs. ScriptableObjects don't have any such useful hooks. The main point of a MonoBehavior is that Unity pumps it with a bunch of useful messages: Awake, Start, OnEnable, Update, and more, all of which you may wish to respond to.

you can also modify the fields on a MonoBehavior in-scene whether you cloned it or not. MonoBehaviors on a GameObject let you do everything define-wise that a ScriptableObject does (configure custom fields in a prefab or scene), but you can also stick MonoBehaviors into scenes, where they can reference other stuff in the scene and in the Assets folder. That and handing them off to other content creators on the team to make more goodies in-game. To me, that's one of the ONLY points of using them: editing at debug/test time. But unless you have a better inspector (such as Odin Inspector or Advanced Inspector), you won't be able to change anything on a runtime-created SO in the default Unity editor inspector, something which can often be very useful for debugging. That said, you can make them at runtime all day long, which is a handy way to clone preset databags and modify them at runtime without changing the on-disk asset. The only reason to derive from SO rather than just making your own data class (or just keeping data in JSON / XML) is to let you edit it within the Unity Editor and refer to other assets. I am generally enjoying my venture into Unity so far.
Unity ai with scriptable objects software#
First a bit of background, I am new to Unity and component based architecture but have > 20 years of commercial software development and even worked as a game dev back in the PS2 days.
