🎮Control Schemes
How to change the controls your users have
Last updated
How to change the controls your users have
Last updated
Due for Simplification, please see Docs.
31/10/2024: MSquared will no longer ship multiple control schemes. The solution shipped will be far more aligned with the existing Game Ready control scheme and built with the Unreal Enhanced Interaction System.
The expectation is that we will ship with the basic controls for movement and camera control, with developers extending this to facilitate any further functionality they want in their project.
We plan to include example mobile UI for touch screen movement, camera and Text chat support, as well as gamepad joystick control for movement and camera.
MSquared will not be addressing non-critical issues relating to Approachable Controls going forwards.
Please speak to your Support Engineers for more info.
Origin controls are designed to be primarily accessible to a broad audience, but configurable enough to suit most experiences. This broad audience includes non-gamers and mobile devices, so the defaults are enabled to cater for those use cases. We also have pre-setup control schemes configured for more complex and game-like experiences.
Origin supports two main control schemes that are essentially a configuration of the options you can configure for your experience:
Approachable Control Scheme - this scheme is enabled by default and has features such as “click-to-move” which enables people with a mouse or touch screen to click on a place they want to go to, and their avatar will navigate automatically to this point.
Game Ready Control Scheme - this scheme is for more game-like experiences and allows movement with the WASD buttons on the keyboard.
A comparison of the two control schemes:
Approachability | Game Ready |
---|---|
Starts with UI mode on, cursor is visible and free to move | Starts with UI mode off, cursor is hidden and captured by the viewport |
UI mode toggle: UI Mode is locked and cannot be turned off, so there is no toggle | UI mode toggle: The UI is seen when users clicks the right mouse button (this keybind can be changed) |
Camera mouse control: Unavailable (UI Mode is locked) | Camera mouse control: Move the camera by toggling UI mode off |
Click to turn: Move the camera in UI mode by holding down RMB/LMB (can be disabled - see Modular control features) | Click to turn: Same as Approachability |
By default, if you extend the Origin controller and player character (BP_Origin_PlayerController
and BP_M2_OriginPlayerCharacter
), the "approachable control scheme" will used.
By default, the player will be in the approachable control scheme. Enabling Game Ready controls by default can be done on a per-role basis by adding the following capability to a role:
Capabilities.ControlSettings.GameReadyDefaultEnabled
It is possible to toggle between the two control schemes in the Control Settings menu. This is also done on a per-role basis. Add the following capability to show the toggle in the settings menu:
Capabilities.ControlSettings.GameReadyVisible
If visible, the setting will show up in the Pause/ESC menu.
If you want players to always have camera control anchored to the mouse movement (eg. when using specific devices), follow Forcing UI Mode off.
If players also have the Capabilities.ControlSettings.ClickMoveVisible
capability, the setting will toggle Click To Move off when Game Ready Controls are enabled, and vice-versa for convenience. This can be manually re-enabled if the player wants to keep using Click to Move together with Game Ready.
The following are a number of movement features, and how to use them. Many of these features are configurable to be enabled or disabled by default and visible or hidden in the settings menu on a per-role basis. There are two capabilities per setting following this pattern:
<settingName>DefaultEnabled
- If present, setting is enabled by default for this role, otherwise it is disabled by default
<settingName>Visible
- If present, setting is visible in the menu for this role, otherwise it is hidden
Some features are instead controlled by the live config.
Further details on this can be found in Control related settings.
Whilst in UI mode, if you hold the left or right mouse button, you temporarily enter "game mode". This can be used to "drag" the camera to look around. Releasing the button returns you to UI mode.
This is enabled by default.
The live config flag to control this is Approachability.Controls.GameReadyClickToTurnEnabled
.
Enable with Capabilities.ControlSettings.ClickMoveDefaultEnabled
Visible in menu with Capabilities.ControlSettings.ClickMoveVisible
Whilst in UI mode, clicking on the ground will move you to that location
It can be disabled, but it is the main feature that the Approachable control scheme is built around and is not recommended to be disabled when using that control scheme.
The setting controlling click to move is click_to_move
.
Whilst in UI mode, if you click and hold on another player, you can start following them automatically.
Controlled by Approachability.Controls.HoldToFollow
live config flag.
Click on an interactive object to move there and interact with it. For more details on the interaction system, see Interaction.
Enable with Capabilities.ControlSettings.HoldToMoveDefaultEnabled
Visible in menu with Capabilities.ControlSettings.HoldToMoveVisible
Whilst in UI mode, hold both mouse buttons to drive the character manually
Controlled by the hold_to_move
setting.
Manually drive avatar with the WASD keys, W for forward, S for backwards, A to turn left and D to turn right.
Enabled by default. It can be disabled, but it is not recommended as it does not interfere with any other controls or require additional UI elements while being the most popular method of controlling a character in a 3D world.
It is controlled by InputAxis MoveForward
and InputAxis MoveRight
. These can either be remapped or removed in your downstream project, by following Modifying controls' input keys.
Jump is enabled by default.
Can be disabled via the General.AllowJump
live config flag.
Bound to the Jump
input action (default mapping is space bar).
Double jump is disabled by default.
Can be enabled by setting the Character::JumpMaxCount
UPROPERTY
on your player character class to 2.
This will require your own version of the Character, as the engine plugin version cannot be modified.
Alternatively, can be enabled by setting the JumpMaxCount
value to 2 under Character
in the Live Config Game
Schema.
This setting controls whether sprint is a press to toggle, or hold to sprint.
Controlled by the hold_to_sprint
setting - the live config default value is CustomSettingDefaultValues.hold_to_sprint
Manually drive avatar with a virtual stick on mobile.
Enabled by default on mobile. It can be disabled to make space for other UI elements on mobile using the Approachability.Touch.ShowVirtualJoystickOnTouch
live config flag.
Enable with Capabilities.ControlSettings.EdgeLookDefaultEnabled
Visible in menu with Capabilities.ControlSettings.EdgeLookVisible
Whilst in UI mode, turn the camera by hitting the edges of the screen with the mouse.
Recommended only for laptop / trackpad users.
Controlled by the edge_look
setting.
In some circumstances, you will want to force the player into UI mode, even if using the game-ready control scheme (e.g. if you're opening a UI element/menu you want them to interact with). Similarly, sometimes you'd want to force the user into "game mode", e.g. if using a gun that requires aiming/turning the camera with the mouse. We have helper functions to support these:
BPC_M2_ApproachabilityCameraControl
provides the "Add Click to Turn Override" and "Remove Click to Turn Override" functions, which can be used to force UI Mode on, and restore the previous state when done.
This will always enable the "Click to Turn" camera controls, as the player won't be able to use anchored camera control.
See BP_Presenter_Selector::SetMode
as an example of forcing UI mode to control the selector cursor.
BP_Origin_PlayerController
provides two functions:
Disable and Lock UI Mode - the player won't be able to switch UI mode anymore with RMB, and camera control will always be anchored to the mouse
Restore and Unlock UI Mode - this clears UI Mode overrides from the function above
SeeBP_ItemExecutor_ImpulseGlove_Approachability
as an example of disabling UI mode and forcing the anchored camera controls when the Impulse Glove is equipped.
Changing UI mode is bound to the ToggleUIMode
input action. The keybinding is RMB by default. If you want to modify this keybinding, or remove it altogether, see Modifying controls' input keys.
This will only affect the ToggleUIMode
input action. By default, "Click to Turn" also uses RMB, though this change won't affect its keybinding. "Click to Turn" is considered a "Secondary" input action by the Approachability controller (see BPC_M2_ApproachabilityCameraControl
).
Each of the above modular control features can be individually configured, both by setting default values, or by exposing the settings to the user to configure personally.
Each setting is gated optionally behind a capability and a setting value. The rules are:
If the control feature has a single capability under the "Approachability" capabilities, the role must have that capability to use the feature. Note this is the "Legacy" way of doing things before controling with a "Default Enabled" and "Visible" capability pair.
If the control feature has both a "Default Enabled" and "Visible" capability under the "Control Settings" capabilities, it will be enabled by default for roles that have the "Default Enabled" capability.
If a role has the "Visible" capability, a toggle will appear in the options menu to change the default. If the "Visibile" capability is not granted to the role then the setting will be hidden and the default will always be used.
To grant a capability to a given role, go to your project's roles table.
In the role's Role Configuration Overrides
, make sure the Granted Capabilities
is checked.
In the Granted Capabilities
field, you can add the desired capability.
Roles use inheritance from parent roles, so it is worth checking first whether the capability has already been granted in a parent role.
Additionally, if the feature has a setting, the setting's value needs to be configured to true.
See BPFL_ApproachabilitySettings::CanDoAction
- it checks both the capability and the setting
In the case of over_the_shoulder_cam
, only the setting is required, not a capability. It uses BPFL_ApproachabilitySettings::GetSettingValueAsBool
to check whether the setting has been set.
If you want the setting to be visible to your users, you need to add it to your project's settings data table (the example is DT_SettingList_Skypark
).
The setting Row Name is what is used to match to the setting that is checked, i.e. game_ready_controls
.
Additionally, if you want the setting to only be visible for certain roles, you can use the Capabilities for Visibility
field. That way, players in roles that don't have that capability won't have the setting shown.
Actually getting the setting in-game is done using the BPFL_ApproachabilitySettings::CanEdgeLook
method, providing the setting name, and the relevant gating capabilities.
For settings that don't have a "Default Enabled" capability, the default values are defined in the live config, grouped under CustomSettingDefaultValues
. The setting name is used to obtain this value must match the name passed in to the BPFL_ApproachabilitySettings
helpers, and the data table entry if there is one.
If you want to replace the input binding used by a particular action, you first need to know what input action it is using.
If it is an InputAction
or InputAxis
, you can modify this in your Project Settings -> Input
.
If it is using enhanced input (the action is an Input Action
asset, with a name beginning with IA_
), you can modify the binding in its Input Mapping Context
.
See e.g. the quickbar shortcuts. They are defined in the character's MorpheusActor's InventoryHandlerComponent
. If you replace the mapping context IMC_QuickbarSlots
with a custom mapping context of your choosing, you can modify the keys used.