How to setup different control schemes for character based on situation

Hello everybody!

I am creating an RPG game to better study the engine, and came across the following situation:
The character will have 2 basic situations, the level exploring and the combats. However, the controller schemes (inputs and commands) will be different for each one. So, for example, the arrow keys (or gamepad thumbstick) would be used to move the character on the map, when exploring, and to select an action, when on combat. The A button would interact with the objects on exploration, but is used to confirm the action selected when on combat.

So far, I am thinking of creating the character inputs outside of the character Blueprint, into a PlayerController blueprint, having 2 PlayerControllers set up. Am I able to change the PlayerController at runtime?

Any new ideas or suggestions on how to achieve this without branching every input event to check if exploring or battling?

Hi mcaetano,

I don’t know to much about UE4 yet but I think you can use a branch option in the controller instead of creating multiple controllers. This video covers a very similar event but is focused on turning or not (~5 minutes in).

I think you can make a new variable (like CanTurn in the video) to handle if you are in combat or not. I’m going to call this variable InCombat. Then set up a branch after A is pressed and with the condition InCombat. When True, your character is in combat and A will select you action. When False, your character is exploring and A will interact. (Of course you’ll need to build those blueprint on both sides).

Hope this helps

Hello Feldemon,

I saw the video (also learned another very interesting thing that I was stuck with, thanks again!), and understood the point of branching the input press. I think that I’ll stick with this approach for now, to be able to further develop the prototype. If the situation goes south for performance, I might think on another idea.

Thank you very much for the help!

Just throwing this out there.

If you have a short transition sequence or can hide your character for a bit you can just handle inputs in your player controller and pass down events to your player character.

And during that transition you can just swap out the characters for one another and since the character itself decides what to do with the input you can set up two completely different input methods. Not as dynamic and if you have to do this during an animation of your character while it’s moving it’s gonna be quite hard. Possible but hard and probably not the ideal way to handle this.

Alternatively to make it look better you can hide the control schemes in “Collapse node” thingies. Still use a branch but it looks cleaner. Performance isn’t really an issue since you just load a minimal amount of additional code in ram. One bool operation isn’t at all taxing on CPU performance. You won’t even notice it.

Cheers

Nice suggestion there, but I was thinking on how hard this would be, by thinking of the following aspects:
I would have to either “clone” the whole character runtime attributes (health, energy, etc) to swap between the combat and non-combat instances, or set the attributes for both instances at the same time when needed (so the combat version is up to date with the exploration). I think this would be rather simple to figure out. But I would still have to create, probably, 2 AnimBPs, state machines, and all the logic separately for them.

Thinking about best practices for programming, would it look “cleaner” if I collapsed the branch logic or maybe setting a function or something like that to determine the input response?

Thanks again!

Awesome, glad I could help and let me know if there anything else.

Also, can you give an update on how it turns out? I’m curious to see how far it can go.

First of all… Hp and all that stuff would ideally be in your player state which is literally designed for this type of task. It will be taken from level to level and will stay consistent no matter which character you use, is easily accessible from everywhere and solves this problem as well.

To you question: I would leave the branch in the event graph itself and collapse the functionality itself. That way you have infinite space to do stuff without getting in your own way while also having everything sorted logically in the event graph itself.

Hello Feldemon! I managed to branch out the events for the MoveUp and MoveRight inputs, and created a InCombat boolean variable inside the character. So far, I haven’t created any combat logic, and am still figuring out how to do so. But the point is, the player moves perfectly, with no input lag whatsoever, and when I do have battle, will probably set the boolean to true, in order to “hot swap” the input response

By Player state, you mean that I should be implementing HP and etc on another Blueprint? Like a Game Mode for example? I think I haven’t used too deeply this kind of BP. The command branching worked perfectly, but now I am curious about your new suggestions

Well it depends a bit. Generally yea. You can totally use Player State for all of that. It is mentioned like this:

A PlayerState is created for every
player on a server (or in a standalone
game). PlayerStates are replicated to
all clients, and contain network game
relevant information about the player,
such as playername, score, etc.

In a single player game it does get a bit more tricky as I’ve figured out quite recently. Basically it mainly was a fix for multiplayer. An optimization. However it is awesome if you have data for one player but swap characters as well.

It doesn’t persist through hard level transitions as I’ve realized. This means “open level” kills the data. But if you stream levels or do a seamless travel
it will persist through any transition you might have.

Swapping out is most likely not the right call now that I’m thinking about it more. Unless you want to do some super fancy animation stuff and don’t want to have that many bones / etc in your skeleton. I still wanted to throw something else out there because you never know. The easiest solution might be the best but it ain’t bad knowing other ways on top of it.