88 lines
3.8 KiB
Markdown
88 lines
3.8 KiB
Markdown
---
|
||
uid: input-system-workflow-embedded
|
||
---
|
||
# Workflow Overview - Using Embedded Actions
|
||
|
||
|
||
|
||
You can use the **InputAction class** in your script to define actions in your script. This adds a layer of abstraction between your actual action code or methods, and the [bindings](ActionBindings.html) to specific device controls.
|
||
|
||
This means that instead of directly reading device states, you do not specify explicitly which controls (such as a gamepad trigger or stick) should do what in your code. Instead you create [Actions](Actions.html), [bind](ActionBindings.html) them to [controls](Controls.html), and respond to the states or values from your Actions in your code.
|
||
|
||
When you make a public [InputAction](../api/UnityEngine.InputSystem.InputAction.html) field in a MonoBehaviour script, it displays in the inspector as a configurable field. The configurable field UI allows you to create a binding for the action. For example, here are two Actions defined using the InputAction class in a script:
|
||
|
||
```
|
||
using UnityEngine;
|
||
using UnityEngine.InputSystem;
|
||
|
||
public class ExampleScript : MonoBehaviour
|
||
{
|
||
public InputAction move;
|
||
public InputAction jump;
|
||
}
|
||
```
|
||
|
||
In the image below, you can see the actions displayed in the inspector. In this example they have been configured so they are bound to Gamepad controls.
|
||
|
||
|
||
|
||
The InputAction class provides a way to bind interactions from a device’s controls to named actions in the inspector. When you bind actions to controls from a device in the inspector, you can then design your script to respond when the actions are performed without hard-coding references to specific devices in your script. This layer of abstraction provides you with the flexibility to modify or add multiple bindings without needing to change your code.
|
||
|
||
To read values from your Actions, you must first **enable** the action, and then either repeatedly poll the action in your game loop, or add event handlers to the action. You must also **disable** the action when you no longer want the input to trigger event handlers.
|
||
|
||
So, use actions such as those shown above in the small code sample, you would use a script like this:
|
||
|
||
```
|
||
using UnityEngine;
|
||
using UnityEngine.InputSystem;
|
||
|
||
// Using embedded actions with callbacks or reading values each frame.
|
||
|
||
public class ExampleScript : MonoBehaviour
|
||
{
|
||
// these embedded actions are configurable in the inspector:
|
||
public InputAction moveAction;
|
||
public InputAction jumpAction;
|
||
|
||
public void Awake()
|
||
{
|
||
// assign a callback for the "jump" action.
|
||
jumpAction.performed += ctx => { OnJump(ctx); };
|
||
}
|
||
|
||
public void Update()
|
||
{
|
||
// read the value for the "move" action each frame.
|
||
Vector2 moveAmount = moveAction.ReadValue<Vector2>();
|
||
}
|
||
|
||
public void OnJump(InputAction.CallbackContext context)
|
||
{
|
||
// jump code goes here.
|
||
}
|
||
|
||
// the actions must be enabled and disabled
|
||
// when the GameObject is enabled or disabled
|
||
|
||
public void OnEnable()
|
||
{
|
||
moveAction.Enable();
|
||
jumpAction.Enable();
|
||
}
|
||
|
||
public void OnDisable()
|
||
{
|
||
moveAction.Disable();
|
||
jumpAction.Disable();
|
||
}
|
||
}
|
||
```
|
||
|
||
See [Actions](Actions.html) for more information about both these techniques.
|
||
|
||
You can find an example of this workflow in the sample projects included with the input system package. To find it, in the Project window, look in **Assets > Samples > SimpleDemo** and open the scene: **SimpleDemo_UsingActions**.
|
||
|
||
Using InputActions also makes it easier to implement a system to allow the user to remap their own controls at run time.
|
||
|
||
Using embedded actions like this is more flexible than [directly reading device states](Workflow-Direct.html), but less flexible than using an [actions asset](Workflow-ActionsAsset.html).
|