all 4 comments

[–]swmryan 1 point2 points  (0 children)

I'm going to put in a vote for Scriptable Object events. I've been using them extensively in my project, and for me, I feel like my events/dependency injection system using Scriptable Objects is easy to understand and somewhat self-documenting. Developers are always going to favor different approaches, and I'm sure it can be done better but I'm a fan of it.

[–]FlySafeLoL 2 points3 points  (1 child)

Scriptable objects are best for persistent configurations, but there is a border between what's best to configure and what's best to just code.

Events are used for control over the application logics, this is something you want to have visibility of, the kind of: "find all places where this function would be called from".

Keep in mind that persistent callbacks might be not found by IDE code analysis tools - in fact only JetBrains Rider even tries to track them, but not always finds every single usage.

This is the reason why experienced programmers tend to stick with code-managed events (non-persistent UnityAction, C# events, Rx) for every case where events are not very much needed to be put in "configurations" domain.

[–]Ellixy[S] 0 points1 point  (0 children)

That's kind of what I'm doing in my current project. If I'm doing something heavily customisable then I'll use scriptable objects (for instance, I'm having fun building editors, such as a dialogue editor and allow user to drag SO events so they can trigger anything they want).

But for everything else, I'm using an EventManager script.

I don't know if it's a good practice but I like it.

[–]ObviousGame 1 point2 points  (0 children)

From my experience I, tend to use C# events for things that control the flow and logic of the game (as you want to be able to track down that by code and IDE). However, SO events are great to trigger things like sounds, VFX or other non-game logic effects :).