Remote Config

Remote config lets you control values and feature flags from the server, so you can tune your game, gate features, and run experiments without a client update.

Scope: remote config is defined per game version; overrides per segment and per player reach a game’s reads once the player signs in.

Dashboard
Unity
Unreal

Manage config values and feature flags for a game version in the dashboard, and override them for a segment or a single player. An override reaches a game once the player signs in: the SDK then reads the config for the signed-in player.

Remote config and feature flags — Manage remote config values and feature flags in the dashboard.

Open the Code Generation tab of Flock → Settings and click Sync Schemas to turn each config into a typed C# class. The example assumes a config named Gameplay with the fields max_lives, spawn_rate and welcome_text, and runs inside an async method:

using Flock;
using Flock.Generated.Configs;

GameplayConfig gameplay = await FlockClient.Instance.Config.GetGameplayAsync();
float spawnRate = gameplay.SpawnRate;
int maxLives = gameplay.MaxLives;

The accessor name comes from your config (Gameplay → GetGameplayAsync) and exists only after Sync Schemas. Fetch at startup and read values instead of hardcoding them.Values resolve patch-first: where a patch applies to the running game version you get the patched value, otherwise the config’s own — your code never learns which.For the signed-in player. With a player signed in, a read returns the values the server resolves for that player: for a gameplay or feature config, the newest patch, then the overrides of the segments the player is in, then the player’s own overrides (other kinds of config have no overrides and read as they do with nobody signed in). With nobody signed in, it returns the game-wide values. Once the server answers, the player’s values are held for that sign-in, so a game that reads a config before the player signs in (on a title screen, say) reads it again once they have, for example in a FlockEvents.OnAuthenticated handler. When the player’s read gets no answer, the read returns the player’s saved values, else the game-wide ones, and asks for the player’s again on a read 30 seconds or more later.The server resolves a player’s values for the Game Version the build sends, else the one the player last signed in with. Only when it has neither (the build sends none, as no Game Version is resolved in Flock → Settings, and none is recorded for the player) does the read return the game-wide values, with one warning in the Console for the sign-in. Resolve the Game Version in Flock → Settings → Configuration, and the player gets their own values from their next signed-in read.With the offline cache on (Flock → Settings → Advanced Settings, Offline Cache), config reads are kept on disk and served from there when the server is unreachable, per player: a returning player gets their own last values offline, never another player’s, and a player whose values were never read online gets the game-wide ones. The cache needs one successful online read to fill, and a refusal saying the player or the config is not found, or that there is no Game Version to read, deletes that player’s saved copy.

Code generation is the intended path here, not a convenience. The generated typed accessors are the public API; without a sync, GetByConfigIdAsync<T>(configId) reads a config by its id into a class of your own.

Flock Resolve Config Data returns the effective values for the running game version — the patch where one applies, the config’s own data otherwise. Your graph never learns which happened.

#include "FlockSubsystem.h"

UFlockSubsystem* Sdk = UFlockSubsystem::Get(this);   // this: any object in the game's world

// The config's Id comes from its name, as the dashboard shows it.
const TWeakObjectPtr<UFlockSubsystem> Flock = Sdk;
Sdk->GetConfigProvider()->GetConfigByName(TEXT("difficulty"), [Flock](TFlockResult<FFlockGameConfigSchema> Config)
{
    if (!Config.bSuccess || !Flock.IsValid())
    {
        return;
    }
    Flock->GetConfigProvider()->ResolveConfigData(Config.Value.Id, [](TFlockResult<FFlockStructuredData> Data)
    {
        int32 Enemies = 5;   // your own default, kept when the read fails or the value is missing
        if (Data.bSuccess)
        {
            Data.Value.TryGetInt(TEXT("enemies.count"), Enemies);
        }
    });
});

A config is resolved by its Id, which GetConfigByName (Flock Get Config By Name) reads from the name the dashboard shows. Read a value by its dotted path, keeping your own default when it is missing: in Blueprint, Get Data Int, Get Data Float, Get Data String and Get Data Bool each take a path and a fallback.

A Load Difficulty custom event, Flock Get Config By Name for difficulty, Flock Resolve Config Data with its Id, then Get Data Int for enemies.count with fallback 5 into Print String — Read the difficulty config by its name, resolve it, and read one value with a fallback.

After a schema sync it is one node handing back a typed struct:

A generated Get Gameplay macro node feeding a Break node — Get Gameplay fetches, resolves, and returns a typed struct — break it for real pins.

For the signed-in player. With a player signed in, Flock Resolve Config Data (and the generated Get nodes, which call it) returns the values the server resolves for that player: for a gameplay or feature config, the newest patch, then the overrides of the segments the player is in, then the player’s own overrides (other kinds of config have no overrides and read as they do with nobody signed in). With nobody signed in, it returns the game-wide values. Once the server answers, the player’s values are held for that sign-in, so a game that reads a config before the player signs in (on a title screen, say) reads it again once they have: bind On Authenticated on the event hub and resolve the config again there. When the player’s read is refused (the server knows no such player, has no Game Version to read, or no config of that name), the game-wide values answer for the rest of the sign-in; when it gets no answer, the player’s saved values answer, else the game-wide ones, and the player’s read is sent again on a read 30 seconds or more later.When the server got no Game Version with the request, the read returns the game-wide values and the Output Log shows one warning for the sign-in, with the fix: resolve the Game Version (Tools → Flock → Resolve Game Version, or Project Settings → Plugins → Flock SDK Settings).Config reads are cached and served from disk when the server is unreachable, per player: a returning player gets their own last values offline, never another player’s, and a player whose values were never read online gets the game-wide ones.

Patterns

Feature flags — ship code dark, then enable it for everyone, or for a segment.
Tuning — adjust drop rates, prices, or difficulty live.
Experiments — serve variants to different segments and compare with analytics.

Always provide safe client-side defaults so your game stays playable if a config fetch fails.

Getting Started

Concepts

Features

Reference

Patterns

​Patterns

Patterns