Code integration
The RemoteConfigSettings
API is included in the Unity
namespace, which you must include in your game script. For more information on its classes and methods, see the Scripting API documentation.
Implementing custom attributes
To provide custom attributes for Rule conditions, implement the following struct
variables in your game script:
- Use the
Delivery
structure to provide a custom player ID attribute by using theSetCustomUserID
method if your application uses its own tracking method. Remote Config will auto-generate an ID if no developer-defined attribute is available. - Use the
userAttributes
structure to provide custom user-category attributes. - Use the
appAttributes
structure to provide custom app-category attributes.
Note: Custom attributes are entirely optional. You can implement Unity Remote Config without these structs and use the predefined unity attributes for Rule conditions. For more information on attribute categories, see documentation on conditions.
Start by creating a framework for your script that implements your custom attributes and blocks out your functions:
using UnityEngine;
using Unity.RemoteConfig;
public class RemoteConfigExample : MonoBehaviour {
public struct userAttributes {
// Optionally declare variables for any custom user attributes:
public bool expansionFlag;
}
public struct appAttributes {
// Optionally declare variables for any custom app attributes:
public int level;
public int score;
public string appVersion;
}
// Optionally declare a unique assignmentId if you need it for tracking:
public string assignmentId;
// Declare any Settings variables you’ll want to configure remotely:
public int enemyVolume;
public float enemyHealth;
public float enemyDamage;
// ConfigManager.FetchConfigs must be called with the attributes structs (empty or with custom attributes) to initiate the WebRequest.
void Awake () {
// In this example, you will fetch configuration settings on Awake.
}
// Create a function to set your variables to their keyed values:
void ApplyRemoteSettings (ConfigResponse configResponse) {
// You will implement this in the final step.
}
}
Fetching and applying settings at runtime
Next, implement your Remote Config support functions, and call them at runtime to retrieve key-value pairs from the service then map them to the appropriate variables.
The Remote Config service returns a ConfigManager
object to handle fetching and applying your configuration settings at runtime. In this example, you’ll use it to fetch the key-value pairs from the remote service, and invoke your ApplyRemoteSettings
function when the retrieval succeeds. ApplyRemoteSettings
takes a ConfigResponse
struct, which represents the response to a fetch request, and uses the ConfigManager.appConfig
method to apply settings.
// Retrieve and apply the current key-value pairs from the service on Awake:
void Awake () {
// Add a listener to apply settings when successfully retrieved:
ConfigManager.FetchCompleted += ApplyRemoteSettings;
// Set the user’s unique ID:
ConfigManager.SetCustomUserID("some-user-id");
// Set the environment ID:
ConfigManager.SetEnvironmentID("an-env-id");
// Fetch configuration setting from the remote service:
ConfigManager.FetchConfigs<userAttributes, appAttributes>(new userAttributes(), new appAttributes());
}
void ApplyRemoteSettings (ConfigResponse configResponse) {
// Conditionally update settings, depending on the response's origin:
switch (configResponse.requestOrigin) {
case ConfigOrigin.Default:
Debug.Log ("No settings loaded this session; using default values.");
break;
case ConfigOrigin.Cached:
Debug.Log ("No settings loaded this session; using cached values from a previous session.");
break;
case ConfigOrigin.Remote:
Debug.Log ("New settings loaded this session; update values accordingly.");
enemyVolume = ConfigManager.appConfig.GetInt ("enemyVolume");
enemyHealth = ConfigManager.appConfig.GetInt ("enemyHealth");
enemyDamage = ConfigManager.appConfig.GetFloat ("enemyDamage");
assignmentId = ConfigManager.appConfig.assignmentID;
break;
}
}
Other considerations
Utilizing Setting of type Json for overwriting objects
Let's say our code has a class CubeInfo
as follows:
[System.Serializable]
public class CubeInfo
{
public float rotateX = 10f;
public float rotateY = 10f;
public float rotateZ = 10f;
public float rotSpeed = 1.0f;
public Color color = Color.white;
}
The JSON editor modal supports json conversion of following types:
- Text Assets
- Scriptable Objects
- Custom Scripts attached to Game Objects
If we want to use a Text Asset, we setup a setting which structurally matches the CubeInfo
class:
For Scriptable Objects, click on the upper right dot next to selection box, and if you pick a scriptable object, it should be automatically converted to json:
Similarly, if you select your Game Object from the scene, additional dropdown will show for all Monobehavior Custom Scripts attached to that Game Object. The one you select should be converted to json:
Applying those settings to the CubeInfo object in runtime is straightforward, we can use JsonUtility class for that matter:
case ConfigOrigin.Remote:
var jsonCubeString = ConfigManager.appConfig.GetJson("jsonCubeString");
JsonUtility.FromJsonOverwrite(jsonCubeString, CubeInfo);
Custom ID verification
To check that you implemented a request with customUserId
correctly, you can use a utility such as Charles proxy to check the contents of the actual network request messages. Using Charles, you can check your implementation of a Remote Config request with custom user IDs by following these steps:
- In the Editor, open the Remote Config window (Window > Remote Config).
- Open the Charles proxy and clear all events. You can also add "unity" in the filter field.
- In the Unity Editor, click the Play button, then look in Charles for the POST request to
config.uca.cloud.unity3d.com/
. Your custom user ID should be in the request as a value inside the"msg"
key for"type": "analytics.delivery.v1"
.
After the test, close Charles so it won’t interfere with other web requests.
Security
The web service from which Unity downloads Remote Config data is read-only, but not secure. This means third parties could view your Remote Config data. Do not store sensitive or secret information in your configuration settings. Similarly, the saved settings file could be read and modified by end-users (although Remote Config would overwrite any modifications the next time a session starts with an available Internet connection).