Full ODK Blueprint node library with descriptions for each node. https://odk-blueprints.preview.msquared.io/v9.3

The Otherside Development Kit (or ODK) is a platform built for the Yuga community to build and share experiences within the Otherside community.

The ODK is built on top of MSquared's World Builder platform. World Builder documentation is available here. The World Builder is built on top of a Blueprint only version of Epic's Unreal Engine, and is architected to allow quick iteration on content, while also providing unparalleled player number and quick and easy travel between worlds.

It's highly recommend that if you intend to develop for the ODK that you familiarize yourself with the basics of the World Builder platform. In particular, sections that are useful to read are:

• Morpheus networking

• Difference from native Unreal

The ODK also provides a host of Otherside related content built on top of the World Builder. The majority of the functionality is provided within , which is located within the engine plugins of your ODK Unreal installation

Please peruse the provided content, and use the as means to explore what's available within the ODK.

Welcome to the Otherside Development Kit!

If this is your first time here, we recommend setting up an example project from one of our templates and experimenting with what's possible.

Otherwise take a look at the plugin and templates that are provided with the Otherside Development Kit

It is HIGHLY recommended you read Msquared's documentation to familiarise yourself with some core concepts within the World Builder that the ODK builds on: https://docs.msquared.io/ The sections that are partcularily important are

• Morpheus networking

Our guide to example the Token Gating system can be found here: We have three examples of Token Gating in the Boneyard Experience.

The clubhouse as pictured above gates entry for Bored Ape holders only, these is a good way of adding areas into your experience that are only accessible by owners of specific NFT collections.

The above shows the Toilet ontop of the clubhouse, we gate this as part of the quest "Drop a Deuce" which can be started via the Quest Giver desk. We gate entry to this Toilet unless the player has a Drop a Deuce token, this is a great example of how to incorporate token gating as part of a quest, where players can only access at a specific stage of the quest or once completed.

The above force field is just bound to requiring having 1 of each of the three coins scattered around the level (x1 bronze, x1 silver and x1 gold) its a good example of how we can leverage token gating until you have certain pickups or maybe items from a vendor.

In this documentation we've set up a few sections to go over:

- Quick overview of some common 3D terms and approaches

- Basic 3D asset specifications

- General Guides for how to create good character art for Otherside

- A full tutorial of creating a complete avatar collection.

- Overview of how to get your 3D assets to be available in the Otherside.

The Otherside and ODK is built on top of the Msquared network. Full documentation on their Avatar system here → . This guide is meant as a QuickStart resource to guide ODK developers in creating a full NFT collection of Avatars.

While there are many ways to build assets for digital worlds, this information will present comprehensive guidelines on how to make sure you can build and maintain avatar collections for Otherside.

1. Upload GLBs to a Publicly Available Location

To make avatars available to all your holders they must be publicly available. They will be downloaded from the storage controlled by you into the Otherside when a user requests an avatar.

In this guide we will walk through the steps of creating an incredibly simple avatar collection...Boxie!

There are many tools for and techniques for creating 3D avatars, this guide will walk through some of the most straight forward approaches.

Prerequisites

• Blender 4.5 LTS -

Access the download page and click "Install the Launcher".

1. The ODK Launcher should open and start downloading the ODK.

2. When the download is complete, the template selection window should open with the option to load an existing project or create a new project from the ODK template:

Configuring Player Character Input Mapping Contexts

Date of change: 11/12/2024

Affected Features: Input

What’s broken and why?

The way we configure the default input mapping context on a character is changing to allow us to add IMCs to the base ODK player character.

How to fix it?

The creator portal is used to create the on-chain tokens and metadata for that token. This includes its name, description, image and any additional fields required for gameplay.

🔹 1. Open the Creator Portal

Go to: 👉

This web interface allows you to define and mint tokens for use in-game. ⚠️ Note: The portal only shows objects created by the currently logged-in user.

• Prohibited Content: Otherside bans the use of its platform to publish certain content, including items that infringe intellectual property rights, are stolen, are misleading, or violate laws and regulations. The company encourages users to report any content suspected of violating these rules.

• Moderation Actions: When prohibited content is reported or detected, Otherside may:

  • Limit the visibility or feature status of the content.

To provide starting points, and examples for how to build functionality, the ODK is shipped with a handful of template projects.

ODK Empty Template: This template provides the minimum content required to startup an ODK project. Use this project once you're familiar with the ODK process and workflows, and are looking to start a new project.

ODK Boneyard Template: This template provides examples usages of some of the content.

ODK Combat Template: This template provides examples of how you can implement a high-fidelity shooter within the ODK.

1. How do I get access to the ODK?

Please reach out to your representative at Yuga who can organise your onboarding, as part of this process you need to supply all emails that will need access to the ODK tooling.

Once you have been given access please follow the quick start guide which can be found here: https://docs.otherside.xyz/odk-documentation/documentation/quick-start-guide/getting-setup-with-odk-development

1. When setting up a new project I get this error "Error getting space required: Error: Expected string at Index 6"

Please log in with Otherside and NOT Msquared as shown in I am unable to Login to the ODK Launcher

1. I am unable to Login to the ODK Launcher

Please ensure that you are logging in with the email that you have sent to your Yuga contact to get whitelisted. If this step has been completed please ensure that you are logging in via Otherside and not Msquared on the Launcher. There is also a known issue where it may take two attempts to login. If you are still facing problems then please reach out to your Yuga representative.

1. I am unable to enter admin mode within the engine.

Please review the

For any role that you want to have access to the Inspector (historically just Director) add the Capabilities.Morpheus.InspectorEnabled capability to the GrantedCapabilities field within your data table for those roles.

