Skip to main content

Realm Instance Config

Each Realm has it's own Realm Instance Config. Redwood comes preconfigured with the default realm found in RedwoodBackend/config/node/default/realm/instances/default.yaml. You can define more realms by simply by defining a <realm-key>.yaml file in a realm/instances folder. You don't need to add this to the default config environment; you can specify it directly in your own custom config environment. Don't want the included default realm? Just override the deployed flag in a realm/instances/default.yaml file in your custom config environment.

note

While it won't break anything if you do, we've tried to keep the configuration flexible enough so that you shouldn't need to modified any config files distributed in the official Redwood Backend Git repository. You can introduce completely new variables in your own config environment.

Basic Details​

  • key is a string that Redwood uses as the identifier for the Realm. This should be the same name as the config file/folder for the Realm Instance Config (i.e. default.yaml has a key: "default").
  • name is the human-friendly string that should be used to show to the player.
  • deployed is a boolean determining whether or not that Realm Instance Config should deploy the associated realm services; set this to false to disable a realm completely.
  • listed is a boolean that determines whether or not the Director should list this realm in the realms.list API call.
  • image-tag is the Docker image tag that Kubernetes should use for the realm services (except for game server images).
  • auth.id and auth.secret should be ignored in the YAML config file for studio-hosted realms; these are generated by the deployment scripts.

Kubernetes Cluster​

The k8s config variables determine how the realm is deployed to the cluster. The k8s.id corresponds with the associated Kubernetes instance id as to which cluster to deploy to. k8s.namespace determines the namespace the services should be deployed to; we recommend keeping this as realm-${../key} for simplicity, but it can be anything you'd like.

Persistence​

The persistence.database config variables define the PostgreSQL details for both runtime-access (how the NodeJS services access the database, this could be an internal Kubernetes service [see RedwoodBackend/config/node/kubernetes/realm/instances/default.yaml for an example] or a private network details for your managed database) and deployment-access (how the deployment scripts get access, usually a public endpoint).

Backend and Frontend​

The backend and frontend config variables define how many replicas to scale the services, what debug-port to use if you need to debug the services, and internal/external connection details.

The backend.connection.external variables are used for how the game server Sidecar service communicates with the Realm. This can be a Kubernetes service host if you're using Agones servers in the same cluster, but otherwise there needs to be a publicly available hostname.

The frontend.connection.external variables are used for the game client to connect to the realm and needs to be a publicly available hostname during public testing.

During development, you'll see that both of the external host variables are set to realm-${../../../key}.localhost for the default realm, which would resolve to realm-default.localhost, which we add to our C:\Windows\System32\drivers\etc\hosts file to resolve. Read more about configuring this in Deploying to a local Kubernetes cluster.

Game Servers​

The game-servers config variables define several behaviors related to the Unreal game server. Most of the relevant documentation can be found in the game server provider documentation.

Ticketing​

The ticketing config variables define several behaviors related to the Unreal game server. Most of the relevant documentation can be found in the ticketing provider documentation.