Dependencies

• A working Game Configs implementation - It's important to have a basic game config set up before integrating it into the dashboard. Take a look at Setting Up Game Configs for a step-by-step guide.
• Working familiarity with runtime options - You need to configure your runtime options to access your Google Sheets credentials. If you're not familiar with runtime options, check out the Working with Runtime Options page.
• Metaplay CLI - This guide uses the Metaplay CLI secrets manager utility. You can get it from Metaplay's GitHub.

Overview

The LiveOps Dashboard provides a comprehensive web-based interface for building, managing, and deploying game configs without requiring access to the Unity editor or local development environment. This is particularly valuable for live game operations where multiple team members need to manage configs, review changes, and coordinate deployments across different environments.

This guide will walk you through setting up your configs to be available to build and publish in the dashboard.

Why Use the Dashboard for Game Configs?

The dashboard enables several key workflows that are essential for operating a live game:

• Remote config builds - Build configs directly on the game server without requiring local Unity setup or development tools. This allows designers, producers, and operations staff to create and test config changes independently.
• Centralized config management - View all config versions in one place, track who built each version, and see the complete history of changes. This provides visibility and accountability for config changes across your team.
• Review before deployment - Build and review configs in a staging environment before publishing them to players. You can inspect the contents, check for errors and warnings, and compare differences against the active config.
• Version comparison - Compare any two config versions side-by-side to understand exactly what changed. This is critical for debugging issues and understanding the impact of config updates.

In short, the dashboard allows for non-technical people to work with game configs without opening Unity.

Configure Dashboard Game Config Builds

If you followed the Setting Up Game Configs guide or otherwise set up some game configs on your own, you should have an existing Google Sheets spreadsheet to source your game configs from. Although you can allow access to the spreadsheet for your client from Unity, that doesn't make it available to the server yet, and consequently, it still can't be accessed by the dashboard.

Adding Google Sheets as a Game Config Source

You can get your SpreadsheetId from the Google Sheets spreadsheet URL, which is formatted as such:

https://docs.google.com/spreadsheets/d/**spreadsheetId**/edit#gid=0

Then, override GameConfigBuildIntegration to tell the SDK where you would like to fetch your configs from:

SharedCode/GameConfigs/MyGameConfigBuildIntegration.cs

public class MyGameConfigBuildIntegration : GameConfigBuildIntegration
{
    // If using a single source in config builds, you can disregard the "sourceProperty" parameter.
    public override IEnumerable<GameConfigBuildSource> GetAvailableGameConfigBuildSources(string sourceProperty)
    {
        return new[]
        {
            // Spreadsheet IDs go here: 
            new GoogleSheetBuildSource("My config sheet", <my-config-sheet-id>),
        };
    }
}

Storing Credentials

If you're using Google Sheets as your config source, you also need to obtain and store your Google Sheets credentials using the Metaplay CLI. You can do this by adding your Google Sheets credentials to your Kubernetes secrets using the Meteplay CLI secrets tool. If you haven't worked with Google Workspace before, check out Google Workspace's documentation on how to set up your account, get credentials and enable the relevant APIs.

If you have your credentials in hand, you can create a new secret using the Metaplay CLI:

$ metaplay secrets create my-environment google-sheets-credentials --from-file=service-account=google-sheets-credentials.json

You can get more information on how to manage secrets and how they work in the Secrets Management page.

Afterwards, refer to the newly added credentials in your runtime options:

Config/Options.base.yaml

GoogleSheets:
  CredentialsPath: "kube-secret://google-sheets-credentials#service-account"

Working with Game Configs in the Dashboard

Once you have configured your credentials, you can manage your active configs and build new ones by navigating to the Game Configs tab on the dashboard.

Viewing All Game Configs

Navigate to the Game Configs page to see all config versions that have been built for your game.

The examples shown above are the configs available in the Idler sample project. See the Idler Sample documentation for more information about this reference implementation. The list view shows:

• Config status - Whether each config is active, archived, or unpublished.
• Build information - Who built the config, when it was built, and the build status (Success, Failed, Building).
• Publication history - When configs were published or unpublished.
• Quick actions - Archive, publish, or view details for each config.

