Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Decouple CameraManager and SpawnSystem - card $194

Discussion in 'Open Projects' started by Tatranskymedved, Dec 4, 2020.

  1. Tatranskymedved

    Tatranskymedved

    Joined:
    Nov 1, 2019
    Posts:
    2
    Hi,

    I'd like to work on that card ($194) and I've almost finished the change - created Event channel for transform type, eventChannelSO, linked all together (cameraManager->eventChannelSO<-spawnSystem) and raising/receiving the event with transform data.

    When removed the old code, I've found there is one more reference to cameraManager in spawnSystem, when we assign this camera to Protagonist:

    SpawnSystem.cs
    Code (CSharp):
    1. private void SetupCameras(Protagonist player)
    2. {
    3.     player.gameplayCamera = _cameraManager.mainCamera.transform; //<======== this line
    4.     _cameraManager.SetupProtagonistVirtualCamera(player.transform);
    5. }
    What is the correct way to assign this camera reference to Protagonist?
     
  2. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    I've merged your PR, as it was exactly the way I was thinking of solving it. But you raise a good point!
    I think the key here is that while for giving a reference of the player to the camera system we can do it with the events (the CameraSystem is always listening, so when the player is spawned, the camera system is there), we can't do the same to give a camera reference to the player. If the CameraSystem were to raise an event in a similar way as what you did for the SpawnSystem, the player wouldn't be there to listen to it yet.

    So... I've introduced a new, very simple concept: I called it "Runtime Anchors". Basically, a simple ScriptableObject with one value inside, in this case of type Transform, that other objects can "watch". The value changes at runtime, but because it's not an event, objects can watch it after it has changed and don't need to be there to be notified.

    This is kinda similar to the famous ScriptableObjectVariables used in Ryan Hipple's Unite talk, with the exception that those are used to provide a way for designers to give values to variables at Edit time. In this case, this is purely a runtime concept since we will use it with Components.

    So I used it within the Protagonist script, which now can watch the Camera's Transform. This is setup by the CameraSystem on OnEnable.

    What do you think?
     
    davejrodriguez likes this.
  3. Tatranskymedved

    Tatranskymedved

    Joined:
    Nov 1, 2019
    Posts:
    2
    Hi Ciro, thanks for merging that PR & you should get it back when I've used wrong names. ;-)

    In regards to Runtime Anchors, I don't see any drawback as of now, but I'm not that experienced in Unity. As I see it, this approach is really cool and it makes a lot of sense to have it set up this way.

    I've actually (randomly) watched that video yesterday of Ryan Hipple before you've mentioned it and was so hyped for this approach. Thumb up!
     
    cirocontinisio likes this.
  4. roboryantron

    roboryantron

    Joined:
    Apr 2, 2014
    Posts:
    5
    I too would like to add a y+ facing thumb