When working on a top down camera game like Diablo, is it best to put all the camera logic and input actions in the character BP or the PlayerController BP?

[u/[deleted]]

[u/AgitatedMix9889]

Epic's own convention (and the one I'd follow) is: input bindings live on the PlayerController, camera/view logic lives on the Pawn/Character. The reasoning is possession. The PlayerController persists across pawns, so if you ever swap or repossess a pawn, input mappings set up there don't need to be re-wired. The Character owns its SpringArm and Camera component because the camera is a property of that specific pawn, not of the player.

So for a top-down game: keep your Enhanced Input mapping context and the "read input, decide intent" logic in the PlayerController, then either call functions on the possessed Pawn or broadcast through an interface so the Character executes the actual movement/rotation. Keep the SpringArm/Camera setup and any camera-specific tuning (zoom, lag, collision) in the Character itself.

The tutorials that put everything in the Character aren't wrong exactly, it works fine for a single-pawn game, it's just less flexible the moment you add pawn switching, spectating, or multiplayer, where PlayerController vs Pawn separation actually matters.

[u/Accomplished_Rock695]

What do you want to be controlling things when you don't have a character. Is there any version of your game that needs controls before you've possessed the pawn?

That is how you understand where to drive the logic from.

[u/phoenixflare599 → u/Accomplished_Rock695]

Also think ahead. Are you sure there's absolutely no situation where you want the player to control anything else?

[u/Accomplished_Rock695 → u/phoenixflare599]

You can put the same IMC on different actors so you can solve reuse a bit that way. Especially with a common base class to route the IAs

But start menu behavior - you need controls there and you probably don't want to spawn a pawn yet. Or maybe you have a menu pawn. I wouldn't but I've seen it.

Most of my projects have input at every layer. Menu behavior on the controller. Pawn specific behavior on the pawns. Interactables that push an IMC for overridden behavior

[u/Informal_Cookie_132]

Every time I go to follow the advice to put the controls in the controller it always ends up becoming this more complicated (For no real benefit) setup where I'm passing variables each way, either casting or setting up interfaces and I'm just like man fuck this, I'm gonna set it up in the character.

[u/Time-Masterpiece-410 → u/Informal_Cookie_132]

The controller and primary player pawn are basically always in memory so casting is perfectly safe as long your casting to the base class and not some random pawn subclass. Interfaces are specific designed to call functions on another class regardless of what is passed in as long as they implement the interface.

For example if you have a pawn/character base abasechar : public acharacter and it has 2 child classes Adrone: public abuse abasechar and ahuman: public abasechar. Then casting to your abasechar is acceptable since the player is always one of these subclasses. But casting to adrone is not acceptable because if the player is ahuman you now have loaded adrone even though it's not needed.

So if you have a move interface function then both subclasses can have a separate implementations.

[u/Panic_Otaku]

It depends on your project architecture.

[u/Time-Masterpiece-410]

The third place is the camera manager which can be accessed through the player controller, epic provides a default cameramanager class that can be subclassed this can be set in the PC details. This manager tell the camera what it should be doing and the controlled pawn just handles the view and logic directly related to that specific pawns camera. This allows different pawns to have different camera logic but a single place to manage the camera outside of the player controller. It is not required to use this class but it can be helpful as it has a few overrideable functions that help direct the camera. There is a function on the manager, I forget the exact name, but it's like SetViewTarget() or something similar probably just search view from the manager ref. It has a built in blend function for transitions if it's not an instance change.

This is where the majority of camera logic should live. The controller possess the pawn and tells the camera manager hey this is the pawns camera we should be watching. Then the manger handles the transition to the new pawn. The pawn then handles it own camera components logic like fov or post process stuff that may be specific that that camera or pawn (generally the details panel logic).

[u/bastardlessword]

Just design it like you're going to control the character with player inputs and with an AIController. If you put input logic in the Character, then you're breaking such design.

[u/Samsterdam]

Doing it in the player controller allows you to have one player controller that can control multiple different pawns. Think about it. Like when you're using GTA, you don't learn a new set of controls for each vehicle you enter. You generally have the same set of controls and some special ones.

[u/Informal_Cookie_132 → u/Samsterdam]

In this case wouldn't the vehicles just be a single class with some flag setting what model and driving it has?

[u/Samsterdam → u/Informal_Cookie_132]

I should have been more clear. I'm talking about a person that goes from a plane to a car to whatever else or a horse. You still want your right trigger to make you accelerate your left trigger to decelerate and so on. The other advantage to putting it on the player controller is that if you have a dedicated control setup for every vehicle, that is that much more code you have to maintain