Here’s the scenario: I am planning out a game that has two main gameplay states: In combat and map exploration/interaction (like a turn based RPG with instanced combat).
In combat, you move on a top down grid and use some menuing to select actions to take.
Out of combat, you move freely on a top down map, with the ability to interact/inspect things ( again very much old school turn based RPG-esque)
In addition to these gameplay states, there is also pause menu, for settings / saving / quitting / etc. There might also end up being an inventory system which would be a matter of more menuing.
With these aforementioned states of the game, there are several different control schemes that need to be handled. In addition, I want the game to be playable with M/K and gamepad. How do I organize my input to make this as straight forward as possible?
Do I make a different action map for each game state (combat grid control, combat action/ability menuing, pause menu control, out-of-combat movement and interaction)? If I do that, do I stick the m/k and gamepad controls within a single scheme across these different action maps? What is the advantage of having separate control schemes that require gamepad vs M/K? Outside of the unity input manager, do i have separate classes to handle each action map? do I funnel them all through a single one? Separate classes to handle M/K and others for Gamepad?
Any guidance, best practices, etc, would be appreciated.
Hi @stevinatorx.
Action maps are used for input patterns, like you mentioned (player movement, combat, UI…).
You can dynamically enable/disable action maps during the gameplay depending on the state of the game. So it makes sense to have an action map for each state of your game where the input patterns change, like you mentioned. Control schemes are applied globally and are valid across different action maps.
Regarding the decision to separate m/k and gamepads into two control schemes or have a single control scheme: it depends on what you’re trying to achieve. In the case of having one single combined control scheme with gamebad and m/k, you’ll likely not need a control scheme at all.
The control schemes are only relevant if you want to separate multiple different means of controlling your game from each other. So that they are mutually exclusive and so that you can know which one is active at any time (eg. to display hints for input device usage).
I hope this helped a bit, please let me know if you have any further questions.
Thank you for your answer! I will tag as a solution. So one “simple” use case for control schemes is to have a way to switch tooltips between keys/mouse and gamepad? I presume by detecting what control scheme the latest input is a member of?
Yes, that’s one possible use case. With the PlayerInput component you can easily access the current active control scheme. See this documentation: Class PlayerInput | Input System | 1.11.2