1. When I open the Launcher it get stuck on the spinner

First you want to confirm that you have the latest launcher installed which you can download from the dashboard, then if that doesnt resolve it please follow the guide for clearing credentials here:

1. I am unable to sign in via the Editor

Please follow the guide here:

If you continue to encounter sign-in failure, please collect your unreal logs and share them in your ODK support channel.

1. I am unable to open the web overlay within my experience/or my account details are incorrect on privy on the overlay/ or I am getting errors when opening the overlay.

With the move to using Privy the way you access deployments has changed, if you go in via the Otherside Dashboard you won't go through the Privy auth process, so when access deployments please append the following link with your WorldID and ProjectID. Please note you don't need the [] on either project ID or world ID

• https://main-o7e.preview.msquared.io/?world=[WORLD_ID]&project=[PROJECT_ID]

We've noticed on rare occasion the web browser can fail to process the content URL that it's attempting to display. We're continually working to resolve these types of errors. If you do encounter this error, please toggle the web browser to resolve (pressing Tab). If the error persists, please raise it within your ODK support channel.

Below are the technical requirements and supported features for avatars in Otherside. Following these ensures your assets import cleanly and display correctly.

File Requirements

3D Asset

• 3D Model Format: GLB (binary glTF)

• Texture Formats: JPG or PNG

• Shading Model: PBR (Physically Based Rendering)

MML File

• UTF-8 encoding

Supported Texture Channels

Only the Basecolor map is required. Other maps (Normal, ORM, Emissive) are optional but can greatly enhance visual fidelity.

👉 Important: Only include Emissive if your avatar actually has glowing elements.

Please find the breaking changes for each ODK version listed as a sub page to this one.

ODK has M2 as a dependency, so please always refer to MSquared Breaking Changes when upgrading versions.

Below is the ODK to MSquared version guide

As part of being part of the ODK ecosystem, you get some fairly extensive Avatar management out of the box. There's a few pieces to what's available, that we'll go through here.

What avatars are available?

Currently we've proved avatar implementation for the following collections:

1. Bored Ape Yacht Club

2. Meebits

3. Kodas

4. Moonbirds

There are also individual avatars meshes available for the following collections:

1. Mutant Ape Yacht Club

2. Voyagers (Otherside)

If you log into an experience with an account that has a wallet linked with a relevant token, you'll be able to select that avatar as your in-game character from the .

Both the Koda and Moonbirds collections also have unique Animation Blueprints to allow custom animations (beyond the standard Otherside animations set).

More collections will be brought online as the ODK matures.

How are the avatars implemented?

To provide dynamic access to a vast array of dynamic characters, at runtime we download and encode the relevant character meshes from their definitions. This implementation allows us to utilize our Carnival renderer which allows us to scale the number of unique characters in a world at once to 10,000+ !

How is it implemented within the ODK?

Current supported avatar types are tracked within the BPE_AvatarType enum within Unreal.

The flow for selecting a player is as follows.

1. Retrieve the player's current selected avatar token via the KVStore within BPC_ODK_ProfileOverlayHandling .

2. Once the avatar type has been verified, request the character load on BPMC_AvatarInfo. This component manages loading the specific GLB on the M2M_CharacterAssetComponent as well as replicating the avatar type information out to observing clients.

3. BPM_ODK_PlayerCharacterBase listen for avatar info updates, and then calls

If you're interested in observing when a player's avatar type changes, then bind to the AvatarTypeUpdated event on the BPMC_AvatarInfo component.

If you're interesting in modifying the default avatar behaviour on clients, then overriding the RefreshAvatarTypeAnimState on your ODK character will allow you to react to the default avatar behaviour.

Role promotion can be used to change the game experience for an individual player. It can be used to give some players extra abilities or visuals. In the Meebits Combat Gym, the player who has the highest score on each team gets promoted to the "Titan" role. This role simply increases the player's size. This serves as a demonstration as to how a role can be granted to a player. Inside BPM_TitanPromoter, this simple logic is run on the server in order to promote a player to a "Titan".

This guide walks through how to set up a new flow.

🎭 Step 1: Place the Task Flow Actor

Start by placing a BP_ODK_TaskFlow actor in your level.

This actor is responsible for:

Kodas

Kodas are the main characters of Otherside. They use Soma to create forms and Chaos to take them away. If someone owns a Koda, they can play as that Koda.

In the Resource game, Kodas have special uses that gives players advantages.

The ODK provide text and voice chat moderation services that allow you to moderate users within your worlds. The moderation page is available here.

Please reach out to Yuga to request access to the moderation page.

MML format is correct and the GLB is valid but it is not loading in the Otherside.

Double check that the MMLs are encoded with UTF-8 and not a something like UTF-8 with BOM.

Avatar prepared but not loading in ODK/Otherside

Check the output logs in editor tab for more details on possible errors. - Make sure the rig uses the exact bone naming and positions from the reference skeleton. - Do not include any additional bones or unsupported structures. - Make sure your GLB files are publicly accessible (avoid CORS issues)

The ODK widget has some useful built in functionality. Defining IMCs You can use InputMappingContexts to define the IMCs that should be enabled when this widget is Activated. All other IMCs will be disabled. When the widget is Deactivated, the IMCs enabled previous to the widget being Activated will be re-enabled. UI Mode You can define the UI mode that widget needs when Activated. Generally, if you need some button input for your widget, you will want to use input mode GAME_AND_UI. Getting the last input type GetLastInputType can be used to find out what the last input type was (Gamepad/Keyboard etc).

