Return to Answer

If you want to completely decouple the tutorial logic from the regular game logic, then you might need to redesign your software architecture to an event-based architecture. You already seem to know how UnityEvents work, but an event-based architecture means that you use them much more extensively to separate the detection of a condition from all the different reactions to it. If you follow that paradigm thoroughly through your whole software architecture, then you gain a lot more flexibility because every separate reaction to an event is loosely coupled.

That means that when something in your game happens, like the player receives 10 damage, then you don't reduce the HP there and then. You invoke an event (tookDamagedEvent.Invoke(this, 10)). Each event can have multiple subscribers. So each reaction to the event should be a separate handler. In this case:

• Reducing the players HP
• Updating the health bar
• Playing the pain sound
• Showing the tutorial

would all be separate methods subscribed to this event.

OK, but how does that help us to change behavior at runtime?

Remember that you can also add and remove event subscriptions at runtime via tookDamagedEvent.AddListener(handlerMethod) and tookDamagedEvent.RemoveListener(handlerMethod). And when you declare the tookDamagedEvent as public, then systems like the TutorialManager can just add and remove themselves without the invoking MonoBehavior having to be aware of their existence. And they can even subscribe or unsubscribe handlers belonging to other objects. So the tutorial system can also temporarily remove the listener of the pain sound and re-add it after the tutorial is over. So by turning the sound into yet another event reaction, you do enable the tutorial system to "skip or modify default behavior".

If you want to completely decouple the tutorial logic from the regular game logic, then you might need to redesign your software architecture to an event-based architecture. You already seem to know how UnityEvents work, but an event-based architecture means that you use them much more extensively to separate the detection of a condition from all the different reactions to it. If you follow this paradigm thoroughly through your whole software architecture, then you gain a lot more flexibility because every separate reaction to an event is loosely coupled.

That means that when something in your game happens, like the player receives 10 damage, then you don't reduce the HP there and then. You invoke an event (tookDamagedEvent.Invoke(this, 10)). Each event can have multiple subscribers. So each reaction to the event should be a separate handler. In this case:

• Reducing the players HP
• Updating the health bar
• Playing the pain sound
• Showing the tutorial

would all be separate methods subscribed to this event.

OK, but how does that help us to change behavior at runtime?

Remember that you can also add and remove event subscriptions at runtime via tookDamagedEvent.AddListener(handlerMethod) and tookDamagedEvent.RemoveListener(handlerMethod) or activate and deactivate event listeners assigned via inspector with tookDamagedEvent.SetPersistentListenerState(index, state). And when you declare the tookDamagedEvent as public, then systems like the TutorialManager can just do so themselves without the invoking MonoBehavior having to be aware of their existence. And they can even subscribe or unsubscribe handlers belonging to other objects. So the tutorial system can also temporarily remove/deactivate the listener for the pain sound and restore it after the tutorial is over. So by turning the sound into yet another event reaction, you do enable the tutorial system to "skip or modify default behavior".

If you want to completely decouple the tutorial logic from the regular game logic, then you might need to redesign your software architecture to an event-based architecture. You already seem to know how UnityEvent's work, but an event-based architecture means that you use them much more extensively to separate the detection of a condition from all the different reactions to it. If you follow that paradigm thoroughly through your whole software architecture, then you gain a lot more flexibility because every separate reaction to an event is loosely coupled.

That means that when something in your game happens, like the player receives 10 damage, then you don't reduce the HP there and then. You invoke an event (tookDamagedEvent.Invoke(this, 10)). Each event can have multiple subscribers. So each reaction to the event should be a separate handler. In this case:

• Reducing the players HP
• Updating the health bar
• Playing the pain sound
• Showing the tutorial

would all be separate methods subscribed to this event.

OK, but how does that help us to change behavior at runtime?

Remember that you can also add and remove event subscriptions at runtime via tookDamagedEvent.AddListener(handlerMethod) and tookDamagedEvent.RemoveListener(handlerMethod). And when you declare the tookDamagedEvent as public, then systems like the TutorialManager can just add and remove themselves without the invoking MonoBehavior having to be aware of their existence. And they can even subscribe or unsubscribe handlers belonging to other objects. So the tutorial system can also temporarily remove the listener of the pain sound and re-add it after the tutorial is over. So by turning the sound into yet another event reaction, you do enable the tutorial system to "skip or modify default behavior".