You can have as many unpublished configs as you want, but only one config can be active at any one time.

Automatic Cleanup Alerts

The dashboard will alert you if you have too many unpublished configs (>100) or archived configs (>200) and offer bulk archival or cleanup options. This helps keep your config list manageable.

Building New Configs

Click the New Build button to create a new config build directly on the game server.

The build modal allows you to:

• Name and describe the config - Add a meaningful name and description to help identify this config later. This is especially important for tracking what changed in each version.
• Configure build parameters - Customize which config sources to use, enable partial builds, or configure other build-specific options. The available parameters depend on your game's GameConfigBuildParameters implementation. See Custom Game Config Build Pipelines for details on customizing build parameters.

The build process runs asynchronously on the server. You can navigate away from the page and return later to check the build status. Large projects may take several minutes to build.

Viewing Config Details

Click on any config in the list to view its detailed information.

The detail view is your central hub for understanding everything about a specific config version. At the top, you'll see the config's current status (active, archived, or unpublished) along with when it was built and by whom. The page shows you the build quality with any errors or warnings that occurred during the build process, which is critical because configs with errors cannot be published to players.

You can browse the complete contents of the config to see all the game data it contains, including any A/B test experiments that are defined. This lets you verify that your changes are correct before deploying them. The detail view also provides quick access to common actions like editing the config's name and description, publishing it to make it active, comparing it against other versions, or rebuilding it with updated source data.

Unpublishable Configs

Configs with build errors cannot be published. The detail view will show a prominent alert and highlight the errors in the build log. You must rebuild the config to fix the errors before publishing.

Comparing Config Versions

The Diff to Active button (or the dedicated diff page) allows you to compare two config versions side-by-side.

The diff view lets you select any two successfully built configs and see exactly what changed between them. You can search for specific config items by ID or name, and swap which version is the baseline if you need to reverse the comparison direction. This is essential for verifying your changes before publishing, debugging issues after a deployment, and communicating specific changes to team members for review.

Publishing Configs

Once you've reviewed a config and confirmed it's ready, you can publish it to make it active for all players.

When you publish a config:

• The config becomes the active config that new player sessions will download.
• The dashboard records who published it and when.
• The previous active config is automatically unpublished.
• An audit log entry is created for compliance and tracking.

Gradual Rollout

Publishing a config makes it available immediately, but players only download the new config when they start a new session. This provides a natural gradual rollout as players reconnect to the game. All players will eventually receive the new config without requiring a client update.

You can optionally choose the force disconnect all players to make them download the new config immediately.

Rebuilding Configs

The Rebuild action creates a new config build using the same build parameters as an existing config. This is useful when:

• You've updated your source data (e.g., Google Sheets) and want to rebuild with the same settings.
• You've fixed code issues and want to rebuild a previously failed config.
• You want to create a copy of a config with minor modifications to the build parameters.

The rebuild modal pre-fills the build parameters from the original config, allowing you to modify them if needed.

Managing Config Archives

Over time, you'll accumulate many config versions. The dashboard provides tools to manage this:

• Archive configs - Hide old or unused configs from the main list. Archived configs can still be viewed and unarchived if needed.
• Bulk archival - Archive all unpublished configs at once when you have too many cluttering the list.
• Permanent deletion - Archived configs can be permanently deleted from the system settings page (requires appropriate permissions).

Permissions and Access Control

The dashboard enforces permission-based access control for config operations:

• api.game_config.view - View configs and their contents
• api.game_config.edit - Build new configs, edit config metadata, and archive configs
• api.game_config.publish - Publish configs to make them active
• api.game_config.delete - Permanently delete archived configs

This allows you to grant different levels of access to team members. For example, designers might have view and edit permissions to build and test configs, while only senior staff have publish permissions for production deployments.

Further Reading

• Custom Game Config Build Pipelines - Learn how to customize the config build process and add custom build parameters
• Working with Game Configs - Understand the fundamentals of how game configs work
• Secrets Management - Learn more about securely managing credentials and secrets