Code

Allow game maker to store project-specific data

Overview

Here is everything needed to use the Content feature in the "Beamable SDK for Unity".

The purpose of this feature is to allow game maker to store project-specific data.

Create, deploy, and update game content without releasing new clients to the app stores.

Content Data Concepts

For simplicity, some Beamable data structures may be omitted from this diagram.

Content Data Types

Content types are must extend Beamable.Common.Content.ContentObject. All derive from Unity's ScriptableObject.

The Beamable SDK for Unity ships with all content types needed for common use cases.

Class Name

Related Feature

Coding Required?

AnnouncementContent

Announcements

No

CalendarContent

--

No

CurrencyContent

Currency

No

EmailContent

Mail

No

EventContent

Events

No

GroupDonationsContent

Groups

No

ItemContent

Inventory

Optional. Game makers may add InventoryBehaviour for custom item behavior

LeaderboardContent

Leaderboard

Optional. Game makers may add custom code for client-authoritative scoring

ListingContent

Store

Optional. Game makers may add custom code for custom listing rendering

SimGameType

Multiplayer

Optional. Game makers may add custom game types

SKUContent

Store

No

StoreContent

Store

No

TournamentContent

Tournaments

No

VipContent

--

No

Adding Content

Game makers may create new content of existing content types or new content of custom content types.

See Content » Guide (Adding Content) for more info.

Examples

Code

📘

Beamable SDK Examples

This and all examples are available for download at GitHub.com/Beamable_SDK_Examples

Here are API highlights for ContentService.

Subscribe

private async void SetupBeamable()
{ 
   var beamableAPI = await Beamable.API.Instance;
      
   // Fetch All  
   beamableAPI.ContentService.Subscribe(clientManifest =>
   {
      Debug.Log($"#1. ContentService, all object count = {clientManifest.entries.Count}");
   });

   // Fetch Filtered 
   beamableAPI.ContentService.Subscribe("items", clientManifest =>
   {
      Debug.Log($"#2. ContentService, filtered 'items' object count = {clientManifest.entries.Count}");
   });
}

Advanced

This section contains any advanced configuration options and workflows.

ContentLink vs ContentRef

Beamable supports 2 methodologies for referencing a content object; ContentLink and ContentRef. Both types need to be resolved before using, but there are key differences.

  • ContentLink - Beamable will perform a First FrameFirst Frame - A first frame operation occurs *very* early in the game project's runtime -- possibly in the very first frame load to resolve the reference
  • ContentRef - Beamable will perform a LazyLazy - A lazy operation occurs on-demand at the last moment possible to satisfy the use case load to resolve the reference

See Content » Guide (Steps) for more info.

📘

Best Practice

These hints make efficent use of concepts and workflows.

  • DO: Use ContentLink in any member variable in your custom content type which references another content type.
  • DON'T: Use ContentRef by default everywhere in your project. This is supported but is considered overkill.

Content Caching

Content is cached by the client and stored both in memory and persisted to disk. When content is updated on our backend, Beamable updates a client manifest and push it to all clients to invalidate and update the cache.

See source code of Runtime/DisruptorEngine/Content/ContentCache.cs for more info.

Content ID

The content ID is assigned at creation, and is composed of content type and content id. A content ID always starts with the content type.

For example, a currency content for dollars would be currency.dollars.

Nesting

Content may be nested too, and the resulting hierarchy will be baked in to the name.

For example, to group "weekend" events under a common folder -- the content ID would be events.weekend.<user-defined-id>.

Content Serialization

Unity's built-in features use Unity's serialization.

However, Beamable's custom content types rely instead on Beamable's custom SerializationSerialization - The automatic process of transforming data structures for read/write storage. This serialization is strict and has limitations.

Supported Types

Unsupported Types

• Unity’s AssetReference
• Unity’s Color
bool
double
enum
float
int
List
long
string
System.Object (and child types)
ContentRef
ContentLink

• Unity’s MonoBehaviour
• Unity’s ScriptableObject
• Etc...

Excluding Fields from Serialization

The [IgnoreContentFieldAttribute] can be applied to any field that you wish to exclude from the Content Serialization process.

[Agnostic]
[ContentType("MyCustomContent")]
public class MyCustomContent : ContentObject 
{
     public string Name;
     public AssetReferenceSprite Icon;

     [IgnoreContentFieldAttribute]
     public Dictionary<string, int> KeyValuePair;

}

Content Validation

Beamable supports optional validation for each field of a ContentObject subclass. This allows game makers to easily build tooling to facilitate team members with their content administration tasks.

See Adding Content Validation for more info.

Storage Location of Content Types

Each content object derives from Unity's ScriptableObject, is an asset file written to disk, and is therefore persistent between sessions.

While all content objects must go in this location, game makers may choose to create custom subfolders within.

Development (Unity Editor)

/Assets/Beamable/Editor/content/

Deployment (On-device)
The development location is not included in the built game project. Instead, when the player loads the game, a fresh copy of all content is retrieved from the Beamable back-end and stored on-device. This allows Beamable to serve dynamic content to the game project. By default, this is a LazyLazy - A lazy operation occurs on-demand at the last moment possible to satisfy the use case loading operation. Each of Beamable's FeatureFeature - An individual aspect of the Beamable product used to create a great user experience prefabs show a loading progress indicator UI automatically.

Content is stored on-device in a within Unity's Application.persistentDataPath.

 Application.persistentDataPath + $"/content/{contentId}.json";

Game Content Designer

Config data, or “Content” as it is called within Beamable, is realm-scoped and can be deployed from either...

Within the context of a CI/CD pipeline, game makers can create jobs that invoke the Content deployment function against data it pulled from source control, and pass in arguments for which realm this Content should go to. This is not theoretical, this is what game makers do today in production.

Content with Microservices

This 'MyCustomContent.cs' snippet includes the [Agnostic] attribute. To make content classes available to your microservices, add the attribute to your content classes.

See Microservices for more info.

[Agnostic]
[ContentType("MyCustomContent")]
public class MyCustomContent : ContentObject { ... }

📘

FAQ

Here are highlights from the Beamable FAQ. See FAQ for more info.

Content


Did this page help you?