Conditional input handling by 'mode?'

Development Programming & Scripting Blueprint
, ,
1

My current project has grown to consume more resources than I like, so I’ve been looking for ways to optimize.

One thing that keeps bringing me back is the input handling.

The game uses a single “Mode” BP but plays in several play modes, primarily third person, first person for range device, another third person for the use of the various vehicles in the world and after some creative input, I have added a sustained drivable ‘tumble’ state.

I’m taking each input in the Character BP and running it through a Switch On Int to handle it based on the mode.
A very simplified example (to fit it onto a single screen) is this.

84919-mode_options.jpg
84919-mode_options.jpg686×708 142 KB

(Just imagine there is a Play_Mode Get attached to the “Selection” pin on the Switch.)

And I know that if I were doing this in C++ directly this would be the optimal method, or far superior to polling for the game state and then testing for inputs.

But for some reason I cannot shake the notion that this, too, is not the most efficient method.

Any advice on this? Is this as good as it gets or am I overlooking something?

2

That’s how I would do it too, with that integer being in the local blueprint.

Keen to see if there is a way to map input axis at runtime somehow and swap between them by state change(?)

3

I thought it might be the best-case but it still looks bulky to me.

The inputs are the same, W, Up, GPad Left thumbstick Up/Y-axis, etc for Forward Motion across each play mode, so the player doesn’t have to get the feel for multiple different control setups.

  • If you were asking if we ‘can’ change the input criteria for input-axis bindings at runtime, not from inside, no.
    Setting up for customizable inputs is simple, but would be something done alternatively to using the bindings in project settings (which exist mostly to ensure uniform play across multiple platforms, and cleaner workflow to support them)
4

Maybe using the Gate node could be another option… Either way your option should be fine.