Hi
My RPG game has distinct gameplay/minigames that need different input maps - for example: During gameplay, InteractionA might examine/interact with a hotspot. During Combat it should Attack. However there is potential for overlap. During gameplay, clicking on portrait brings up that characters inventory. During combat, you click a portrait to select a spells target. Typically the game isnt paused during these different settings.
Settings
Disclaimer: I'm not overly familiar with the new Unity Input System.
(Example) What Im doing now:
1. Add a new "Attack" action to the player input action map
2. In the player controller component Update(), check KickStarter.playerInput.InputGetButton() etc (not at my home computer, might have variable names from) and act appropriately.
3. Add checks for "Is Combat Active" around appropriate button checks.
I dont like the polling or the constant checks if a system is active. Its going to get messy quickly.
What I would like
1. Callbacks/Event on input instead of polling.
2. Not have to litter code with if (CombatIsActive) DoThis(); else DoThat();
Ive done some research and heres how I was considering do this:
1. Make my own UnityInput action maps
2. Enable/Disable them as required (OnCombatStart enables the Combat action map and disabled the AC Player action map).
3. For example: The Combat -> A would call OnAttack(), but during gameplay it might do something else or nothing
This thread gives and example of that. The part I am unsure of is > "New ActionMap will not contain any AC inputs, it will run separately".
Id like to still fire UI events and have AC/Unity UI buttons respond.
Does this sound like the correct approach, or does AC implement a similar concept to input action maps and different callbacks for each action in the map that I somehow missed?
Thanks as always, your direction is always super help for this kind of thing.
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
AC itself relies on polling so that it both retains compatibility with Input Manager, as well as control over the priority of inputs.
That isn't necessary for custom inputs, however. You can bypass AC's input functions (e.g.
InputGetButton
) in favour of Unity's provided ones, e.g.myInputAction.WasPerformedThisFrame()
.Categorising input actions through maps is good practice, but not strictly necessary: actions themselves can also be enabled/disabled. However, keeping your UI-related actions in a separate "UI" map does mean that you can disable your "regular" map without affecting your ability to interact with the UI.
When using Unity UI-based Menus, AC will defer control to the Event System prefab.
Thanks this answers/confirms what I thought.
Using polling due to the need to control priority makes sense.