SixTwentyDOCS

Project Configuration

How to configure your game's matchmaking, networking, storage, and runtime settings.

Configuring your game

Configure a game from the web console (/console/games — when you create a game or edit an existing one), or programmatically through the control-plane API (PATCH /projects/{projectId}). The console writes to the same API.

Settings fall into two groups:

  • Game settings live on the game itself: allocation mode, player counts, networking, persistent storage, server size, visibility, and the custom container image. Change them at any time in the console or via the update-project API; changes take effect for servers allocated afterward.
  • Build and runtime settings travel with each build: environment variables, dependencies, anticheat, compute options, and game-explorer metadata. Your deploy pipeline supplies these when it publishes a version, so they are described as publish-time settings below.

A minimal update to a game's settings looks like:

curl -X PATCH "https://control-plane.prod.620cloud.com/projects/$PROJECT_ID" \
  -H "X-Auth-Token: $AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "minPlayers": 2, "maxPlayers": 16, "allowPlayerBackfill": false }'

Matchmaking and Game Allocation

Allocation Modes

Choose an allocation mode (allocationMode) when you create or edit a game.

STATIC allocation

  • Your game will be allocated as a set of stateful containers. You can specify an additional property for the maximum number of containers (maxReplicas) and we will automatically provision additional servers based on the actual player load over time, up to that maximum count.
  • In a static mode, players can queue for a specific instance of your game. For example, Clans-1, Clans-2, and so on. Your code should not make any assumptions about the actual number of servers at any given time. If there are no players on Clans-2, we may deallocate that instance until someone re-queues for Clans-2, at which point the server will be re-allocated (with its state restored).
  • We reserve the right to restart containers as needed, but will fire off an event to your game before doing so. For example, if we need to restart Clans-2 to apply a code update that you published, our orchestration server will give your game a grace period to shut down before it is automatically restarted. This will be very similar to a SIGTERM and SIGKILL lifecycle in a process -- the game gets a warning first, giving it a chance to gracefully handle a shutdown, and then it is forcefully shut down at some point in the future. Our systems will make a best-effort attempt to avoid restarting instances with active players, and we will work on exposing the grace period as a parameter to you. We are still figuring out the best way to handle this case, but want for you to plan in advance for it.

