Environments and Testing in Game Manager

This guide explains how environments work in Game Manager, how to test your game, and when you need to think about environments at all. For most developers, the answer to that last question is "not yet."

Overview

• New games have two environments: Production and Development.
• Existing games keep their current Open testing and Closed testing environments and also get Development.
• To test a build, you can run it directly in Game Manager. You don't need to configure or release to any environment for this.
• Environments only matter once you want to test your distribution channels (for example, a staging website) separately from production.
• You are never forced to migrate. If your current setup works, it keeps working.

What is an environment?

Environment replaces the term Release Track in Game Manager. Existing API parameter names such as release_track_id remain unchanged.

An environment is a separate, self-contained "universe" for your game. Each environment has:

• Its own distribution channels (where your game is delivered, such as a website, Discord, or CrazyGames).
• Its own releases, so the build live in one environment can differ from the build live in another.
• Its own user base, so players in one environment are separate from players in another (see User accounts and scopes).

Because environments are separate, a change in Development never affects what players see in Production.

Which environments do I have?

Development, Open testing, and Closed testing are configured the same way by default, so there is no practical difference between them unless you set them up differently.

We start new developers with just two environments on purpose. You get a simple setup that works out of the box, and you can add complexity when you actually need it.

Testing your game

Option 1: Run builds in Game Manager (most developers)

If you only need to play and share builds with your team:

1. Upload your build.
2. Run it inside Game Manager.
3. Give teammates the Tester role in Game Manager so they can play the build too, or share the link to the build.

You don't need to create a release, and you don't need to open the Development environment. When you run a build in Game Manager, you choose exactly which build to run, so no release is involved.

Tester permissions

The Tester role lets teammates play builds, view analytics, and inspect crash logs. Testers cannot configure settings, access financial reports, or release builds. See Inviting your team.

For local builds, see Testing Web Builds in Unity. For monetization testing, see Testing Payments and Testing Ads.

Option 2: Use Development to test distribution channels

Use Development when you want to test how your game behaves on a distribution channel, separate from production. A common example is a staging website:

1. Open the Development environment.
2. Add a distribution channel for your staging website.
3. Make a release in Development. This updates the staging site to the build you selected.

For channel configuration and embed URLs, see Distribution Channels & the Smart Playable URL.

Production is untouched. Your production website, Discord, and other live channels keep serving whatever build they were already on.

What a release actually does

A release on an environment means: update every distribution channel in this environment to use this build.

This is true in Production and in every other environment. Two consequences:

• A release in Production updates all your live channels.
• A release in an environment that has no channels has no effect, because there is nowhere to send the build. This is why you don't need to make releases just to test in Game Manager.

Do I need more than one non-production environment?

Possibly, if you maintain several separate test setups. For example, say you have a development website and a separate staging website, and you want to update each one independently. Each should be its own environment with its own distribution channel. If both sat in the same environment, a release would update both at once and you couldn't tell them apart.

Rule of thumb:

• One test website? Use Development and add that channel to it.
• Several test websites, or you need separate user bases for them? Ask us to create additional environments for you.

There is no fixed limit on the number of environments. Today, new environments are created by our team on request. We plan to let you create and remove them yourself in the future.

If you use Open testing and Closed testing

Existing games keep these environments exactly as they are, and nothing about them breaks. A few things to know:

• They are optional. If you only run builds in Game Manager and never use channels in these environments, you likely don't need them.
• Releases to them may be doing nothing. If your CI releases to Open or Closed testing automatically, but those environments have no channels and you share builds by link, those releases have no effect. You can stop making them.
• They are legacy. We won't maintain Open and Closed testing in the documentation going forward, but we won't remove them from your game without talking to you first.
• You can migrate on your own terms. If you'd like to move to the simpler Production and Development model, get in touch. We'll help you move any channels to Development and then remove the environments you no longer need. If you find you do need them, tell us and we'll keep them or set up new ones.

CI and the CLI

Your existing CI setup continues to work. Pushing releases to Open and Closed testing from the CLI is still supported.

We're moving the tooling toward referring to distribution IDs instead of fixed release track names. This means that:

• The CLI and SDK will work with any number of environments, not just two or three.
• You'll be able to find the distribution ID in Game Manager and use it in your pipeline.
• A staging pipeline that releases to a staging website will keep working, because you target the environment that holds that channel.

User accounts and scopes

Behind the scenes, each environment and distribution channel uses a scope, which determines how players are identified and where their data is stored. Scopes are tied to authentication.

You usually don't need to touch them. Game Manager, Discord, CrazyGames, and our other platform distributions each come with their own pre-assigned scope.

Why scopes exist

Suppose your backend issues player IDs as incrementing integers, and you have a production backend and a separate staging backend. Player ID 4 in production is a different person from player ID 4 in staging. If both environments shared one scope, we would treat them as the same player and mix up their data. Separate scopes per environment prevent that.

If you use Pley login (our recommended approach), you can usually share a single scope across channels so that a player has one account everywhere.

What this means when testing in Game Manager

When you run a build in Game Manager, you are in the Development environment, which has its own scope separate from Production.

• New Game Manager accounts: you play as a separate user in Game Manager than in Production. Progress you make in Game Manager does not carry over to Production, and vice versa. If you reach level 10 while testing and then open the live game, you start at level 1.
• Existing Game Manager accounts: to avoid disrupting you, your account keeps its existing behavior. Your Game Manager user and your Production user remain shared, and your progress is unchanged.

If you notice testers on the same game behaving differently (for example, one shares progress with Production and another doesn't), this is the likely reason. Contact us if you'd like your game moved to fully separated users.

FAQ

Do I have to do anything because Development now exists?
No. You can ignore it until you need a separate channel for testing.

Can I keep using Open and Closed testing?
Yes. We'll talk with you before making changes to them.

My CI releases to Closed testing, but my team just shares build links. Should I change anything?
Those releases don't do anything for you. You can stop them, but it isn't required. Contact us and we'll help you confirm and clean up.

Can I have a staging environment?
Yes. Use Development if you have one staging channel, or ask us for additional environments if you need more.

Can I create environments myself?
Not yet. Ask us and we'll create them. Self-service is planned.

Why is my test progress different from my live game progress?
See User accounts and scopes.

Need help?

If you're unsure which setup fits your game, contact the Platforms team. We're happy to look at your workflow and recommend the simplest option that works for you.