You can derived your widgets from WBP_ODK_Widget. The InputMappingContexts property WBP_ODK_Widget can be used to configure which IMCs should be active when the widget is on screen. This will use the BPC_ODK_InputComponent to push a new IMC state onto the stack when the widget is displayed on screen. When the widget is closed, the state will be removed enabling whatever IMCs where active before the widget was opened.

Feature Overview

The team select UI allow players to change team. Use the "N" key to open the UI.

Technical Overview

All functionality can be found in WBP_TeamSelect.

Key Concepts for 3D Characters

Before you make a character, it helps to know a few basics. Don’t worry—you don’t need to be an expert! These ideas will just give you the vocabulary to follow the steps later.

The ODK uses the BPC_ODK_NiagaraEffectsManagerComponent to play local and replicated effects on characters. The BPMC_ODK_GucciTrailHandler is an example showing how we add and remove effects to characters that own a Koda pendant NFT.

Inside BPMC_ODK_GucciTrailHandler::TryApplyGucciTrailEffect, we use the BPC_ODK_NiagaraEffectsManagerComponent to add the Gucci Niagara visual effect to both characters feet using AddNiagaraEffect. It's parameters are as follows: Niagara System - The Niagara system to add. Socket - The socket on the character mesh to attach the Niagara system to. Relative Transform - The transform which should be applied to the Niagara system relative to the socket. This lets you offset/rotate or scale the visual effect in relatioin to the defined socket. Is Persistant Effect - If true, the visual effect will play continuously until removed. If false, the effect will run once and then be automatically removed. Replicate - Should the effect be visable to other players as well.

Overview

Wallet views allow you to filter the tokens in your wallets. If you want to get all koda cam photo tokens, you can use wallet views for that.

To get tokens in a view, simply call GetWalletView on the BP_ODK_WalletWorldService. You will need to pass in the WalletViewClass for the wallet view you care about.

Live Config Changes

Date of change: 16/07/2025

Affected Features: Users with existing ODK projects

What’s broken and why?

Currently ODK schema is embedded within the `ODK` section within the project.schema. For legacy reasons, the ODK schema was instantiated with each template, rather than stored with the plugin content itself. To ensure you're operating with the latest, correct ODK schema, please integrate the latest schema here into your project. This process will be corrected in the ODK v9 release so users don't need to manually manage this at that point

If you haven't already downloaded and installed blender go ahead and do that now.

We are using Blender 4.5 so all menu placement and controls will be aligned to this version of Blender. You are welcome to use another version, some things might have changed slightly in the program based on which version you are using.

Morpheus Array Type Redefinition

Date of change: 08/12/2025

Affected Features: Morpheus Arrays

What’s broken and why?

Morpheus Arrays in BPs will no longer have their inner type default to integers.

This is due to a refactor in the Morpheus Arrays inner type to integrate with Unreal's redirectors preventing crashes when redirected types are used as an Inner type to the MorpheusArray.

How to fix it?

When opening a widget or in other various scenarios, you may want to the mouse to become visable and allow the player to interact with widgets on screen using the mouse. To do this, use the blueprint function library functions: MarkContextNeedsUIMode and UnmarkContextNeedsUIMode respectively.

You must provide a "Context" when calling these functions. This context represents the object who wants UI mode to be enabled/disabled. If multiple calls are made to MarkContextNeedsUIMode with different contexts, calling UnmarkContextNeedsUIMode once with one of the contexts will not disable UI mode. The system will always ensure the highest UI mode is enabled that at least on context needs.

Feature Overview

BPM_ServerPhysicsObject is a blueprint actor that can be derived from to create gameplay props that have server auth physics. This means that any player can interact with the object and have the physics affects get replicated to all other players. Examples of derived BPM_ServerPhysicsObject classes include: BPM_Dice, BPM_Ball.

The default IMCs used by derived BP_ODK_PlayerCharacterBase assets can be configured by overriding the GetInputMappingContexts function. Simply return a list of IMCs with a configured priority. You can call the base class function to include the IMCs used by the base if you like.

ODK provides an out of the box analytics integration with Mixpanel. You're able to register your own Mixpanel project with Unreal, or reach out to Yuga to be added to their ODK Mixpanel project.

To enable Mixpanel analytics for your world you need to:

1. Add BP_ODK_Mixpanel_AnalyticsWorldService to your additional world services within your world settings.

2. Add a mixpanel project token to live config at : project : ODK.Analytics.MixpanelProjectToken

Selfie Cam

The Selfie Cam example is made up of several modular pieces to showcase the various features required for the end-to-end flow.

At a high-level, the system is composed of the following key components and functions:

BPC_SelfieCamComponent

A component attached to the BP_ODK_PlayerCharacterBase, responsible for toggling selfie camera mode. It spawns the BP_SelfieCameraActor.

BP_SelfieCameraActor

This actor contains a CineCamera component. Once spawned, it attaches to the player's hand socket and communicates its location to the Animation Blueprint via a Blueprint Interface. This enables the Animation Blueprint to sync the hand's location using an IK chain. The actor also manages the Camera UI and binds to its events.

BPC_HighResShot

Another component on BP_ODK_PlayerCharacterBase, with a Take Screenshot event that allows specifying location, format, and resolution. It can display an optional preview widget, which is customizable and works with a Blueprint Interface for swapping. The component also includes the following Event Dispatchers: OnHighResShotSaved, OnFlashShown, OnFlashClosed, and OnPreviewShown.

BPFL_ScreenshotTools

After a screenshot is saved, the image can be uploaded to the user collection using the User Collection Upload Screenshot function from the BPFL_ScreenshotTools library.

Using the Selfie Cam

