ORK comes with multiple built-in player and camera controls, but you can also use any custom control you want.

Player Controls #

Player controls are used to move the player’s game object in the scene. They’re set up in Base/Control > Game Controls in the ORK Control Settings > Player Controls.

The following built-in player controls are available.

• None
  No control is added to the player.
  Use this when you want to use custom controls or Makinom machines.
• Button
  Keyboard/joystick controls are used to move the player.
  Uses a Character Controller component.
• Mouse
  Mouse/touch controls are used to move the player to a clicked/touched position (using raycasting to find the position).
  You have different options available on how the player will be moved (e.g. using a NavMesh Agent).
• Top Down 2D
  Simple top down controls for 2D, moving on X/Y axis.
  Uses a Rigidbody 2D component.

None #

The None player control is used to not add one of the built-in controls

Custom Components #

You need to register your custom components to be able to enable/disable them with blocked player controls.

Register your custom control components in Base/Control > Game Controls in the Player Settings > Control Behaviours. Use this setup for a control component added to your player:

The Control Behaviour settings can also change fields/properties on the component to define a default setup, as well as automatically add the component to the player.

If the component isn’t added by the Control Behaviour settings, you need to manually add the component to the player’s prefab.

Button #

The Button player control is a basic control using input keys (e.g. keyboard or joystick input) to move the player and is intended for 3D games.

Optionally use the control in First Person/Strafing mode, i.e. the horziontal input will move/strave left/right instead of rotate the player.

Movement can optionally use the Camera Direction, i.e. forward movement is based on the camera’s direction.

Move Type #

The player is moved based on the selected move type:

• Character Controller
  Moves using a CharacterController component.
  Make sure that you add a Character Controller component to the player combatant’s prefab and place it correctly – otherwise the control will automatically add one, probably not at the correct position.
• NavMesh Agent
  Moves using a NavMesh Agent component.
  Requires a NavMesh setup in your scenes.
• Combatant Movement Component
  Moves using the Movement Component setup of the controlled combatant.
• Animator Root Motion
  Sets parameters of an animator controller for root motion control.

Jump #

Optionally allow the player to jump via an input key.

Using an input key with Hold input handling allows jumping higher when holding down the jump input key.

Sprint #

Optionally allow the player to sprint while holding an input key (i.e. use Hold input handling).

Sprinting can optionally use energy (which can optionally use a Consumable type status value as energy).

Mouse #

The Mouse player control moves the player to a clicked/touched position in the scene.

The position is found by using a raycast on a defined layer mask – make sure your layer setup is correct, e.g. only using a layer with ground game objects to avoid interference from other things in the scene. The position can optionally be marked by a cursor prefab.

Move Type #

The player is moved based on the selected move type:

• Character Controller
  Moves using a Character Controller component.
• NavMesh Agent
  Moves using a NavMesh Agent component.
  Requires a NavMesh setup in your scenes.

Using a NavMesh Agent is usually the better choice.

You can use the No Click Move component to block defined areas from movement.

Top Down 2D #

The Top Down 2D player controls is a basic control using input keys (e.g. keyboard or joystick input) to move the player and is intended for top down 2D games.

The player is moved using a Rigidbody 2D component, i.e. this control is only used in 2D environments.

You can optionally flip the player on the vertical (Y-axis) or horizontal (X-axis) axis based on the movement by negating the scale on those axes. This is only useful when using sprites as your player, e.g. using 3D models for this wouldn’t do much.

Sprint #

Optionally allow the player to sprint while holding an input key (i.e. use Hold input handling).

Sprinting can optionally use energy.

Camera Controls #

Camera controls are used to move the camera in the scene. They’re set up in Base/Control > Game Controls in the ORK Control Settings > Camera Controls.

The following built-in camera controls are available.

• None
  No control is added to the camera.
  Use this when you want to use custom controls or Makinom machines.
• Follow
  The camera will follow behind the player.
• Look
  The camera will look at the player (but not move).
• Mouse
  The camera will follow the player.
  Height and rotation can be changed by mouse/touch control.
• First Person
  The camera is linked to the player (or a child object).
  It can be moved horizontally/vertically (e.g. by mouse).
• Top Down Border
  The camera follows the player until the he crosses a border.
  The border is defined using a Camera Border component with a Collider in the scene.

All of ORK’s built-in camera controls derive from the BaseCameraControl class, which optionally allow using a transition when changing the camera control target (e.g. in battles or schematics). Transitions interpolates the position and rotation change from the current to the next camera control target. Implementing custom controls, either directly or via a wrapper component (see below for examples), should also derive from the BaseCameraControl class to allow using camera control changes.

None #

The None camera control is used to not add one of the built-in controls

Custom Components #

You need to register your custom components to be able to enable/disable them with blocked camera controls.

Register your custom control components in Base/Control > Game Controls in the Player Settings > Control Behaviours. Use this setup for a control component added to your camera:

The Control Behaviour settings can also change fields/properties on the component to define a default setup, as well as automatically add the component to the camera.

If the component isn’t added by the Control Behaviour settings, you need to manually add the component to the camera.

The Placed On setting can also add/search the camera control on the player or on Makinom’s persistant game object.

Follow #

The Follow camera control is a very simple control that follows the player at a defined distance and height.

The control can either follow the player’s game object or a child object of it.

Look #

The Look camera control looks at the player’s game object or a child object of it.

Yeah … that’s it, it doesn’t move or does anything else.

Mouse #

The Mouse camera control follows the player at a defined distance and height.

The rotation and zoom of the camera can be changed using mouse/touch drag input, e.g. right-click dragging or 2-finger dragging.

The rotation can be changed with horizontal dragging.

The zoom can be changed by vertical dragging or by optional input keys, e.g. using a Mouse ScrollWheel input.

