0
\$\begingroup\$

I have a player with many individual components that each handle a behavior such as jump, block, attack, duck, etc.. None of the scripts know about one another. Each listens for a specific input to fire. Some behaviors share the same input depending on the characters state such as ok the ground, in the air.

I'm running into issue where the wrong behavior will fire that has shared input (down+attack instead of down+attack being held down for x seconds).

I'm looking for advice on how to manage these behaviors and have more control over what can happen when.

I've tried resolving this issue by creating a method that will disable other behaviors temporarily while completing the action and I've changed the script execution order.

I thought about adding a discrete player state and restricting what behaviors are able to be performed at any given time but this increases the complexity quiet a bit.

\$\endgroup\$
  • \$\begingroup\$ Wouldn't docs.unity3d.com/Packages/com.unity.inputsystem@0.2/manual/… help you achieve this ? \$\endgroup\$ – Aybe Feb 26 '19 at 22:29
  • \$\begingroup\$ I have an input system that checks for the conditions. I've looked over the new unity input, is there something specific that it does that you think might help? \$\endgroup\$ – Pyreal Feb 26 '19 at 22:34
  • \$\begingroup\$ If I'm not mistaken you can map a particular combination of input i.e. hold or tap to a particular action, wouldn't that solve your problem ? docs.unity3d.com/Packages/com.unity.inputsystem@0.2/manual/… \$\endgroup\$ – Aybe Feb 26 '19 at 22:37
  • \$\begingroup\$ It's something ive wanted to dive into, so maybe it's worth a shot. It's going into full release soon. \$\endgroup\$ – Pyreal Feb 26 '19 at 22:43
1
\$\begingroup\$

As Aybe suggests in the comments above, I'd recommend separating the concept of Input from the concept of Actions. You can do this in your own scripts, even if you're not ready to jump into the new input system.

To do this, you'd have one script that manages reading the player's input devices and determining what actions have been performed. This has several benefits:

  • If one action should affect whether another can be performed (eg. taps & holds coexisting on the same button), you can coordinate the two in one place and ensure the correct one fires.

  • Your input logic is centralized. If you add control mapping, or need to swap out a whole new input handler (eg. for a new platform with completely different input hardware), you have one well-defined place to make these changes, rather than sprinkling them through every script that uses input.

Then your individual behaviour scripts can subscribe to this input controller for the actions they care about. A side benefit you get with this is that your in-game effects are now decoupled from their triggers: you can re-use those same behaviour scripts for non-player initiated actions, like NPC abilities, or events in cutscenes - substituting an AI controller or cutscene script as the action provider.

It's up to you how much knowledge your input controller script has about the player's various abilities. It could explicitly know all the action types it needs to support and their relationships, and expose getters / events / handler slots to fire off the corresponding behaviours. Then you control which action blocks which with explicit logic inside this script. Or it could be a completely generic input-checker that accepts subscription requests asking it to watch a particular input, and maybe a priority level or spillover setting to control which subscriptions should fire first / block other subscribers. Then it's delegated to the subscribers to describe the input they want and its conditions.

|improve this answer|||||
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.