Overview

The o3hmanifest is a per-module configuration file that holds vital information about:

• The user-facing title for your module and other important metadata.
• The API features required for your module to function properly, and respect users' Global Settings UI preferences.
• The module's asset types, ids, and how they map between your Creator and Audience experiences.
• And more! Skip to the Quick Reference for a complete list!

🚧

The o3hmanifest.json file must be distributed in the same folder as the index.html file in your builds (usually dist/). See Build Delivery Checklist for more information.

Setup Guide

First time here? Cool! This section is designed to get you rolling in no time. Welcome!

Read on for a step-by-step setup and usage guide, or see our Quick Reference to find the topic that interests you first.

Creating an o3hmanifest File

We've set up a useful JSON editor which allows you to easily create (or edit!) an o3hmanifest.json file.

If you need a new manifest, open the editor and fill out each section based on this guide. When you're done, you can download the file from the Download File button.

If you want to edit an existing o3hmanifest, paste the contents into the text box on the right side of the screen, and click the Load File button. Then make your edits and copy the changes over to your project.

While the editor ensures the validity of the JSON while you edit, it doesn't keep you from making incorrect choices. Ensure your module behaves correctly in the SDK whenever making changes to your o3hmanifest.

Asset Inputs and Outputs

The Creator and Audience experiences in your module will utilize the AssetManager to load whatever types of assets needed.

Creator vs Audience Flow

The creatorInputs/creatorOutputs and audienceInputs/audienceOutputs fields contain the asset ids and asset types used in your module's dealings with the AssetManager. These are the assets created by or given to your module in Creator and Audience modes, and

All audience input assets must be mapped from creator outputs. The creatorAudienceMapping stores a mapping of how each asset in your creatorOutputs maps to dependent assets in your audienceInputs.

As an example, let's say your module is recording the creator's front camera, and passing it to the audience:

...
"creatorOutputs": {
    "creatorCameraOutput": "VideoAsset"
},
"audienceInputs": {
    "creatorCameraInput": "VideoAsset"
}
...
"creatorAudienceMappings": {
    "creatorCameraOutput": "creatorCameraInput"
}

Calling these creatorCameraOutput and creatorCameraInput was done to make their connection to each other more clear, but is not necessary. Typically, they can have the same name!

Asset Types

Note that both the input and output asset were of type VideoAsset. Assets that are mapped to each other must be of the same type.

The valid types are:

Feed Video Types

The creatorFeedVideo and audienceFeedVideo values commonly contain the name of the single VideoAsset, but there are a couple advanced options. If an array of VideoAsset names is provided (ie: ['video1', 'video2']) or the name of a VideoCollection is used the videos will be joined together as a single video when the module completes. For a VideoCollection the order of the video join is determined by the order in which the videos are added to the collection.

Features and Privacy Permission Settings

Users must give the Oooh app, and consequently your module, permission to access features like the Camera or Fullscreen Recording on their device. The o3hmanifest file is your chance to let us know which features your module needs, so that we present the right permissions management flows to users for you.

Knowing which features to include in your o3hmanifest is as simple as knowing:

• which API features your module depends on
• whether the features used by your Audience flow should be treated as optional or required.

Types of Permissions Dependencies

When your module calls an o3h API that requires permission from the user, the Oooh client presents the right flows for the right user based on the features described in this section. You should determine which features your module requires based on the APIs your module uses:

Now that we know which permissions your module needs to list in your o3hmanifest, you should list those permissions as required for the creator. But what about for your audience?

Required vs Optional Features

If the gameplay in your module's Audience flow requires a feature to function correctly, you should list it in the required array for the audience. However, if your module can be successfully enjoyed without a feature enabled, you may benefit from listing that feature as optional.

Supporting a feature as optional for your audience means Oooh will allow them to proceed with playing your module even when the required permissions haven't been granted. This greatly reduces friction for audience members who just want to turn their camera off (see leaderboard), or just aren't comfortable recording their screen for some reason.

However, handling these optional features correctly at runtime will be up to your module. If you set a feature as optional in the o3hmanifest, your module should not break when the feature is disabled!

In this example, the module allows Audience members to play even when the permissions required for camera and screen recording have not been granted. However, these features must be allowed for the creator flow, and creators who try to host this module without the required permissions will be asked to go turn them on before they can proceed with playing.

"permissions":
{
    "creator":
    {
        "required":
        [
            "usesCameraComponent",
            "usesFullScreenRecording"
        ],
    },
    "audience":
    {
        "optional":
        [
            "usesCameraComponent",
            "usesFullScreenRecording"
        ]
    }
},

📘

As a quick aside, if all the permissions are optional, it won't show the permission dialog at all, the user will just be taken straight to your module. If any are required, it will show all required and optional permissions, but you can continue without accepting optional permissions.

Please reach out if you have any questions about permissions!

Levels and Chapters

Your module may be designed to offer levels, or may just be fun to replay sometimes!

If a Host loves your module, they may want add another video and call-to-action to the oooh they already hosted using your module.

These secondary videos and CTAs are called Chapters. Currently we offer two ways to add a new chapter in Host Studio (pictured below), and playing another level of your module is one of those options.

This option is controlled by the hasLevels field in the o3hmanifest Every module should set haslevels to true.

If your module supports a limited/finite number of levels, you must include a maxLevels field that indicates the number of supported levels. Otherwise, omit the maxLevels field.

Not sure how your module should be supporting levels? Just ask!

Leaderboards

If your module has a scoring mechanism, then it's fun for players to compare their scores! After players submit their gameplay, they will see their submission in the Community View for your module.

Note that this is separate from but related to our leaderboard guide, which speaks to using our in-module leaderboard library.

Please ask us questions if you are confused about how your module should be utilizing leaderboards!

Quick Reference

For your convenience, here is each field summarized, with a quick note or reference back to the appropriate section in the Setup Guide.