This is a checklist to work through before launching your game on SpatialOS. It covers both general best practices and SpatialOS-specific procedures. The checklist aims to be exhaustive to cater for different kinds of launch (such as closed alpha, early access, and public beta), so there may be some items that aren’t relevant to your specific launch.
For guidance on non-technical aspects of launching your game such as marketing, pricing, support agreements, and SLAs, contact your account manager.
Many of the items in this list are things that you need to think about early on when designing your game, such as scale testing and making sure you have cheat detection in place.
Identify expected successful player activity (eg time spent playing, quests completed) and validate that users are achieving this in-game. This will help you predict the load of your game.
Currently, SpatialOS doesn’t provide a native player analytics integration. You can use your own analytics software, or use a third-party service and send analytics events from user code within your workers. We have documentation on integrating third-party services with SpatialOS.
More tightly-coupled integrations and a native solution are on the long-term SpatialOS roadmap - please get in touch if you’d like to know more.
Make sure you have an established procedure for users to send bug reports, including any useful information for debugging (such as stack traces). Also set up an escalation procedure with Improbable, for any bugs or other issues that we need to look into.
SpatialOS doesn’t provide a native bug reporting integration. We recommend using a third-party service or building your own.
Carefully guard access to privileged or private components in your game by considering questions such as:
- does a player have the correct permissions to modify their own inventory?
- do the permissions allow a player to modify another player's inventory?
- do players need an account to log in to a game, or can they get in unauthenticated?
Also check the security of any third-party service integrations you’re using. For example, if they interact with game clients, is the client-service connection properly authenticated?
Make sure core gameplay actions are as resilient as possible to cheating. You can do this through a combination of:
designing with security in mind, such as having validation of movement and shooting
using cheat detection software such as:
SpatialOS collects deployment metrics which you can use to monitor your deployment’s health and status, and to debug when things go wrong. You can access these metrics:
You can also set up alerts on these metrics.
Subscribe to automatic notifications for SpatialOS platform-level issues on the status page. This is our first point of announcement if there’s a problem with SpatialOS.
If you'd like to programmatically check in on the platform status, use this guide.
If you’re using other providers as part of your game (eg for inventory management), subscribe to receive notifications for any issues affecting their services.
Things can go wrong with a live game, and how you respond can have a significant impact on how players perceive your game. Identify who will be available to triage, escalate, or handle production issues with your game.
See our game maintenance and recovery documentation for steps to take when something goes wrong with your game, or you need to do game maintenance.
There are some things you need to set up in advance, before you can follow the steps. Make sure you set these up early on, so that you’re ready for the first time you need to follow the steps.
You might want to change or add to the steps to create a game-specific runbook, or write tools to automate certain steps.
During development, set up continuous integration procedures to make sure there’s always a playable build ready to demo and test.
In production, having a simple, repeatable process for making content and gameplay updates will reduce the impact on players each time you make a change to your game.
To test your emergency procedures, simulate the effects of disaster scenarios (such as natural disasters or cyber attacks) to find out how well-equipped you are to respond, and where you need to prepare more.
Scale testing helps you evaluate the bounds of your game and the systems that support it.
You should start scale testing early in the development process, and do it frequently. For example, you could test new features when they’re going through QA, for 2x your estimate of the best-case number of players on launch weekend.
Make sure critical systems (and tertiary systems, such as third-party inventory systems or analytics tools) are functional.
It’s best to have real players testing the game (rather than automated game clients) because players don’t always behave predictably, and players’ networking and hardware characteristics can be hard to replicate.
For example, there might be a time when all the players congregate in one corner of the game world, and you need to know how this affects the game. You can also make sure your testers are based in different regions, so you can check whether a player’s location has an impact on gameplay.
Share your launch timeline with your team, and also with Improbable, so we can avoid doing any infrastructure maintenance on the clusters you’re using during your launch period.
The timeline should include key events such as when your marketing campaign will go live, and the expected peak number of players (usually the first weekend or two after launch).
You should feature freeze your game several months before your target release date, and have a code freeze of a couple of weeks directly before launch, to allow time to fix any bugs that come out of testing.
Make sure you’ve investigated any limits or quotas associated with SpatialOS or third-party providers, and have adjusted them to cover double the scale of your best-case scenario launch.
Make sure you’ve forecast player numbers for each region, and the corresponding deployment capacity per region. You may also want to pre-pool deployments in each region to minimise player waiting times. Contact us for advice on doing this.
Establish an emergency contact with Improbable.
Well in advance, notify your third-party dependencies of the likely impact of your launch on their service.
This is known as a “canary deployment”, and means you can revert a broken release with minimal player impact.
Alternatively, you could let players access a preview instance of the game, to make sure everything works as expected before you release the game.
Capture what went well and what could have gone better, and take action to make sure the process runs even more smoothly next time.
Updated about a year ago