Important Note: The BP_AttachmentManagerODK singleton must be defined in your level's world settings > Non Morpheus singletons section. The Koda Cam system relies on this manager to perform mesh attachments to both character and crowd actor instances. If the singleton is not present, attached meshes will fail to render, and the avatar selfie stick functionality (for short-arm configurations) will not execute correctly.

The Selfie Cam can be activated using the IMC_SelfieMode Enhanced Input Mapping with the following actions:

IA_ScreenshotCamera_Toggle - Enable/Disable the Selfie Camera

IA_RotateCamera - Rotate the camera when active

IA_ZoomCamera - Changes to field of view to simulate camera zoom

IA_SelfieMode_TakeSnapshot - Save the image to disk

Live Config

The selfie cam is capable of saving high resolution images to disk and uploading them. This could lead to several large files being uploaded by multiple users. To mitigate any risk, several Live Config values have been added:

ODK.SelfieCam.Enabled - Allows for disabling the activation of the Selfie Cam. If this is set to false, when a user presses the toggle shortcut, the BP_SelfieCamActor will not be spawned. ODK.Collections.AllowImageUpload - Users will stil be able to use the Selfie Cam, but the Image Upload option will be disabled.

In this section we will go through how to properly setup a material in blender such that it exports properly to the GLB.

There is extensive information in the Blender docs about this if you want to read more: https://docs.blender.org/manual/en/4.5/addons/import_export/scene_gltf2.html

The first step we want to take is opening up Preferences

Navigating to Add-ons and then glTF 2.0 format and enabling Shader Editor Add-ons

This will allow us to export occlusion maps if we have them.

Switch to the Shading tab to begin making our first material.

Select a mesh in the viewport and click the New button on the top of the Shader Editor window to create a new Material. I am going to rename this material BaseMaterial.

Let's add a new node glTF Material Output we won't need it immediately but we can get it setup now in case we need it in the future.

Just to test how this works let's make this material chrome like.

• Adjust Metallic up to 1.0

• Adjust Roughness down to 0.1

Then export the glb, run it through the avatar web tool and set the path in the ODK Unreal Editor to the newly downloaded GLB.

Boxie now has a chrome head!

Any specific material settings should be tested at this point to help inform what values any texture maps you create should follow.

Note about Transparency

Currently the avatar web tool removes any transparency from materials. If you want to use transparency you'll have to use the CLI tool that we will cover in the pipeline portion.

Transparency is pretty limited in game for avatars. There are two types that are supported.

• Dithered - well suited for decals or cutting holes in geometry.

• Blended - This can create semi-transparent materials however it does not support reflections so materials like glass are hard to recreate. Additionally there can be some Z-Buffer issues when using this method so if this is enabled the entire object that has this material applied to it should be expected to be transparent.

You can switch between these two settings in the Details panel in the Materials section in the dropdown Render Method

We cover best practices for asset production and QA in Asset Production Best Practices.

For this simple example the final Blender file ended up looking like the images below. All textures, meshes, and materials were made simply so I could finish this guide in a reasonable amount of time.

QA

The QA process you take depends greatly on how your collection is structured. I would recommend taking the approach for review we did in the section and adapting that for your collection. You could:

• Create a UI in engine to switch between avatars either via local files or use the load GLTF from URL node and have them uploaded to a public location.

• Set the blueprint to cycle through all avatars or a subset of avatars and render that to a video file from unreal to review the avatars.

If working with a large collection it helps to determine what the smallest subset of avatars represent all traits, and then add some spot checking of random avatars to hedge against faulty assumptions in the minimum trait list.

The boneyard is a space that the ODK development team used to develop ODK functionality and serves as a space where we can showcase example content and use cases to the ODK community.

All content within this space should be used as an example for how we have achieved aspects of functionality.

BPM_ODK_Example_PlayerCharacter

The companion Morpheus Actor of BP_ODK_Example_PlayerCharacter. This Blueprint extends from BPM_ODK_PlayerCharacterBase and should be used for all replication logic within your world.

BP_ODK_Example_PlayerCharacter

This Blueprint extends from BP_ODK_PlayerCharacterBase and should be used to add your own character logic.

BP_ODK_Example_PlayerController

This Blueprint allows easy extension of the player controller. It should be used when you wish to inherit M2 base functionality while also adding your own logic.

Our wallets system allows developers to interact with a player's owned (or delegated) tokens. BP_ODK_WalletWorldService and BPMC_ODK_WalletComponent are the main classes you may need to interact with.

BPMC_ODK_WalletComponent can provide you with the WalletAddress fo the player. BP_ODK_WalletWorldService can be for most functionality regarding tokens.

For any wallet that's associated with a user's account, we automatically listen for all tokens within the wallet, and store those details within the BP_ODK_WalletWorldService . Any dynamic changes are also tracked at runtime, and you can bind to the following events to respond to token changes:

• OnTokenAdded

• OnTokenRemoved

• OnTokenBalanceUpdated

For more sophisticate token handling, it's recommend that you utilize .

In-world gating uses the base class BPM_GatedAreaBase.

This can be done by opening Editor Preferences > Sign-In Settings and adding your credentials.

This feature intends to allows devs to limit access to gameplay. Players are limited on a condition. This condition usually concerns token ownership, however, the system allows for completely generic gating. BPM_ODK_GatedArea_Plane is a fully working example that you can use to start gating access to areas of your map. If you plan to create you own type of gated area, we recommend looking at this asset to understand the workings of the system. It has a property GateCondition that can be used to configure who can navigate into an area.

Gating Conditions

Gating conditions can be added to the gated area actor by configuring the GateCondition property in the details panel of the BPM_ODK_GatedAreaBase. In the following example, the gated area is gated on whether a player has any token on the ethereum block chain.

