Setup Play-in-Editor
Last updated
Was this helpful?
Last updated
Was this helpful?
Setting up the common classes
The assets present in Morpheus Platform are read only - in a downstream project, you cannot modify them, only extend from them, or use them as reference. Therefore if you want to modify different classes' behavior, or add extra functionality, you will need to make your own versions of the assets and use them instead. There are different ways of doing this:
If you create your project using the M² Base Project, the majority of commonly overridden assets will be already made for you, e.g. BPM_Example_PlayerCharacter. These will be writable, renamable etc. so can act as a starting point for your project.
For further details of this flow, see .
When making a new project using the Morpheus Platform defaults, the following is a list of classes to consider making your own versions of, to extend the Morpheus Platform functionality whilst adding your own:
BP_M2Example_GameMode
NOTE: Prior to V33, this would be BP_Origin_GameMode
Inherit
Project Settings -> Default GameMode, or World Settings -> GameMode Override
BP_M2Example_PlayerController
NOTE: Prior to V36, this would be BP_Origin_PlayerController
Inherit
In the Game Mode (Player Controller Class)
BPM_M2Example_PlayerCharacter
NOTE: Prior to V36, this would be BP_Origin_PlayerCharacter
Inherit
In the Game Mode (Player Morpheus Actor Class)
NOTE: Prior to V25, this will have to be done via the PlayerSpawner
BP_M2Example_PlayerCharacter
NOTE: Prior to V36, this would be BP_Origin_PlayerCharacter
Inherit
Either via the Game Mode (Default Pawn Class), or via the role's pawn set asset (see the further details)
NOTE: Prior to V27, this will only be possible via the pawn set asset
BP_M2Example_HUD
NOTE: Prior to V33, this would be BP_Origin_HUD
Either
In the Game Mode (HUD Class)
M2M_MorpheusGameState
Inherit
In the Game Mode blueprint (Morpheus Game State Class)
WBP_M2Example_HUD
NOTE: Prior to V33, this would be WBP_Origin_HUD
Copy
In your HUD BP
Not required as of V36)
DT_RolesExample
Copy
World Settings -> Default Role & Data Tables
(Not required as of V31)
PDA_Skin_Origin
Copy
Project Settings -> Default Skin
(Not required as of V33)
DT_Origin_SettingList
Copy
In your Skin
The GameMode: This configures a bunch of the classes used in your level, e.g. the player controller and HUD classes outlined below. If you want to make a new game mode, it should extend BP_M2Example_GameMode
To apply your game mode, you can either modify per-level in your world settings, or modify the default in your project settings -> Maps & Modes.
The PlayerController: Should extend BP_M2Example_PlayerController.
The Morpheus Actor: The representation of a client's character that is used for replication. Should extend BPM_M2Example_PlayerCharacter.
Prior to V25, the Player Morpheus Actor Class is not available from the game mode. Instead, to make sure your correct morpheus actor is spawned, you should also update the "Player Spawner". Use BPM_Origin_PlayerSpawner as a base, and you can modify the PlayerMorpheusActorClass field in it. This can then be set in your level's world settings
The Render Target Actor(s): The actual character spawned in-game to represent a player. Should extend BP_M2Example_PlayerCharacter
If you want to add further customization to the pawns used, e.g. wanting different roles to have different pawns, or want to make changes to the "animated crowd", you can configure them in your roles table's pawn set asset (the Pawn Lod Level Set field):
(NOTE: Prior to V27 this flow is the only way to configure your render target actor)
For a given role, its PawnLodLevelSet controls what render target is used.
If you make a new pawn set asset (copying the existing one), you can swap out its Base Pawn and LOD0 Actor Class
The UI:
The HUD BP: The logic responsible for spawning the HUD, and managing our UI. An example has been made in BP_M2Example_HUD, which can be used as an example that can either be copied or extended.
The HUD WBP: The actual HUD widget that contains the in-game UI. To use your own HUD widget, we recommend making a copy of WBP_M2Example_HUD as a starting point.
To use your new HUD, you can change the Game Layer Class in your HUD BP.
The Roles table: This controls which roles are available to your players. If you want to modify this, make a copy of DT_RolesExample.
NOTE: The roles table has deprecated as of V36 (but will still be accessible if you are on a legacy project that still uses the "origin" assets). A simplified example will be added soon.
The following are no longer required as of V33, and aren't present in the example content. If you are a legacy project that still uses the "origin" assets, they may be of use to you:
The Skin: This is responsible for the styling of your UI etc. If you want your own skin, make a copy of PDA_Skin_Origin. For more details on skins, see How to use skins.
The Settings table: When you open the "Escape Menu", this table dictates what is present in the UI. If you want to change this, you should make a copy of DT_Origin_SettingList, and set your skin asset's Settings Skin Settings -> Settings Data Table field to your new table.
When making a new map, check the world settings, to make sure everything is as expected:
The GameMode Override: Make sure it points to your new game mode
The Roles table: You can configure the default role, and the roles table used here
The Singletons: There are a number of singleton actors that are spawned when the game is started, and enable various bits of Origin functionality. For more details on these, see Singletons.
In releases before V25, the PlayerSpawnerClass is one you may want to change - if you want to use a different morpheus actor, swap out the player spawner class with the one you created.
The MorpheusGameState class: This game state is similar to the unreal native game state, but with the benefit of being replicated by morpheus. Use this instead of unreal's game state
To set it up, go to your GameMode blueprint class and set it in the dropdown
To retrieve the morpheus game state, use the GetMorpheusGameState function
Your characters' animations are controlled in the ABP_M2_Human. Making changes to your Animation Blueprint in a downstream project is unfortunately quite an involved process currently compared to native Unreal, due to needing to be applied to both actor render targets and the animated crowd. If you do want to do this, please get in touch!
There are a currently a few workarounds required for full functionality (especially related to MMLs) when using Play-in-Editor functionality.
You need to be using the BP_Origin_GameMode (configurable via world settings), or a game mode that is a child of this.
When you first download the editor and create a new project, your sign-in settings will be configured such that you can immediately start PIE with no other modifications. This section will outline how you can configure your sign-in settings to have more control over how your individual clients and server autheticate.
Offline Mode
Skips server and client authentication. When enabled you will not have account information and will not be capable of interacting with the Morpheus platform backend.
This is a good fallback if you experience authentication errors and just need to run PIE to test non-authenticated actions. Default value: false.
Per Client Sign in Settings
The sign in method and parameters to be used by the spawned clients. You must have at least as many configured Per Client Sign in Settings as clients you will be launching in PIE. Default value: 4 clients configured to sign in with SSO.
Trusted Client Api Key
The Api key used to authenticate your local trusted clients (e.g., Sentinel and Remote Viewer). This is an internal-only feature.
Use Local Bot Api Key
Determines whether locally spawned bots should authenticate. This is an internal-only feature. Default value: false.
Local Bot Api Key
The Api key used to authenticate local bots.
This option is only available when Use Local Bot Api Key is enabled
This is an internal-only feature.
Use Transient Users for Bots
Determines whether the authenticated locally spawned bots should be granted a user account.
Transient User Allocation Token
Use Local World for PIE
When this is enabled, the user will be granted a local world context which persists between PIE sessions. It is analogous to a deployed world and can be used to test any requests and functionality made with World scope.
Default value: true.
Client Sign in Stall Method
Advanced feature.
Users can create a blueprint inheriting from J_SignInStallMethodCommon which will allow them to pause bootflow during sign-in until some condition is met.
The default settings are shown below
Below are some common sign-in setups and the setting modifications from the default settings to use them
Default
Server and up to 4 clients will use SSO and use individual credentials. If any of the server or cliens do not have credentials saved, you will see one SSO popup window for each server/client.
Update to V37 to remove multiple SSO!
Offline Mode
- Enable Offline Mode
Server and Client will both skip authentication.
Things may break! As servers and clients in offline mode are not able to perform authenticated actions we don't guarantee all features will work as expected.
Bearer token
- Change the Per Client Sign in Settings Type to User Supplied Bearer Token
- Paste a bearer token into the field
The server will authenticate with SSO. Clients will authenticate with the supplied bearer token. If there are no saved server credentials, you will still need to perform SSO for the server.
Bearer tokens are only valid for 1h. Once your token expires, requests and logins will fail until you supply a new bearer token. All clients can share the same bearer token.
The server will authenticate with Api key.
Clients will authenticate with the configured Per Client Sign in Settings.
Your PIE session will not have a world context to make requests from. This can lead to errors for actions and requests requiring a World scope.
This was the default server sign-in method prior to local worlds. It can serve as a good fallback if you see sign-in errors related to the local world.
By default, PIE sign-in is configured to use local-worlds. This requires no configuration by the user and should work immediately. You can check whether this setting is enabled by navigating to
Editor preferences > Sign in settings > Use Local World For PIE.
In Editor Preferences, in the Sign-in settings section, change your settings to reflect the following where:
Offline Mode is NOT ticked
In the Editor, click on the "Editor Sign In" button on the toolbar
You will be requested to sign in with your Google Account in your main system browser. Once complete, you will be presented with a list of api keys:
The name will depend on the key your organization admin set up.
Select the key they instructed you to use and click "ok".
In Editor Preferences, in the Sign-in settings section, change your settings to reflect the following where:
Offline Mode is NOT ticked
The Per Client Sign In Settings property has the Single Sign On element
This option is only available when Use Local Bot Api Key is enabled.
This is an internal-only .
Default value: false.
The allocation token used to request user accounts for the locally spawned bots.
This option is only available when Use Transient Users for Bots is enabled.
This is an internal-only .
Api key
- Disable Use Local World for PIE.
- You will need to perform
This option is only available when Use Local Bot Api Key is enabled.
This is an internal-only .
Default value: false.
The allocation token used to request user accounts for the locally spawned bots.
This option is only available when Use Transient Users for Bots is enabled.
This is an internal-only .
Api key
- Disable Use Local World for PIE.
- You will need to perform
If you disable this setting, you will need to .
This is only relevant if you don't have enabled.
The Editor Sign In button will only appear if is not enabled
