Why the need for ScreenShakeActions?

[chiswicked]

What purpose does creating a separate ScreenShake and ScreenShakeActions with all the addedd “complexity” of a singleton serve? In my mind the effect (ScreenShake) and to react to events and trigger it (ScreenShakeAction) can happily live in the same class, I can’t really find a strong argument for the need to separate them.

I know just becuse something works (my code example later) it doesn’t mean it’s “right”, but I was just wondering if there’s any conscious design decision I might have missed in the video why this implementation was done using thesingleton pattern and separate classes?

Wouldn’t it be easier, simpler and more readable to do something like this? Any pitfalls, downsides to this implementation?

using UnityEngine;

public class ScreenShake : MonoBehaviour {
    private CinemachineImpulseSource cinemachineImpulseSource;

    private void Awake() {
        cinemachineImpulseSource = GetComponent<CinemachineImpulseSource>();
    }

    private void Start() {
        ShootAction.OnAnyShoot += ShootAction_OnAnyShoot;
    }

    private void ShootAction_OnAnyShoot(object sender, ShootAction.OnShootEventArgs e) {
        Shake(5f);
    }

    public void Shake(float intensity = 1f) {
        cinemachineImpulseSource.GenerateImpulse(intensity);
    }
}

[Synith]

I think the best way to see the purpose behind the separation is to ask yourself:

“How well does my ScreenShake code work if there is no ShootAction class?”

In this case your code ScreenShake code would break if there was no ShootAction class in your project. The ScreenShakeActions class acts as a link between the two solutions so that the ScreenShake code can be called by the ShootAction class without breaking that independence.

This is useful because it lets us re-use our ScreenShake class across multiple projects and situations. As an example you could use ScreenShake in a driving game where you want the screen to shake each time you hit an obstacle. Then you would create a ScreenShakeCrash class (similar to our ScreenShakeActions class) where you subscribe to an event that is called each time you crash and then calls the ScreenShake.Instance.Shake() method.

[CodeMonkey]

Yup like @Synith mentioned the issue with that code is the ScreenShake is now tightly coupled with ShootAction. It will break if ShootAction no longer exists.

ScreenShake is a very nice general effect that pretty much every game uses, so having it be completely separate from any game specifics is a good thing.
That way you can copy paste the ScreenShake class into other projects and the only thing that is project specific would be the in-between class like ScreenShakeActions.

But yes if all you care is just this one game then listening to the events directly on that class would indeed work.

[chiswicked]

Makes perfect sense. Thank you both and thanks for the great tutorial.