There are many types of gate condition that are defined in the ODK. The BP_ODK_GateCondition_AND and BP_ODK_GateCondition_OR are key conditions that allow you to combine conditions together for more complex gating. The following shows a gate condition that requires ownership of both a bored ape and a mutant ape (defined by giving a contract address).

If you can not find the condition you need defined within the ODK, you can create your own condition by deriving a new object from BP_ODK_GateCondition and overriding the IsConditionSatisfied function in your new asset.

The arcade machine is an example of how you can link to an external URL via the web browser. In this example we link to TopTrader.xyz which is done by using the blueprint BP_Interactable_OpenURL and calling OpenWebBrowser with the desired URL on the BP_WebBrowserWorldService

Coins in the Boneyard are examples of how you can implement collectables on chain, these pickups grant players tokens to their wallets.

BP_ODK_PickupExample is an example blueprint where you can see how this is achieved, using the RequestGrantToken node we define a token to grant and the target will be defined by the WalletComponent that will contain the address of the players wallet.

Overview

This is a curated list of resources () for Metaverse Markup Language (MML): tools, docs, editors, and more.

is Metaverse Markup Language, developed by Msquared.

🧠 Conceptual Overview

The ODK Quest system builds on top of the Task Flow system to offer a blockchain-integrated questing experience. Each quest is defined by a set of sequential tasks, with a unique on-chain Fungible Token acting as both the activator and the progress tracker.

A quest typically looks like this:

1. The player is granted a Quest token to begin.

Glyph

Otherside uses a user-friendly wallet called . Glyph simplifies web3 onboarding for both users and developers by using traditional web2 methods of account creation (ie. using a gmail account).

Glyph facilitates login, wallet integration, fiat onramping, and onchain actions with gas sponsorship. Built for developers, it's scalable and easy to integrate.

It's built on Privy technology which allows for common SSO's to be used in the sign up process like Google. More information about the service can be found here:

What do we use Glyph for?

We use Glyph in the Otherside to allows users to seamless create wallets that they can use within the experience, Glyph also allows linking to third party wallets e.g Metamask. Alongside this we also use Privy to manage user accounts within the Otherside Platform.

To create an account, please first reach out to your Yuga support contact, and provide your (and your teams) email address details. We can then credit them with the appropriate permissions. Once complete, please browse to the to create your account.

To create an account, or login. Click the "Login" button, and then enter the email details you provided above. You'll be sent a confirmation code to your email to validate your login.

The ODK notification system allows for developers to display notifications on a players HUD.

The Notification Singleton

By default, the BPM_NotificationsSingletonODK singleton is set in the World Settings. This can be extended and replaced to allow for custom functionality. The singleton serves as a notifications manager, broadcasting notifications upon receiving a request.

The video screens in the ODK are intended to be a seamless solution for playing video alongside important millicast streams. The BPM_VideoPlayerWithMillicastBase actor is a base class for these screens but will not function without a mesh to display the video on.

BPM_VideoPlayerWithMillicastCurvedScreen is an example of how the base class can be extended to show the stream on a mesh in the world.

The important function to consider here is “GetMeshComponentToDisplayOn” and should be overwritten to define a static mesh component and MaterialIDs

In this example, the video is displayed on the curved video screen mesh and assigned to material IDs 0 and 1. This allows for the image to be shown the correct orientation on the back side of the mesh.

Step 1

Ensure you are using the custom sign -in method in Editor > Sign-In Settings as shown below, this should be set too:

The overlay is a fully featured Chromium browser that is used in the ODK to render UI elements, this allows us to get all the benefits of web based development and also have a unifying set of menus across all ODK experiences.

Web Browser functionality is controlled via the BPFL_ODK_WebBrowser function library, and the BP_WebBrowserWorldService .

Pressing "Tab" within an experience will open the Player Profile overlay menu, which is available in every experience within the Otherside Platform. This overlay displays the Players progress and inventory as they explore the Otherside. This page consists of the following sub pages:

Overview

• This section gives the player a high level view of their progress within the Otherside, it will track key metrics, show their avatar, display badges and allow them to show off their prized NFT's on this page.

The persistence system in the ODK can be used to store data remotely. Examples of it's use might be: storing player progression or storing high scores for a mini game. On the backend, the storage system is simply a map of keys and values as string. You could imagine that for the high scores example, you might want to store the data using "high_scores" as a key and a json encoded object string for the data in this form.

The Persistence Service

The main class to be concerned with is BP_ODK_PersistenceWorldService. This world service provides functions in the following flavours: ReadValue, RegisterInterest and Save. The full list is: - ReadIntValue - ReadJsonValue - ReadStringValue - RegisterIntValueInterest - RegisterJsonValueInterest - RegisterStringValueInterest - SaveIntToPersistence - SaveJsonToPersistence - SaveStringToPersistence

The ODK interaction system facilitates interactions between the player character and in world props.

Basic Interaction Flow

Player characters have the BPC_ODK_InteractionComponent attached to them. All interactable actors have a BPC_ODK_InteractableComponent attached to them. The BPC_ODK_InteractionComponent periodically polls interactable components to see which is the current

🧠 Conceptual Overview

The Task Flow system allows you to define a sequence of tasks that guide a player through an experience—such as a quest, tutorial, or onboarding sequence—using a structured flow of triggers, conditions, and actions. Each task is handled one at a time, and the player must complete them in order to progress.

The core components of the system are:

🔁 Triggers

A trigger defines when the task flow should begin. For example, the flow might start when:

• A player receives an on-chain token

• A player overlaps a specific volume in the world

• The game reaches a certain boot state

Triggers often work with conditions to check whether the flow is allowed to start. For example, the trigger might fire when a player enters a zone, but the condition ensures it’s only valid on Wednesdays.

✅ Conditions

Conditions exist at both the flow level (whether the sequence should begin at all) and the task level (whether a specific task is ready to activate).

These conditions are logic blocks you can define—for example:

• “The player has not completed this flow before”

• “It is daytime in the game world”

• “The player has reached a specific location”

Conditions must complete successfully for their corresponding flow or task to proceed.

🎯 Tasks

A task defines a goal that the player must accomplish to move forward in the flow. For example:

• Task 1: Jump three times (track jump count from a movement mode change)

• Task 2: Perform a specific emote

Each task must signal when it's complete using the Task Trigger Execution Complete event, which tells the Task Flow system to move to the next step.

All tasks are initialized using the Initialize Task Flow Executor event.

⚡ Actions

Actions are optional, fire-and-forget logic blocks that execute at key moments in the flow lifecycle. You can use them to:

• Show a VFX or sound at task start

• Spawn an item when a task begins

• Hide UI or clean up actors when a task ends

Actions can fire on events like:

• Flow Start / Complete

• Task Start / Complete / Skipped

They are lightweight and don’t report back to the task system—they simply execute and move on.

This system is designed to be flexible, data-driven, and extendable—whether you’re guiding the player through an onboarding sequence, building a narrative quest chain, or triggering progression gates.

The ODK Launcher has two streams which are:

Public: This version of the ODK is released to all developers.

Preview: This version we grant early access to new ODK features for early testing. Once the preview version has been publically released you will need to switch back to Public and we will remove you from the Preview stream. If you need to access a preview version of the ODK you will need to reach out to your Yuga Representative who can organise this. Developers need to be given special access permissions to use this stream.

If you are switching to Preview then please follow this guide for how to do so.

Guide

1. Log into the Launch via Otherside Login, and NOT Msquared Login

2. Select ODK Alpha from the web project drop down

3. Click the settings cog in the top right and select Preview in the update channel drop down

4. Click the Top left button that loads the launcher version installer menu

5. Click Add Installation

6. From the version dropdown select ODK Chapter 8.1 Preview and click Install

BPC_ODK_InputComponent is the main manager of input in the ODK. This component lives on the BP_ODK_PlayerControllerBase asset.

Enabling and disabling IMCs BPC_ODK_InputComponent can be used to control which IMCs are active. BPC_ODK_InputComponent uses a stack of states where each state contains a set of IMCs. When a state is active, all enabled IMCs are disabled and all IMCs on the newly enalbed state are enabled. PushInputMappingContextState - can be used to add an new state to the stack. This state will become active. RemoveInputMappingContextFromState - can be used remove a state from the stack. The previous state in the stack will become active. AddInputMappingContextToState - can be used to add an additional IMC to an existing state. If the state is active, the IMC will be enabled. RemoveInputMappingContextFromState - can be used to remove an IMC to an existing state. If the state is active, the IMC will be disabled.

Getting the last input type BPC_ODK_InputComponent can be used to get the last input state (Gamepad/Keyboard) by calling GetLastInputType or hooking into the event OnInputTypeUpdated.

Feature Overview

The scoreboard shows the number of kills and deaths for each player. The scoreboard updated whenever: the scoreboard UI is opened, a player joins a team, a player is killed and whenever a player joins/leaves the game. Use the "Z" key to open the UI.

Technical Overview

All functionality can be found in WBP_Scoreboard.

Feature Overview

Spawn point zones are added to the map for each team. When a team is selected, the character will spawn at the associated teams spawn point.

Technical Overview

AJ_PlayerStartVolumes have been placed around the map and tagged with either: RED, BLUE or GREEN. On BeginPlay, BPM_ODK_ExampleCombatCharacter caches all player start volumes on auth clients. When BPM_ODK_ExampleCombatCharacter is respawned, we use our team to find the appropriate player start volumes and teleport to a random player start in the player start volumes.

2025.12.11

New Features

• KodaCam

Since this collection doesn't actually exists we are going to make it ourselves. Feel free to skip this portion and just grab the trait metadata from the resources .

The Boxie collection only has three different traits categories:

• Head

  • classic box

  • sphere

The ODK Token System provides a unified way to track and synchronize player progress, rewards, achievements, and quests across the blockchain and experience.

Tokens can be used for persistent state, with each token type having a specific purpose and behavior.

🔍 What Is a Token?

In the context of ODK, a token is an on-chain data object that represents something the player owns.

Token are:

The ODK seperates different types of movements into different conceptual movement modes. Walking, grinding and gliding are examples of different movement modes available in the base ODK.

Movement modes are controlled via a component on the BP_ODK_PlayerCharacterBase render target. By default, this component is BPC_ODK_MovementComponent, however this can be overriden on BP_ODK_PlayerCharacterBase by setting the MovementComponentClass property.

The BPC_ODK_MovementComponent controls which movement mode should be active at a given time. A mapping is defined on this component between a "movement mode id" and a movement mode component class. This allows for easy overriding and addition of movement mode behaivours.

Adding a new configurable input action To enable configurable keybindings for an input action, you should configure the following on the InputAction asset. You first may want to add the IM_MappingGroup modifier. This defines what context the input action can be used. This is used to automatically reset deuplicate input action keys that are in the same mapping group. As an example, the jump and move forward input action have been added to the same mapping group so that if the user can not add the same key for both.

You then will need to add PlayerMappableKeySettings to the input action's user settings. The following should be configured: Name - just the name of your input action asset. Display Name - The text to be shown to the player in UI. Display Category - The category your input action will be put under in the keybindings UI.

