InputMaster Primer

= InputMaster Primer = Relevant for version v7.1.1b

Initial Notes

 * This tutorial is NOT a Unity tutorial nor a primer to C# or programming in general. This tutorial assumes that you already have a good grasp of how Unity works and that you have intimate knowledge of programming concepts and the C# language.
 * BSGTools is C# ONLY. Unityscript and Boo are NOT supported.
 * InputMaster was designed for programmers, by a programmer. It has no configurable options in the Inspector, and should not be manually added to a GameObject for any reason. All configuration is done in code. However, if you'd like to make some variables editable in the Inspector, you can expose them through your InputManager.
 * It is worth mentioning that this tutorial uses a Singleton pattern to provide access to the InputManager script we will be creating. This pattern is easy and fast to implement, which is why I'm using it here. Some people argue that the Singleton pattern is bad design. Regardless, this is a beginner's tutorial, and I'll be treating it as such.

Setting Up The Scene
Our basic scene will be comprised of a few very basic objects:


 * 1) An orthographic camera
 * 2) A quad primitive (our basic "player")
 * 3) A directional light (to make things actually visible)

Creating The InputManager
Once the basic scene is set up, create a new C# script, name it InputManager. This InputManager script should inherit from the Singleton class provided with InputMaster. Your script should look like this:

The initial goal is to create a single control and an InputMaster object. Creating the Master object sets several things in motion:


 * It tells the system to create a new instance of InputMaster
 * To call DontDestroyOnLoad on InputMaster.
 * To provide the new master instance with the default controls for the game.

Note that you will never actually see your instance of InputMaster. It will be attached to a hidden GameObject.

First things first, creating a Master object. Creating a new master is as easy as calling CreateMaster:

We pass in this as a parameter to CreateMaster(object) so that it can use some awesome reflection magic to get all of the Controls automatically from your InputManager instance. Note that this will cause a spike in performance if you have a lot of controls in your InputManager class and InputMaster gets created during gameplay. If this is the case, I recommend either explicitly adding an instance of your InputManager to a GameObject in a bootloader scene or to use this alternative method:

Using this will require editing if you add additional controls later.

We want to make sure that this object is also not destroyed on a new scene load, so add DontDestroyOnLoad(this) to your Start method.

All in all, your starting point should look like this:

Creating The Controls
InputMaster has been tirelessly reworked to be as simple yet as powerful as possible. One major step of this change was to reduce the 3 original control types (DigitalControl, AxisControl, OneWayControl) to a single type, KeyControl. Controls for Xbox 360 controllers have their own types. This monolith control type:


 * Has two bindings.
 * Positive - REQUIRED
 * Negative - Optional
 * Maintains three states:
 * Down - Was the control pressed this frame?
 * Up - Was the control released this frame?
 * Held - True as long as the control is pressed.
 * Tracks two values:
 * Value - The smoothed value between -1...0...1
 * Will only ever be negative if you have a Negative binding for the control.
 * FixedValue - An integer value (actually a sbyte) version of Value. Will only ever be -1, 0 or 1

We're going to have our player (read: quad) change color every time its pressed. There is only one required parameter, the KeyCode binding. However, if you'd like to give it a friendly name you can as well. This is a good idea, as doing a ToString on a Control object returns this name. If the name is not defined, a name of this pattern is created for you: UNNAMED_[Random 12 Char String]. Defining this name now and not later makes debugging MUCH easier, as this name is used in exceptions and stack traces.

Your InputManager should look something like this at this point:

This doesn't add functionality to the control yet, but when the game is run the system will be updating the control's state.

Control Functionality, or, The PlayerController
The InputManager is configured with a instance of InputMaster and the initial control is configured.

The last major step is to set up the PlayerController to turn the control's state into actual functionality.

Create a new C# script, name it PlayerController, and add it to the Quad primitive.

We need to check if the KeyControl's Down property has a specific flag. In previous versions of InputMaster, the Down/Up/Held properties were bools.

These states are no longer of type bool. They are now of type ControlState, which is an enumeration with the following flags:
 * ControlState.Positive - Does the positive binding have this state?
 * ControlState.Negative - Does the negative binding have this state?
 * ControlState.Neither - Do neither the positive or the negative binding have this state?
 * ControlState.Either - Do either of the positive or negative bindings have this state?
 * ControlState.Both - Do both of the positive and negative bindings have this state?

For example, to check if a control's positive binding is in the Down state, you can check by comparing the Down property of the control to ControlState.Positive. The trade off from previous versions of InputMaster is verbosity. However, you gain intimate knowledge of exactly what state your controls are in.

This script is really simple (for now). In our Update method we're going to get an instance of the InputManager via the Singleton's Instance property and poll the state of the changeColor KeyControl. If the Down state has the Positive flag, we assign a random color to the renderer's material.

Go to the editor, press play, and test the control:



Using Values
Go back to the InputManager script and add a new KeyControl:

Returning to the PlayerController, we need to add several items:
 * 1) A Vector3 that will define the addition we will make to the original scale of the transform.
 * 2) A Vector3 that will store the original scale.
 * 3) The functionality that will take the Value of the scaleUp Control and apply it so that it scales up the quad.

Go to the editor, press play, and test the control:



Moving The Player
Add two new KeyControls to InputManager.

You can configure the Sensitivity, Gravity, Dead and Snap parameters. These have the same effect here as they do in Unity's Input system.

Finally, configure the PlayerController to use the values of these new inputs to adjust the transform position:

Go to the editor, press play, and test the controls: