API Status

Setup Play-in-Editor

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:

Using the template project

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 Using The Template Project.

Summary

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:

The assets below are what are made automatically for you by using the template project, so the simplest flow would be to start from there.

Asset to override
Copy or Inherit?
Where to apply?

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

In more detail:

  • 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 Character:

  • 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.

There are some other base classes in msquared that can be used as valid starting points, such as accessing the C++ directly (via PlayerController, M2_CharacterBase or M2M_CharacterBase). However, these will be missing some of the expected Origin features, so only use these if you really know what you're doing.

  • 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.

Setting up the map

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

Changing animations

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!

Configuring to use MMLs

There are a currently a few workarounds required for full functionality (especially related to MMLs) when using Play-in-Editor functionality.

The following sections are current required to place MMLs when in Play-in-Editor mode - this requirement will be removed in a future update.

Ensure you're using the correct game mode

You need to be using the BP_Origin_GameMode (configurable via world settings), or a game mode that is a child of this.

You may need also need to add this change to the template maps: InfinitySpace and Meadow. A fix for this will be rolled out in a future release.

Configuring Sign-in Settings

You can find the current sign-in settings by navigating to Editor preferences > General > Sign in settings

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.

Setting name
Description

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.

This option is only available when Use Local Bot Api Key is enabled. This is an internal-only feature. Default value: false.

Transient User Allocation Token

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 feature.

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

Setup
Server/Client Behaviour
Notes

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.

Api key - Disable Use Local World for PIE. - You will need to perform Editor sign-in

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.

Local world authentication

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.

If you disable this setting, you will need to Set up server credentials.

Set up server credentials

This is only relevant if you don't have local world authentication enabled.

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

The Editor Sign In button will only appear if Local world authentication is not enabled

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".

Set up client credentials

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

PreviousExtra WorkflowsNextSetup Local Asset Validation

Last updated

Was this helpful?