Using Scriptable Object Event System architecture

I think using the Scriptable object event system to handle Dialogue Actions would be more efficient.

It’s based on this talk:
Unite Austin 2017 - Game Architecture with Scriptable Objects

A more specific version:
ULTIMATE Event System for Unity Beginners

The scripts of interest here are GameEvent.cs, which is a scriptable object, and GameEventListener.cs, which sits on every Game object that needs to listen to GameEvents.

We can modify the DialogueNode.cs like this:

        [SerializeField] GameEvent onEnterEvent = null;
        [SerializeField] GameEvent onExitEvent = null;

        public GameEvent GetOnEnterEvent => onEnterEvent;
        public GameEvent GetOnExitEvent => onExitEvent;

This eliminates the use of string references for actions, that are error-prone.

We can modify the PlayerConversant.cs like this:

        public void TriggerEnterAction()
            if(currentNode != null && currentNode.GetOnEnterEvent != null)

        public void TriggerExitAction()

            if (currentNode != null && currentNode.GetOnExitEvent != null)

Now, we can just add a GameEventListener.cs to the Enemies and use the UnityEvents of the GameEventListener to enable Fighter.cs or whatever we want.

This does 3 things:

  1. We don’t have to access the AIConversant from PlayerConversant as AIConversant and DialogueNodes can access the GameEvent scriptable objects independently.
  2. Multiple functions on different game objects can be called when the event is raised.
  3. We don’t have to call foreach loop every time TriggerEnterAction and TriggerExitAction gets called.

I haven’t tried this out yet but will it be a problem if I use this architecture? I’m guessing Brian will be answering this :slight_smile:

1 Like

I don’t see a problem with it. This is a form of the Publisher pattern, and looks like a good way to get rid of those string references that I personally prefer to avoid myself.
Give it a try and report on how things work with this!


Privacy & Terms