DYNAMIC allocation

  • Your game will be allocated on-demand in response to matchmaking and queuing events. For example, if your game requires four players to begin, and eight players enter the queue, two instances of the game will be created automatically by our matchmaking and orchestration systems behind the scenes. These players are also transferred automatically once your game enters a healthy state as per our SDK lifecycle management.
  • In a dynamic mode, players queue for your game mode itself, and are allocated to game instances as they become available. For example, players may queue for SSM and end up being assigned to any number of different servers, as per our orchestration logic.
  • Your game must interact with our lifecycle SDK to indicate when it is safe or unsafe to shut down the game. This is usually between minigame iterations. Our systems make a best-effort attempt to keep the container alive, and may add more players during this time (it's like a game lobby window). However, in some cases (such as if insufficient players are in the game mode), the container may be shut down. Once again, we will deliver a shutdown event and a grace period in case you want to re-queue players for another mode or lobby before the container is killed. Otherwise, players are sent back to the SixTwenty hub.

Backfill

Backfill allows queued players to join instances of your game that are already running (specifically, those that are in the IN_GAME state). For example, if there is an instance of your game that is currently in the IN_GAME state with two players, and there are four remaining slots, then the next four players to queue for the game mode will be backfilled into the existing game instance.

Backfill is controlled by the allowPlayerBackfill setting when you create or edit your game.

Spectator Mode

Spectator mode allows players to join instances of your game that are already running, even if those games are full. Spectators can join a game even if it does not enable backfill and is in the IN_GAME state. Unlike backfill players, spectators are not automatically allocated whenever players queue for the game -- they must specifically request to join as spectators via a special command.

Spectator mode is controlled by the allowSpectatorMode setting when you create or edit your game; when it is not set, it defaults to false.

When spectator mode is enabled, your game must safely handle cases when the number of players on the server exceeds the maximum player count specified in the matchmaking configuration. For example, you can kick or re-queue excess players at the end of a game cycle if your game cannot accommodate them in the next round.

Dependencies

Note

This feature requires an Organization subscription, individual subscriptions cannot use this feature!.

SixTwenty has partnered with a number of leading plugin authors to support unique and innovative game experiences within the Studio. These plugins are enabled per published version — your deploy pipeline includes the library list when it publishes a build.

Some of the values that are currently supported are:

  • MYTHIC_MOBS: This plugin allows you to create custom mobs with unique abilities and behaviors.
  • MODEL_ENGINE: This plugin allows you to create custom models for mobs, items, and blocks.
  • MYTHIC_DUNGEONS: This plugin allows you to create custom dungeons with unique mobs, loot, and mechanics.
  • MYTHIC_CRUCIBLE: This plugin allows you to create custom PvP arenas with unique mechanics and objectives.
  • PROTOCOLLIB: This plugin allows you to intercept and modify network packets.
  • LIBSDISGUISES: This plugin allows you to disguise entities.
  • DECENTHOLOGRAMS: This plugin allows you to create custom holograms.

Game Explorer Configuration

Players can find your game from the SixTwenty Lobby using the compass icon and navigation menu. The game explorer shows a set of attributes that describe your game, supplied with each published version:

  • displayName: (string) the name of your game as shown to players in the game explorer menu. Unlike the project name (which is used internally), this name can contain spaces and special characters.
  • visibility: (HIDDEN, PLAYTEST, or PUBLIC) determines if your game is visible to players in the staging game explorer menu. Most games that are actively being developed and iteratively released (they are not in an initial draft stage) should be set to PLAYTEST. This setting only impacts the staging environment, as all approved and published games are visible in production.
  • description: (string[]) a brief description of your game, separated into lines.
  • iconItem: (string) the item that represents your game in the game explorer menu. This should be a valid Minecraft item ID, such as minecraft:diamond_sword.
  • iconURL: (string) a URL to an image that represents your game in the game explorer menu. This is only visible in Bedrock clients.
  • category: (string) the category that your game falls under in the game explorer menu. Examples include Survival, PvP, and Parkour.
  • tags: (string[]) a list of tags that describe your game. These can describe categories, but can also describe attributes of the game such as Team, Sandbox, and so on.
  • playtestPlayerIds: (string[]) a list of player UUIDs that are allowed to playtest your game on the staging network. This is useful for sharing your game with a select group of players before it is published to the SixTwenty network.

Specialized Tags

Below is a list of specialized tags that you can apply to your game when you publish a version, which can affect your game when published.

  • Arcade - Your game will be shown and playable via the Mixed Arcade system. Note that there are additional requirements you must meet to use this tag that can be found here

Persistent Storage

Persistent storage attaches a durable network file system to each of your game servers, so data written by a server survives restarts and re-allocation. You can enable it and choose a size directly from the web console when you create a game or later edit it (no support request required).

  • Each named server gets its own independent volume — for example, Game-1 and Game-2 have separate file stores, but the file system within each persists across restarts and re-allocation.
  • The file system is always mounted at the /data directory inside your container.
  • Persistent storage is only available for games that use the STATIC or FIXED allocation mode (the modes with stable, named servers). It cannot be enabled for DYNAMIC games.
  • You can set the volume size (in GiB) when enabling it; the default is 15 GiB. Sizes up to 100 GiB are self-service — if you need a larger volume, reach out to our support team.
  • Changing the size affects newly created volumes only; volumes that already exist are not resized.

Advanced Configuration and Overrides

There are a set of internal overrides that can be applied to your project by the SixTwenty team. These unlock advanced or non-standard functionality, which is generally available, but not exposed in the standard game settings. We currently support:

  • Health check modifications
    • Changing the default health check wait time after server initialization. This may be useful if your games take a long time to start up, and you want to avoid the health check failing prematurely.
    • Changing the default health check interval. This may be useful if your game may be expected to ignore the Health SDK or not respond to it in a timely manner.

If you are interested in enabling these features, please reach out to us via a support request.

Environment Variables

Environment variables are injected into your game server's runtime environment. They are applied when your deploy pipeline publishes a version, supplied as key-value pairs in the publish step:

"environmentVariables": {
  "LOG_LEVEL": "debug",
  "FEATURE_FLAG": "true"
}

Secret Environment Variables

For sensitive values, mark them as secret environment variables. Secret values are stored as Kubernetes secrets and injected into your server's environment, rather than kept in plain configuration. Populate them from your CI secret store — for example, add them as GitHub repository secrets and pass them through your GitHub Actions workflow when it publishes a version.

Compute Settings: Internet Access & OpenTelemetry

These runtime options are applied when you publish a version:

  • enableInternetAccess: Grants your game server outbound internet access. Required for features that need to connect to external services. Note: Enabling internet access may have security implications and requires additional review for production publishing.
  • enableOpenTelemetryAgent: Enables the OpenTelemetry Java agent for distributed tracing and observability. Not compatible with the POLAR anticheat. See OpenTelemetry Java Agent for more info.

POLAR Anticheat Requirements

If you enable the POLAR anticheat for a published version, you must meet these requirements:

  • your dependency libraries must include PROTOCOLLIB
  • enableInternetAccess must be true
  • enableOpenTelemetryAgent must NOT be true

If these requirements are not met, your configuration will be rejected with a validation error.