If you want to completely decouple the tutorial logic from the regular game logic, then you might need to redesign your software architecture to an event-based architecture. You already seem to know how UnityEvents work, but an event-based architecture means that you use them much more extensively to separate the detection of a condition from all the different reactions to it. If you follow that paradigm thoroughly through your whole software architecture, then you gain a lot more flexibility because every separate reaction to an event is loosely coupled.

That means that when something in your game happens, like the player receives 10 damage, then you don't reduce the HP there and then. You invoke an event (tookDamagedEvent.Invoke(this, 10)). Each event can have multiple subscribers. So each reaction to the event should be a separate handler. In this case:

• Reducing the players HP
• Updating the health bar
• Playing the pain sound
• Showing the tutorial

would all be separate methods subscribed to this event.

OK, but how does that help us to change behavior at runtime?

Remember that you can also add and remove event subscriptions at runtime via tookDamagedEvent.AddListener(handlerMethod) and tookDamagedEvent.RemoveListener(handlerMethod). And when you declare the tookDamagedEvent as public, then systems like the TutorialManager can just add and remove themselves without the invoking MonoBehavior having to be aware of their existence. And they can even subscribe or unsubscribe handlers belonging to other objects. So the tutorial system can also temporarily remove the listener of the pain sound and re-add it after the tutorial is over. So by turning the sound into yet another event reaction, you do enable the tutorial system to "skip or modify default behavior".

If you want to completely decouple the tutorial logic from the regular game logic, then you might need to redesign your software architecture to an event-based architecture. You already seem to know how UnityEvent's work, but an event-based architecture means that you use them much more extensively to separate the detection of a condition from all the different reactions to it. If you follow that paradigm thoroughly through your whole software architecture, then you gain a lot more flexibility because every separate reaction to an event is loosely coupled.

That means that when something in your game happens, like the player receives 10 damage, then you don't reduce the HP there and then. You invoke an event (tookDamagedEvent.Invoke(this, 10)). Each event can have multiple subscribers. So each reaction to the event should be a separate handler. In this case:

• Reducing the players HP
• Updating the health bar
• Playing the pain sound
• Showing the tutorial

would all be separate methods subscribed to this event.

OK, but how does that help us to change behavior at runtime?

Remember that you can also add and remove event subscriptions at runtime via tookDamagedEvent.AddListener(handlerMethod) and tookDamagedEvent.RemoveListener(handlerMethod). And when you declare the tookDamagedEvent as public, then systems like the TutorialManager can just add themselves without the invoking MonoBehavior having to be aware of their existence. And they can even subscribe or unsubscribe handlers belonging to other objects. So the tutorial system can also temporarily remove the listener of the pain sound and re-add it after the tutorial is over. So by turning the sound into yet another event reaction, you do enable the tutorial system to "skip or modify default behavior".

If you want to completely decouple the tutorial logic from the regular game logic, then you might need to redesign your software architecture to an event-based architecture. You already seem to know how UnityEvent's work, but an event-based architecture means that you use them much more extensively to separate the detection of a condition from all the different reactions to it. If you follow that paradigm thoroughly through your whole software architecture, then you gain a lot more flexibility because every separate reaction to an event is loosely coupled.

That means that when something in your game happens, like the player receives 10 damage, then you don't reduce the HP there and then. You invoke an event (tookDamagedEvent.Invoke(this, 10)). Each event can have multiple subscribers. So each reaction to the event should be a separate handler. In this case:

• Reducing the players HP
• Updating the health bar
• Playing the pain sound
• Showing the tutorial

would all be separate methods subscribed to this event.

OK, but how does that help us to change behavior at runtime?

Remember that you can also add and remove event subscriptions at runtime via tookDamagedEvent.AddListener(handlerMethod) and tookDamagedEvent.RemoveListener(handlerMethod). And when you declare the tookDamagedEvent as public, then systems like the TutorialManager can just add and remove themselves without the invoking MonoBehavior having to be aware of their existence. And they can even subscribe or unsubscribe handlers belonging to other objects. So the tutorial system can also temporarily remove the listener of the pain sound and re-add it after the tutorial is over. So by turning the sound into yet another event reaction, you do enable the tutorial system to "skip or modify default behavior".