Unity New Input System (part 1)

Challenge: Converting Old Input System to New Input System

In this challenge we will be applying our knowledge about the New Input System to an practical and real world situation. This Challenge will allow us to understand how the Input System works in a 3D game with multiple scenarios that shows off the power of the New Input System.

Understanding and Analyzing the Old Script:

One extremely underrated skill to have as an developer is to learn how to read and understand scripts that aren’t written by yourself. In this situation the client has provided the previous script for this tech demo prototype.

Upon close inspection we can see that the script is indeed using the Old Input System. An example below shows that the script has “Input Get Key Down” commands.

The script using old Input System which needs updating.

The next thing to analyze is how the script is structured and how the game works. If the game is playable then that makes the understanding part much more easier, but in most cases that isn’t always the situation. Therefore we will need to open up the major scripts and read through each one to get a better understanding on how each script interacts with each other. That way we will know how the initial game should have worked before the implementation of the new Input System.

The base game is still playable which makes understanding much quicker.

Since the game was semi playable, we can quickly see that the game is running on colliders or “Zones” which sets up certain conditions to trigger certain events. This means that each interactable object is a separate script and with their own separate conditions to function. This information would come in handy much later once we start implementing the New Input System.

Updating the Input System:

Now that we have a slightly better understanding on how all the scripts are interacting with each other, it is time to start laying the ground works for using the New Input System. First we need to install (if you haven’t so already) the New Input System Package Asset from the Package Manager.

Then we are going to need to activate the New Input System within the “Project Settings”. Within the Player Tab in the Other Settings section, we are going to scroll down near the bottom and search for “Configuration”.

Within the Configuration we should be able to select the Input System Package (New) if you have downloaded the proper package from the package manager. Don’t Select Both, since that will allow both old and new to function, we need to identify the old script and update it to new, which is only available within the New setting.

Once you change to the new Setting, Unity should ask you to restart the application so the New Input System will be working. You will also see that there will be several Error messages within the Console, and the game will be unplayable due to the depreciated scripts.

Next we are going to create our new Input Actions (Right Click > Create > Input Actions). Name the New Input Actions, then double click the object to open up the Control Schemes.

As you can see I have already started to make the Player Movement Input.

In this prototype there will be several Action Maps which we will need to create to fit all the controls this game has. But First we will start with the “Player”, and within this Player Action Map we will need to create controls for the bindings. Currently while skimming through the scripts we know that within the Player Script we will need Movement but in the “Interactive Script” which controls the Zoning and trigger events, we will need more Actions. Actions that occur within the Interactive Script include “Collect, Action, Hold.” An example of how we figured out these Actions is by analyzing the script like below.

In the Interactive Script that the Client provided, there is a Press function and Hold Key function.

After going through all of the functions within the two scripts, we can see that the final Actions required for the Player to be functional would be listed below.

For each Action, I make sure that I also have a dedicated binding attached. For example for the Movement, I have Keyboard settings that are controlled by the WASD keys.

There can also be the same binding for different Actions as long as the scripting scenario doesn’t overlap. For example I have both Action and Collect bind to the “E” key.

As long as the situation doesn’t overlap (aka. I am not doing and Action and Collecting something) these bindings won’t interfere with each other.

Finally it is time to save the Action Map Settings either through manual input or check the “Auto Save” box to have it automatically done for you.

Lastly, in order to get access to this Action Map via scripting, we will need to convert this Action Map into a C# scriptable object. We can do this by selecting the Input Action Map Object and looking at Inspector. Give the C# Class a name so you can identify the class later.

As of right now, we have download the New Input Asset from the package manager. Analyzed and understood the core function of game and how it works. Pinpoint which script does what. Created a New Input Action Map which has the Player Action and bindings.

Now that the ground work has been completed, within the next article we will start with creating an Input Manager and reworking the scripts to use the New Input System.