Lastly, you will need to configure you input action inside whatever IMCs it is added to. You should probably add keys for both keyboard and the gamepad. The following should be configured: Name - This should be the name of the input action asset appeneded with either "Keyboard" or "Gamepad" respectively. Additionally, if your input action needs to be added to multiple IMCs, due to the fact that the "Name" property must be unique accross the project, you can append a different number to the end of the name in each IMC.

ODK Base UI is a flexible UI framework designed for building reusable and dynamic widget controls. It simplifies logic binding, value syncing, and visibility control by pairing each control with an Executor.

Controls are placed into UI layouts like any other widgets, but their functionality is entirely data-driven via executors.

This keeps consistency thoughout the Otherside platform, allowing for devs to reuse existing designed controls.

🔁 How It Works

Each control can be paired with:

• A Value Executor (handles functionality and state)

• An optional Visibility Executor (handles when to show/hide the control)

• An optional Registered Control Name (for simple runtime access via the UI system)

🎮 Control Executors

The Executor is a Blueprint class that drives the behaviour of a control. Every executor supports the following functions:

This system makes each control self-contained and keeps your UI logic clean and reusable.

👁️ Visibility Executors (Optional)

A Visibility Executor is a separate class that defines when a control should be visible.

It implements:

• GetVisibility → Returns a visibility state (Visible, Collapsed, etc.)

Use cases include:

• Hiding the player roles dropdown unless the user is an admin

• Only showing Gamepad settings when a controller is connected.

🏷️ Registered Control Name

Every control has an optional RegisteredControlName.

This name:

• Registers the control with the BP_WorldService_ODKUI

• Allows it to be found or replaced dynamically at runtime (See function library below)

🧰 Runtime Editing

The Blueprint Function Library BPFL_ODKBaseUI gives you helpers for modifying UI areas at runtime.

Notable functions:

This system is especially useful in:

• Hot-swapping controls during a session

• Extending shared base widgets without making duplicates

Examples

🧪 Example: Roles selector

• Control Type: Dropdown

• Executor: BP_SettingsExecutor_PlayerRoles

  • GetCurrentValue → returns a string array of available roles

🎮 Unreal Setup (Gameplay Logic)

The Unreal side of an ODK Quest handles how the player interacts with and completes tasks, and ensures that quest progress reflects the player's on-chain token balance. The system uses BP_ODK_TaskFlow actors, Quest-specific task executors, and wallet integration to create a fully synced experience.

For the creation of the Quest token see Creating a Quest token

🔹 1. Add a BP_ODK_TaskFlow Actor to the Level and create a Task PDA

The outlines exactly how to set this up

In your new PDA_ODK_TaskFlow:

• Add a new item to the Tasks array

• Derive each Complete Task Triggersfrom BP_ODKTaskFlow_QuestTaskBase(described below) — these define what in-game conditions complete the task (e.g. jumping, running)

🔹 2. Use the Correct Base Class: BP_ODKTaskFlow_QuestTaskBase

For quests, each task must derive from BP_ODKTaskFlow_QuestTaskBase.

This subclass is essential because:

• It handles sending the token to the user when a task is completed

• Unlike standard tasks, it does not automatically progress

• Instead, it waits for the player to receive the token, then:

  • Reinitializes the flow trigger

This means:

• Token ownership becomes the single source of truth for progress

• You don’t risk out-of-sync task flow states

• Tasks remain paused until the player actually holds the correct number of tokens

All derived tasks should still call:

...once the task’s completion criteria has been met.

🔹 3. Getting Quest Token IDs in Tasks

To associate tasks with the correct Token ID, you need a way to retrieve the ID. This can be done per task — but that quickly becomes repetitive.

Instead, use the built-in system based on BP_GetTokenIDBase, which has two helpful options:

• BP_GetTokenIDFromCustomDetails

• BP_GetTokenIDFromLiveConfig

Recommended: BP_GetTokenIDFromCustomDetails

• Each task checks the custom details of the Data Asset

• You define a single source of truth inside the asset, and all tasks reference it

This means less setup repetition and centralized management.

Alternate: BP_GetTokenIDFromLiveConfig

• Allows dynamically retrieving token IDs from a live config

• Useful for centralized overrides or managing IDs per environment

🔹 4. Activating a Quest

Quests are only activated when the player receives the first token.

This should be granted as part of your experience — how you do this is project-specific.

The easiest way is via:

In the ODK sample, tokens are granted by Interacting with an NPC. This opens a web overlay with available quests.

🔹 5. Granting the Achievement (Reward Tokens)

If your Quest Token includes a rewards array (tokens to grant upon completion), you can automate this via:

We recommend this is assigned to the TaskCompleteActions of the final task, but could also be assigned to FlowFinishedActions.

Why? Because technically the flow never completes in the traditional sense — it’s driven by token sync, and the player could hold the final token before the system registers a full flow completion event. Adding it to the final task will speed up execution.

This approach ensures:

• Rewards are reliably granted

• The grant is tied to the token logic, not just the internal task flow state

🔹 6. Displaying Quest notifications

By default, the player's BPMC_ODK_WalletComponent, found on BPM_ODK_PlayerCharacterBase, contains a TokenHandlers map.

This map listens for changes to tokens and routes behavior accordingly.

Out of the box, the wallet includes:

• "achievement" handler

• "quest" handler

The map’s key must match the type field in the token metadata — for quests, this is "quest".

When a token is added, removed, or updated:

• The appropriate handler is triggered

• You can use this to:

  • Display UI

  • Fire off effects

If you need additional behaviour, you can subclass the default handler and override its logic.

When interacting with emotes in the ODK, the main asset to interact with is the BPMC_ODK_EmotesComponent. This is a component on the ODK morpheus player character BPM_ODK_PlayerCharacterBase.

