Input

To optimize bandwith usage in turn base games, it is recommended to use Commands. A Command is only sent on request, whereas regular inputs at sent every tick; the former is thus using less bandwidth than the latter.

The Quantum Golf Sample implements two types of Command inputs, the PlayCommand and the SkipCommand. Each uses generic structs to carry game-specific command data and serializes it. N.B.: When creating a new Command, the serialization of the data it contains needs to be implemented manually.

The CommandSystem receives and validates the commands sent by players.

Commands

PlayCommand

Player can send a PlayCommand on their turn to send information about the decisions/moves taken during that turn.

The PlayCommandData wraps an FPVector3 and an FP used to hold the ball striking direction and force respectively.

C#

[Serializable]
public struct PlayCommandData
{
  // game-specific command data here
  public FP Force;
  public FPVector3 Direction;
}

public class PlayCommand : DeterministicCommand
{
  public PlayCommandData Data;

  public override void Serialize(BitStream stream)
  {
  // serialize command data here
  stream.Serialize(ref Data.Force);
  stream.Serialize(ref Data.Direction);
  }
}

SkipCommand

Players can skip their current turn by sending the SkipCommand.

C#

[Serializable]
public struct SkipCommandData
{
  // game-specific command data here
}

public class SkipCommand : DeterministicCommand
{
  public SkipCommandData Data;

  public override void Serialize(BitStream stream)
  {
    // serialize command data here
  }
}    

Unity Side Helpers

There are a few scripts on the Unity side helping the caching and sending of input.

CommandDispatcher

The CommandDispatcher is used for sending all of the local player/s'PlayCommand and SkipCommand the local player.

StrikeInput

StrikeInput forwards the active player’s aiming input to be registered and polled by the InputPoller.

The StrikeInput script listens to input events of the active local player sent by the InputManager. Uses mouse dragging to update the aiming direction. Another one of its responsabilities is to constantly update the force bar marking position.

When a player is aiming and the mouse button is released, a PlayCommand is sent with current aim direction and force bar marking position.

• AimSensitivity: scale factor used when dragging the mouse and changing the shooting direction.
• ReverseControls: input drag values are inverted before being applied to the shooting direction.
• ClampDirection: aiming direction angles are clamped according to the min-max striking angle values defined in the GameConfig asset. These values are double-checked by the simulation. It also clamps the maximum strike opening values, though this is purely for visualization / UI purposes.
• MaxStrikeOpeningAngle: maximum opening angle relative to the camera's facing direction when the player started aiming.

InputManager

It implements various static static events to handled input events such as mouse button events. Other scripts register to with the InputManager if they are interested in receive this sort of input / event.

InputPoller

The Quantum simulation polls input from Unity at a given rate - this is defined in the Deterministic Config. The InputPoller is responsible for reading the most recently registered input for the local players so the simulation can poll it.

The input data is stored from the moment it is registered until it is overwritten by another input from the same player, or when the player's turn ends. In the latter case the registered input is reset to its default value. This setup allows for the aiming data to be polled from the simulation when a remote player is aiming and from the registered inputs in the InputPoller when a local player is aiming; this results in a sharper visual responsiveness.

Aiming UI Display

The AimingDisplay is responsible for updating visual features such as the directional arrow and force bar when a player is aiming.

When the aiming player is local, AimingDisplay polls the registered input for that specific player from the InputPoller; alternatively, if the player is remote, the script polls the most recent corresponding input from the simulation.