I’m beginning to build a video game (new to UE) and I’m trying to figure out a good way to handle complex player controls prior to getting bogged down in the implementation. I’m asking for experienced advice on how to accomplish this in Unreal Engine (5).
The feature that I’m struggling to find a good design for is a theoretically unlimited set of objects which each have their own set of interactions and associated controls for interacting. A tangible example of this would be a single level with multiple objects that the player can walk around and interact with. They walk up to an object, press a button, and begin interacting with the object. While interacting, they have a different set of controls specific to that object until they press a button to stop interacting with it, at which point they return to walk-around control mode.
The solution I would imagine for this is a primary player controller (for moving around) and then a set of player controllers, one for each object. Thus, when beginning interaction with an object, the primary player controller would be swapped out for the one specific to the current object being interacted with. This would allow for modular and well-organized structuring of input routing, and would avoid cluttering a single player controller with a potentially disastrous amount of case-specific routing of input logic per object. However, I haven’t been able to get a simple example of this to work & any online material I’ve been able to find seems to indicate that it’s not possible.
If someone who has expertise in this area of the engine could explain how player input is routed to a player controller and how/if I would be able to swap player controllers out for a single player’s input - and if not, what is recommended - I’d really appreciate it.
I will note that I’ve seen the Enhanced Input plugin (which appears to be officially supported for UE5?), and it seems like this might fit my design criteria (swapping out modular Mapping Contexts within a single player controller). But I want to make sure that I’m not misunderstanding or overcomplicating things. If there is a way to swap out player controllers depending on the game state, then I’d like to compare the effectiveness of that vs. having to learn and use the Enhanced Input plugin.
dont swap player controller, swap pawns/characters.
player controller sends raw input events to the controlled pawn. Pawn interprets input however it wants.
Using an interface makes it pretty flexible - don’t need to care about what pawn is being interacted with, just send interface calls to it and if it reads them cool, if not it can silently ignore.
Don’t need any special plugins for this. Test a simple setup like this:
assign all possible input actions/axis events to player controller. Make an interface with all those events too called “interactable interface” or something like that.
Implement the interface on a couple different actors. Make them report some text or whatever you want them to do for whatever input events you want them to make use of.
Whether you are actually possessing these actors or just interacting with them doesnt really matter I dont think. You just reference them and then send the interface event to them. That’s all.
If just basic interaction, you can get reference to “other actor” from overlap event. If you possess them, its just “Get player pawn/character”.
How to route where input gets sent to? That’s specific to your game. IF you possess pawns to control them, you only send input to possessed pawn so that is easy. If you are normally controlling a character but sometimes interact with something, you probably can put a switch on the player character and then it can route its input events to the interacted object.
you can think of whole system like routing electricity from power station. Player controller is the power station. Interactable objects and pawns/characters in the level are where you route power to. So it’s a one to many relationship - doesn’t make sense to swap power stations to match the variable number of actors in the field.
If my PlayerController listens for all possible input and then just forwards that to the possessed pawn, what value does the PlayerController provide? I suppose if I do this and then implement the interface, I could potentially route input traffic to multiple actors at once, but that’s not so much the design problem I’m running into.
I suppose a simple option that I hadn’t really considered is having the PlayerController only manage directing of inputs to the currently possessed Pawn, and letting the pawn decide what to do with this. One issue with this is that if I want to implement any generic controls at the PlayerController level, these inputs are now consumed and won’t be registered on the possessed Pawn components (as I understand it). This essentially means that I can’t handle input at the PlayerController level if I wish to.
The idea of having the PlayerController listen for all possible input and then forward it to a Pawn that implements an interface could solve this, by setting the PlayerController to act on an input before forwarding it - but then I’m still open to having my PlayerController get fairly complex if any input that I want the PlayerController to handle is dependent on that game or character state.
I feel like the analogy of the power station doesn’t really hold up when thinking of the “power” or input events coming from higher up (PlayerInput Mapping). The PlayerController is one of a few objects that sits on the stack for handling InputComponent checks, so it seems somewhat arbitrary if we limit PlayerController to having to be a monolithic single class per Level. I’m not trying to disagree that this is how the engine is designed (because it seems to be that way) - just that it doesn’t make inherent sense to me.
My understanding is that the reason for separating player controller from controlled pawns is sort of a legacy from multiplayer shooters where you might have the player controller possess various different pawns throughout the life cycle of a game, so you want a central, persistent input handler. Perhaps there is deeper multiplayer technicalities but that’s beyond my knowledge.
In a single player game I think that you could avoid using the player controller, as characters in the level can read input directly, as can widgets. I still find it useful to use a central input-switchboard so to speak.
About consumption - you can toggle if input is consumed on the input events (details panel with event selected).
You can enable input directly on the actors themselves, no need to forward from player controller or use different pawn classes.
To start with something simple, add a sphere trigger component around your interactable actors, and when player character overlaps it, enable input for that object.
