The new input system InputSystem is a new plug-in for Unity in 2019. Note that Unity uses the old Input Manager by default and the new Input System is disabled. When you install the Input System component, Unity will ask you to enable the new input system. If you select Yes, Unity will enable the new one and disable the old one, after which the editor will restart. The specific operation is to open the package manager (Windows -> Package Manager) and find the Input System plug-in in "Unity Registry", as shown below
We click "Install" in the lower right corner to install
Prompt that we will use the new input system and disable the old input system at the same time, we click "Yes" to confirm.
The new input system already exists in our current project. In order to be able to confirm the input system used in our project, we can further verify it in the Player option in the Edit -> Project Settings window.
We see that "Input System Package (New)" is displayed in the "Active Input Handing" item, indicating that the new Input System input system is used. We can also select "Input Manager (Old)" or "Both" by clicking the drop-down. Obviously, "Input Manager (Old)" is the old Input Manager input system, and "Both" means that the old and new input systems can be used at the same time.
There are two ways to use the new Input System. The first is to obtain input directly from the input device; the second is to obtain based on the InputAction input action. We focus on the second InputAction input action.
First, we need to understand the following concepts:
InputAction: Every input of the player can be understood as an InputAction (input action).
InputActionMap: It manages a collection of some InputActions (such as front, back, left, and right input actions).
InputController: It is to manage the input of specific hardware devices (keys of different devices can be set).
InputBinding: Used to bind InputAction and InputController (association between device keys and input actions).
Next, let's demonstrate how to use it.
First we create a cube Cube, and then add a PlayerInput component to it.
After adding the components, if we want to receive input, we need to create InputAction. We can click the Create Actions button on the component to create. After clicking, a dialog box will pop up to select the path to store the generated .inputactions file.
We can define the name of this .inputactions file, here we can use "NewInputProject" by default. The save path is under the Assets root directory. This file is actually a configuration file (stored in pure JSON format), which contains input actions and their associated binding and control schemes. Although it is a file, Unity provides a graphical editing interface for the file. As follows
On the far left are two Action Maps, which are Player and UI. They are Action Maps that Unity prefabricated for us. When we click "Player", the InputAction under the collection will be displayed in the "Actions" on the right. We see that there are three: Move, Look, Fire. Let's continue to click to view the specific InputAction of the lower level. For example, if we click on the InputAction of Move, there are multiple InputBindings below it. Note that if the type of InputBinding is different, its settings are also different.
We can click on one of the InputBindings, such as "WASD" in the picture above. According to the name, we roughly understand that this InputBinding is used to control the input in the four directions of up, down, left, and right. Therefore, its next level must set at least four directions (up, down, left, right) of the input configuration. For example, the first input setting in the figure above is "Up:W[Keyboard]", which should be the letter W key on the keyboard, corresponding to the input information of "Up". At the same time, we can see the detailed configuration in the "Binding Properties" on the right.
Path is our device key.
Composite Part should be an option for multiple input values.
Use in control scheme is the device type, and their values have the following meanings
Keyboard&Mouse: keyboard and mouse
Gamepad: Gamepad
Touch: touch screen
Joystick: Joystick
XR: VR/AR devices
Next, we manually add a custom "InputAction"
We click the plus sign to the right of "Actions" to add a new "InputAction" and name it "Test". Next, let's look at the "Action Properties" interface to the right of "Test". There are three configuration items in this interface: Action, Interactions and Processors. We focus on the contents of Action. Action Type to define the type of our "InputAction", which has three values to choose from: Value, Button and Pass-Through.
First, Value: It is mainly used for the input of continuous state change, such as the movement of the mouse, the joystick of the gamepad, and so on. If there are multiple devices bound to this Action, only the input of the currently used device will be sent.
Second, Button: The Action that is triggered every time it is pressed is just a normal button. Defaults.
Third, Pass-Through: Same as Value, the difference is that if there are multiple devices bound to this Action, the input of all devices will be sent.
Next, we can add "InputBinding" binding to our "Test". This "InputBinding" can add multiple, that is to say, one "InputAction" can add multiple "InputBinding". Here, we just add one. We click the plus sign to the right of "Test", we can add different types of InputBinding.
Let's explain a little bit what these four add options mean:
Add Binding Ordinary binding, you can bind a button, mouse, gamepad, etc.
Add Positive\NegativeBinding A combination of two buttons, one for positive numbers and one for negative numbers
Add Button With One Modifier needs to press the combination of two buttons at the same time, such as ctrl + j
Add Button With Two Modifiers needs to press the combination of three buttons at the same time, such as shift + ctrl + j
In fact, we found that there is already a <No Binding> under "Test" by default, which is an ordinary binding of Add Binding, so we can use it directly. Please note that this "Test" is not the same type setting as the "WASD" we introduced above. We click to select it, and then look at the "Binding Properties" interface on the right.
We choose the "Keyboard" keyboard
We choose "By Character Mapped to Key"
We randomly choose an "M" letter button
At this point, our "M" button will be displayed at Path, and we can complete the setting of "InputAction" by checking "Keyboard&Mouse". Next, let's go back to the "Player Input" component. We found the "Behavior" behavior item in this component, its default value is "Send Messages", we replaced it with "Invoke Unity Events".
After the selection is completed, the "Events" item will appear below, and there will be two sub-items "Player" and "UI" under the item. You should be able to guess that these two are the "Action Maps" we just displayed in the "NewInputProject.inputactions" configuration file. We can click on "Player" to view its sub-items
At the bottom, the InputAction item of "Test" we just added will appear. Next, we need to create a script "TestScript.cs" file and attach it to the Cube.
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class TestScript : MonoBehaviour
{
public void OnTest()
{
Debug.Log("Input M");
}
}
We can click the plus sign below to add the script above, and assign the OnTest method to the "InputAction" item of our "Test". As follows
After adding, we can run the whole project.
Then press the "M" key on the keyboard to test.
Summary: There is a big difference between the new Input System and the old Input Manager in use. Although the old Input Manager also sets a lot of "virtual axes" through configuration, and then gets the "virtual axes" in the code to get the user's input, and then do further processing. Moreover, these codes need to be placed in the Update method for execution. And the new Input System system also needs some configuration. Obviously, these configurations are more complicated than the old system. The new system configuration is mainly to add InputAction one by one, and each InputAction can be bound to the buttons on different input devices. This InputAction is very similar to the "virtual axis" in the old system. But the difference between the two is that the device input of the old system is judged in the code; while the new system is obtained through the "Player Input" component, and the script method is specified to execute. From a design point of view, the old system is only the encapsulation of the input device, while the new system is not only the encapsulation of the input device, but also the encapsulation of the input logic. Therefore, although the new system is a bit more complicated, except for the content of the configuration (that is, the inputactions file we added, we can configure all input situations in this file), the rest is to use the script method to process the game logic corresponding to different inputs . The new system makes our code writing structure clearer, and each input corresponds to a script method for processing. This design is still very good.
The content involved in this course has been shared to Baidu Netdisk: https://pan.baidu.com/s/1e1jClK3MnN66GlxBmqoJWA?pwd=b2id