A Bit Confused Re: PlayerCameraManager && Non-FPS camera setup in general

[Nsomnia]

For my game each unit will have one camera a external ‘Unit cam’ to allow free view around the unit within a certain range. Simple. Spring arm and camera.

My players unit however will have multiple cameras, one unit camera like the rest but also cameras with clamped pitch and can move up and down vertically a certain distance as well as zoom in/out.

Originally I was creating a standard UnitCam in my base pawn class so that each one had it, and then my players unit class had the additional cameras; needly to say having to get all cameras and deactivate all of them then activate the one needed, especially when the number of units (and thus unit cameras) can be ever changing from 1(just the player) to dozens if in a heavy battle.

So I finally decided to play around with the PlayerCamagerManager class, as it seems to allow me to remove all the camera logic from the pawn classes or player controller and keep it nice and tidy in a seperate class.

What would be the best practices for a setup like this? I originally thought I would just add a spring arm and attached camera to the PlayerCameraManager but now I realize it spawns a camera in by default on the currently possesed pawn with no way to enable/disable it, or even translate it through the blueprint.

I will delve into the C++ as I’m watching the twich stream “flexible camera control through C++” and maybe get rid of the defalt camera spawning logic so I can blueprint my own setup.

Am I going in the right direction?

TLDR: How best to use the camera controller class Blueprints & C++ for a non-first person shooter game (vehicle combat simuator) where the player has multiple cameras and each unit has a camera, but only one can be active at a time, to keep things clean and future proof.

Edit: I should add that I noticed even trying to add an offset or rotation to the default TransformComponent scene component inherited from c++ in the PCM bp, does nothing since the PCM seems to stay the player spawn point. Maybe I’m stuck with having to do camera control through the player controller and indivudally activate one camera and deactivate the rest through many careful loops?

Whats most confusing is even ticking SetActorLocation(0,0,0) keeps the actor set to where the currently active pawn is, how is this behavior defined?

What makes sense to me, but seems less future proof and harder to modify is to have each pawn create a camera/spring arm setup on Possess and destroy them on UnPossess and the player would then destroy all camera and spring arm components and create the camera/springarm setup needed through a custom event when switching to one of the 2/3 other camera views the player has. That allows unit switching but means all the logic is stuck in parent classes.

Edit2: Would Blueprint_UpdateCamera be more to my needs? Set the default unitcamera positon and spring arm setup in there, and if activePawn == GetPlayerPawn and bUsingPlayercamera2 == true then do a branch for the players camera implementation on a seperate return node?

[StarfireDev]

@Nsomnia;537170

For my game each unit will have one camera a external ‘Unit cam’ to allow free view around the unit within a certain range. Simple. Spring arm and camera.

My players unit however will have multiple cameras, one unit camera like the rest but also cameras with clamped pitch and can move up and down vertically a certain distance as well as zoom in/out.

Originally I was creating a standard UnitCam in my base pawn class so that each one had it, and then my players unit class had the additional cameras; needly to say having to get all cameras and deactivate all of them then activate the one needed, especially when the number of units (and thus unit cameras) can be ever changing from 1(just the player) to dozens if in a heavy battle.

So I finally decided to play around with the PlayerCamagerManager class, as it seems to allow me to remove all the camera logic from the pawn classes or player controller and keep it nice and tidy in a seperate class.

What would be the best practices for a setup like this? I originally thought I would just add a spring arm and attached camera to the PlayerCameraManager but now I realize it spawns a camera in by default on the currently possesed pawn with no way to enable/disable it, or even translate it through the blueprint.

I will delve into the C++ as I’m watching the twich stream “flexible camera control through C++” and maybe get rid of the defalt camera spawning logic so I can blueprint my own setup.

Am I going in the right direction?

TLDR: How best to use the camera controller class Blueprints & C++ for a non-first person shooter game (vehicle combat simuator) where the player has multiple cameras and each unit has a camera, but only one can be active at a time, to keep things clean and future proof.

Edit: I should add that I noticed even trying to add an offset or rotation to the default TransformComponent scene component inherited from c++ in the PCM bp, does nothing since the PCM seems to stay the player spawn point. Maybe I’m stuck with having to do camera control through the player controller and indivudally activate one camera and deactivate the rest through many careful loops?

Whats most confusing is even ticking SetActorLocation(0,0,0) keeps the actor set to where the currently active pawn is, how is this behavior defined?

What makes sense to me, but seems less future proof and harder to modify is to have each pawn create a camera/spring arm setup on Possess and destroy them on UnPossess and the player would then destroy all camera and spring arm components and create the camera/springarm setup needed through a custom event when switching to one of the 2/3 other camera views the player has. That allows unit switching but means all the logic is stuck in parent classes.

Edit2: Would Blueprint_UpdateCamera be more to my needs? Set the default unitcamera positon and spring arm setup in there, and if activePawn == GetPlayerPawn and bUsingPlayercamera2 == true then do a branch for the players camera implementation on a seperate return node?

I would suggest what you said in Edit2. PlayerCameraManager still a little bit confusing to me since it has not much examples or best uses for it, like one question I was having these days was how could I add PostProcess to camera manager?

You would create your logic inside the Blueprint_UpdateCamera and change its transform when you swap the camera. The benefits you could get by using the player camera manager for this is to have only one camera instead of multiples, could be interesting for performance.

You should think of giving an int index number for every player unit and, inside your player controller, you create the CurrentPlayerViewIndex (or something like this…), so every BlueprintUpdateCamera call gets the Player Location at the CurrentePlayerViewIndex index from your units array. Thus, you wouldn’t need to go through an entire array everytime you call BlueprintUpdateCamera.

[Nsomnia]

@Gbr;537204

I would suggest what you said in Edit2. PlayerCameraManager still a little bit confusing to me since it has not much examples or best uses for it, like one question I was having these days was how could I add PostProcess to camera manager?

You would create your logic inside the Blueprint_UpdateCamera and change its transform when you swap the camera. The benefits you could get by using the player camera manager for this is to have only one camera instead of multiples, could be interesting for performance.

You should think of giving an int index number for every player unit and, inside your player controller, you create the CurrentPlayerViewIndex (or something like this…), so every BlueprintUpdateCamera call gets the Player Location at the CurrentePlayerViewIndex index from your units array. Thus, you wouldn’t need to go through an entire array everytime you call BlueprintUpdateCamera.

The problem is units can come and go out of the level as they travel/react etc. so its very dynamic.

I’ll be playing with the Blueprint_UpdateCamera override and see what I can get.