Forum rules - please read before posting.

New Input System, AC, Best Practices

edited September 16 in Technical Q&A

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

  • Unity 6.1
  • AC: 1.83
  • New Unity Input System
  • My own code (based on some examples online) to switch control dynamically between Controller, Mouse and Keyboard etc. - which in turn enables or disabled Direct Navigate menus, UInity UI menus, etc.
  • This post focuses mostly on custom scripting

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.

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.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.