Click/touch input for rotation and zoom can optionally be omited, always moving the camera by mouse movement without click/touch input.

First Person #

The First Person camera control is linked to the player’s game object or a child object of it.

The camera isn’t parented to the player, but follows the targeted game object by updating the position each late update.

To vertical rotation of the camera can be changed using an input key (e.g. using vertical joystick input or mouse movement). The vertical input can also be inverted based on a bool value selection, e.g. allowing to use a bool variable to support custom options.

The horizontal rotation of the player’s game object (root, not a possibly targeted child object) can be changed using an input key (e.g. using horizontal joystick input or mouse movement). The horizontal input can also be inverted based on a bool value selection, e.g. allowing to use a bool variable to support custom options.

I.e. the First Person camera control will also rotate the player.

Top Down Border #

The Top Down Border camera control follows the player at a defind distance and height and can be used in 2D and 3D games. The camera following the player can optionally be limited by Camera Border components.

Rotation #

Optionally change the rotation of the camera using input keys or mouse/touch controls.

Allowing rotation can be limited to battles or the field, or used in both.

Panning #

Optionally change the panning of the camera using input keys or mouse/touch controls.

You can also use screen edge panning, i.e. pan the camera in a direction by moving the cursor close to the edge of the screen.

Allowing panning can be limited to battles or the field, or used in both. Battle and field can use separate panning distances.

Zoom #

Optionally change the zoom of the camera using input keys, e.g. using a Mouse ScrollWheel input.

Allowing zooming can be limited to battles or the field, or used in both. Battle and field can use separate height and distance limits.

Camera Borders #

The camera following the player can optionally be limited by Camera Border components. The area is limited by a Collider or Collider 2D component with Is Trigger enabled (to allow the player to move within it).

The camera follows the player while the player is within the bounds of the camera border. You can also use multiple camera borders in a scene.

The Camera Border component can optionally use it’s own height (upper bounds of the collider) to place the camera or set the camera’s rotation. Additionally, the Camera Border can block the rotation input, panning and zooming of the Top Down Border camera control.

Custom Controls #

You can use any control you like with ORK Framework – you just need to let ORK know about it.

ORK Framework’s built in controls are a good starting point to get you going, but most likely you’ll want to add your own control scripts or use 3rd party controls for your player or camera. Since ORK needs to enable/disable control at certain points in a game (e.g. during a cut-scene event or a battle without direct player control), you need to register your custom controls to allow ORK to access them.

When using a custom control, make sure to change the used player or camera control type to None.

To register a control component, click on Add Custom Control in the Player Settings > Control Behaviours.

Additionally, you can also change fields/properties on the component to define a default setup. For setup examples see the None control information for player and camera controls stated above.

Control Wrapper Components #

In case your control component needs some kind of special treatment or setup that doesn’t work well with ORK’s custom control setup, consider writing a wrapper component.

A wrapper component works as a bridge between ORK and your custom control. You define the wrapper component in ORK’s custom control and manage blocking and unblocking the custom control in your wrapper component.

When ORK blocks a control, the component will be disabled, so you’ll use the OnDisable function of the component:

void OnDisable()
{
	// called when the control is blocked
}

When ORK unblocks a control, the component will be enabled, so you’ll use the OnEnable function of the component:

void OnEnable()
{
	// called when the control is unblocked
}

You can also add these functions to your actual custom control component and skip using a wrapper component.

Example: OOTII Camera Controller #

Here’s an example wrapper component for OOTII Camera Controller. This wrapper will forward control blocks and supports Camera Control Target changes and transitions, you can download it here:

Download

In case transitions are not working, make sure the wrapper component is executed after the actual camera control component by adding it to the Script Execution Order. You can do this in Unity’s Project Settings, add the ORK_OOTII_CameraControlWrapper component with a time of 100 (or more).

The wrapper component has settings for resetting the camera’s position and rotation after restoring camera control (to the position/rotation it had when the camera control was blocked). This can be done using local or world space. For OOTII, the camera is usually a child object of the camera controller – the default setup is to restoring position/rotation in local space.

Setup #

To set it up, go to Base/Control > Game Controls.

ORK Control Settings > Camera Controls #

Disable built-in camera controls.

Player Settings > Control Behaviours #

Click on Add Custom Control and change the following settings.

And that’s it – don’t forget to save your changes. ORK will now add the control wrapper to the camera when loading the scene, which will handle blocking camera controls, camera target changes and target change transitions for you. No need to do any further setup.

Example: Cinemachine Camera Controller #

Here’s an example wrapper component for Cinemachine. This wrapper will forward control blocks and supports Camera Control Target changes and transitions, you can download it here:

Download

In case transitions are not working, make sure the wrapper component is executed after the actual camera control component by adding it to the Script Execution Order. You can do this in Unity’s Project Settings, add the ORK_Cinemachine_CameraControlWrapper component with a time of 100 (or more).

The wrapper component has settings for resetting the camera’s position and rotation after restoring camera control (to the position/rotation it had when the camera control was blocked). This can be done using local or world space.

Setup #

To set it up, go to Base/Control > Game Controls.

ORK Control Settings > Camera Controls #

Disable built-in camera controls.

Player Settings > Control Behaviours #

Click on Add Custom Control and change the following settings.

And that’s it – don’t forget to save your changes. ORK will now add the control wrapper to the camera when loading the scene, which will handle blocking camera controls, camera target changes and target change transitions for you. No need to do any further setup.

Please note that the wrapper has to be on the same game object as the CinemachineBrain component, which is usually the camera. By default, the wrapper will use the player as follow and look at target – if you want a different setup, you can add the component manually to your scene’s camera and adjust the settings there.