Defining Emotes

You can define an emote by creating a new PDA_ODK_Emote asset.

Name - Display name used in UI Emote Id - Used to help unlock emotes via token ownership. The token metadata will specify the emote id that it represents ownership of. Icon - Icon used in UI Type - An enum that lets code categorise emotes. Currently the types we support are: STANDARD and COOP. Emote Executor - An object that runs logic to start the emote

Currently, emotes come in two flavours: standard emotes and coop emotes. Stardard emotes simply play an animation on you player character. Coop emotes allow you to play animations synced with another player character. The way these are handled are very different. The emote executor allows for completely different behaivours to be executed by different emotes whilst being handled the same way in the reset of our logic.

Setting Emote Selection

The emotes available to a player in your game can be configured on the BPC_ODK_EmotesComponent on your player render target actor. You can configure the DefaultEmoteSelection property on the component by selecting the PDA_ODK_Emote assets you desire.

Starting and Stopping Emotes

PlayEmote and CancelCurrentEmote can be used to start and stop emotes regardless of whether they are standard or coop emotes.

Overriding Emote Selection

You can override what emotes are available by using the override functions: OverrideEmoteSelection, RemoveEmoteSelectionOverride and, RemoveAllEmoteOverrides. This can be useful for limiting what emotes are available in different contexts. You might only want a couple emotes available whilst the player is in a tutorial but allow all emotes to be played after the tutorial is completed. This can help achieve that. When you apply an emote selection override, a new state will be added to a stack containing the override emotes. When you no longer want to override the emote selection, removing the override will remove the state from the stack returning you to the original emote selection.

Filtering Emote Selection

You can use GetFilteredEmotes, to get a filtered list of emotes that currently playable. This would take into account emote selection overrides. Filtering can be used in conjunction with overrides. You could for example filter the current emote selection for all coop emotes and then apply an emote selection override to only include those coop emotes.

Feature Overview

The Meebit template comes with an example implementation of teams. Players can join different teams to shoot players on different teams.

Technical Overview

A player's teams is stored on a morpheus actor component: BPMC_TeamComponent. This component has a client auth replicated property Team that handles replicated of state to other clients. Teams are defined in the E_Team enumeration. Data regarding teams can be configured in DT_TeamData which uses the S_TeamData structure. This strucure allows you to configure a display name shown to players and a color for a given team.

Tutorials:

Adding a Team

Adding a team is easy! Simply add a new enumeration value to E_Team betweem NONE and INVALID values. Then configure a new data table entry in DT_TeamData. Lastly, you will need to update some simple helper functions so that blueprint logic knows how to access/use your new team. Inside BPFL_TeamHelpers you will to update GetTeamIndex and GetTeamName, adding values. Once you have added your new team!

BPC_Scannable 📸🔍

The BPC_Scannable component extends the Selfie Cam system by allowing specific actors in the world to be "scanned" whenever a screenshot is taken. This makes it possible to tag screenshots with contextual metadata about visible objects — such as quest items, characters, or interactables.

It is a good idea to test how your avatar is going to work in the Otherside by setting up a small test scene to preview some animations.

In order to do this we are going to:

• Create a new ODK project

• Create a new blueprint that will

  • Load a GLB into the ODK at runtime

Token Handlers are objects that react to token changes inside the ODK wallet. They live on the wallet component of the Morpheus player character and define what happens when a token is added, removed, or updated — such as triggering a quest, showing some UI, or playing a VFX.

The system is modular, data-driven, and highly extendable via Blueprints.

🔩 Where Token Handlers Live

Token Handlers are configured on the player's wallet component: 📍 BPMC_ODK_WalletComponent Found on: BPM_ODK_PlayerCharacterBase

For this collection we have 3 Different Trait types. We can combine our separate meshes into a unified mesh for each trait type, and apply the appropriate material. We end up having 1 mesh object for each trait in our outliner.

In order to export unique avatars we will want to only enable the meshes that make up a specific token. We can create a python script in Blender that reads in the JSON we created earlier and enable and disable visibility to export specific token glbs.

The easiest way to do this would be to enforce a naming convention when creating meshes in the outliner something like:

{trait_type}_{trait_name}

i.e.

head_smiley_face

So the general steps would be:

• Read in collection metadata

• Loop through each token

  • hide all meshes

  • enable meshes from token metadata

  • export GLB from Blender.

Installing Avatar Tools CLI

• Download the standalone Binary for node.js v20.11.1

  • Windows

  • Mac

• Extract the .zip and place it in a folder relative to your blender file

• open up a terminal and change the directory to the folder you just extracted i.e. cd /path/to/avatar-tools-main

• add node_bin to PATH

  • Windows set PATH=..\node_bin;%PATH%

Below is a very basic script that can be run within Blender to export all avatars for a collection. There is plenty of room for improvement to fit specific needs and workflows but this should give a foundational look at how to create a simple process for generating all unique avatars.

Setup Reference

We are going to roughly block out the dimensions of our character and manually step through the entire process to get an avatar rendered in the ODK.

We want our Boxie character to be around the height of a Voyager so roughly ~1.8 meters tall. Too tall or wide and the character may not fit through certain areas or other assumptions might break too small traversal will look very strange and again some assumptions may break. That is why making characters between 1 m and 2 m is a hard requirement.

If you aren't already there switch to the Layout view in Blender and delete the Camera, Light, and Default Cube. This is also a good opportunity to save your file.

Let's download the Avatar Height Guide from above, and then in Blender create a Plane. We are going to apply the Height Guide to the plane to get a rough idea of how our avatar will compare to ones already in the Otherside.