Quantum Configs

Introduction

There are a couple of Quantum config files that have specific roles and purposes.

The config files are placed in different folders in the Unity project. Finding them quickly is sometimes annoying. Check out the quick-find toolbar in this post: Unity Window Config Shortcuts

Most of the config files reside inside a Unity "Resources" folder and end up in your app build that way (see DeterministicSessionConfigAsset.Instance for example) while others (RuntimeConfig, RuntimePlayer) can be assembled during run-time.

Quantum Start Sequence

Which config is used by whom and send when is shown in the diagram below.

Config Files

PhotonServerSettings

Assets/Photon Unity Networking/Resources/PhotonServerSettings.asset

Quantum, until version 1.2.4, uses a custom PUN package (PhotonUnityNetworking v1.93) to connect and communicate to the Photon Cloud. This config describes where the client connects to (cloud + region, local ip, ..).

Photon Unity Networking V1 Introduction

Also a valid AppId (referring to an active Quantum plugin) is set here.

How To Create A Quantum AppId

Only one instance of this config file is allowed. The loading is tightly integrated into the PhotonNetwork class. See PhotonNetwork.PhotonServerSettings.

DeterministicConfig

Assets/Quantum/Resouces/DeterministicConfig.asset

Via the DeterministicConfig developers can parameterize internals of the deterministic simulation and plugin (the Quantum server component). Toggle Show Help Info in the inspector of this config for details of each parameter.

The default way only allows one instance of this asset but as long as it is passed into QuantumRunner.StartParameters it does not matter how the file is retrieved.

This config file will be synchronized between all clients of one session. Though each player starts its own simulation locally with his own version of the DeterministicConfig the server will distribute the config file instance of the first player that joined the plugin.

The data on this config is included in the checksum generation.

SimulationConfig

Assets/Resources/DB/Configs/SimulationConfig.asset

This config file holds parameters used in the ECS layer and inside core systems like physics and navigation. See the related system sections in the manual for more details of each value.

The SimulationConfig is part of the Quantum DB and multiple instances of this config are supported. Add the config asset GUID to the RuntimeConfig to select which SimualtionConfig should be used.

Developers can "extend" (create a partial class) the quantum_code/quantum.state/Core/SimulationConfig.cs class and add more data to it.

Delta Time Type

You can customize how the QuantumRunner will accumulate elapsed time to update the Quantum simulation (see the QuantumRunner.DeltaTime property).

• The Default setting will use an internal stopwatch and is the recommended setting for production.
• EngineDeltaTime will use, for example Unity.deltaTime, to track when to trigger simulation updates. This is very handy when debugging the project using break points, because upon resuming the simulation with not fast-forward but continue from the exact time the simulation was paused. Alas, this setting can cause issues with time synchronization when initializing online matches: the time tracking can be inaccurate under load (e.g. level loading) and result in a lot of large extra time syncs request and canceled inputs for a client when starting an online game.

RuntimeConfig

In contrast to the SimulationConfig, which has only static configuration data, the RuntimeConfig holds information that can be different from game to game. By default is defines for example what map to load and the random start seed. It is assembled from scratch each time starting a game.

Developers can add custom data to quantum_code/quantum.state/RuntimeConfig.User.cs (don't forget to fill out the serialization methods).

Like the DeterministicConfig this "file" is distributed to every other client after the first player connected and joined the Quantum plugin.

A convenient way of using this config is by creating a MonoBehaviour that stores an instance of RuntimeConfig (and RuntimePlayer) with default values and asset links (GUIDs) for example pointing to other asset files containing specific balancing data. When the player is inside a game lobby parts of the Runtime configs can be overwritten with his custom load-out before connecting and starting the game. See QuantumRunnerLocalDebug.cs or the sample below:

C#

using Quantum;
using UnityEngine;

public sealed class RuntimeSetup : MonoBehaviour
{
    public static RuntimeSetup  Instance { get; private set; }

    public RuntimeConfig GameConfig { get { return _gameConfig;   } }
    public RuntimePlayer PlayerConfig { get { return _playerConfig; } }

    [SerializeField] private RuntimeConfig _gameConfig;
    [SerializeField] private RuntimePlayer _playerConfig;

    private void Awake() {
        Instance = this;
    }
}

RuntimePlayer

Similar to the RuntimeConfig the RuntimePlayer describes dynamic properties for one player (quantum_code/quantum.state/RuntimePlayer.User.cs).

The data for a player behaves differently to the other configs, because it is send by each player individually after the actual game has been started. See SendPlayerData() executed during the OnGameStarted() callback.

Back to top