Player Events

Description

The Player Events script is a component attached to the player’s controller in FP Motion’s demo scene, it checks for the player’s input, and sends out events to all other components in the asset, making it easy to know what the player is doing from any component.

How does it work?

To give components easy access to what the player is doing, the Player Events component compiles all the actions that the player might do into one script, and activates them based on the input received.

The component itself has a property dedicated to each event that the player can trigger with input, or value that can change and applies to other parts of the game.

Whenever it receives some input, the script checks whether there is some event that fulfills all of its conditions to change, and matches the input; if so, it updates accordingly.

How does the Player Events component know when to call a certain event?

How the component behaves is totally up to the programmer, what that means is that the associations between the actual events, and the conditions allowing them to change are in-code.

This makes the component hard-coded, but there is really no good way to expose these parameters to the inspector as far as we can tell.

When writing the function to trigger an event based on input and some conditions, the usual format is:

//Conditions. Here, the player being grounded)
var canChange = GroundState.Get();

//Go back if the state can’t change because of conditions.
if (canChange == false)
    return;

//If the player has pressed the button, toggle.
if (Input.GetKeyDown(crouchKey))
    Crouch.ForceToggle();

In the example above, the crouch event is being toggled whenever the player presses the crouchKey; The toggling only happens when the player is touching the ground, which is the condition in this case.

The above method is called every frame.

Why not just check for input in every script?

FP Motion uses events in this manner because doing it the more traditional way is not efficient, or clean enough.

Checking input in every script is messy and slow, the main reason being that some actions need certain conditions to happen, and thus the script checking for input has to know of those conditions, and check for them.

If multiple scripts need to check for the same conditions, and trigger the same action, it all becomes a giant mess!

Code being ‘clean’ is also a very important thing for us, so we don’t want to do the same checks in multiple scripts, especially with there being no good reason to do so.

That said, the most important reason for using event-based input is that it allows the developer to have a method get invoked whenever an event’s value changes; For example, when the player shoots, you might want another script to play a sound.

Usage

Using the Player Events component can be easy, but changing it may be a little trickier, especially without intermediate-level programming knowledge at the very least.

Getting information about events

To receive information on any of the player’s current actions trough the Player Events there is a need to access it from the component that needs that information.

As the events component is a singleton, you can access it this way:

PlayerEvents.Instance.EVENT_NAME

Where you replace EVENT_NAME for one of the event variables that are defined inside the script.

Once you save the event, you have access to all the properties of that event, and depending on the event it is, its state or value is one of those.

For example, in order to check if the player is aiming or not, you can use the following code:

bool  aimState = PlayerEvents.Instance.Aim.State;

With the reason behind the aim event having a ‘state’ variable being that it is of type Action.

You can read more about events, and the types that there are here.

Invoking a function when an event changes

As mentioned before, an important reason we opted to use event-based inputs instead of the more traditional unity version is the ability to have a function invoked when an event changes.

For example, when the state of the player’s aiming changes, we might want to play a sound; you can do that with the following code:

//Subscribe two functions to the aim start, and stop.
PlayerEvents.Instance.Aim.SubscribeToStart(OnStart_Aim);
PlayerEvents.Instance.Aim.SubscribeToStop(OnStop_Aim);

private void OnStart_Aim() { //Aim starts }
private void OnStop_Aim() { //Aim stops }

API