The following checklist outlines is a procedure for executing a pre-launch “dry run” alongside an option to do a “cut-over”, as to help your game go live.

Edgegap recommends that each of the listed step be executed carefully to help you safeguard from any potential issues. However, this is optional and isn’t a requirement to use Edgegap.

Also, not every step in this list are needed though. If your game is already live, and you migrate your traffic from another platform, you may want to review most steps. If the game hasn’t been launched yet and will be soon, only a portion may be needed. I guess the message is to pick and choose what work best for your case, but there’s no such thing as being “too prepared”.

Before Pre-Launch “Dry-Run”

Two to three weeks before the launch/patch/event, make sure the following items are discussed:

• Share architecture and communications flow between your development/backend team and Edgegap (i.e., web sequence diagram)

• Provide forecasted traffic player-wise (i.e. based on previous version/patches, marketing and player acquisition budget, streamers who will be involved etc.)

• Make sure the game runs fine with the current version and Edgegap’s platform (i.e. QA team is using the game on Edgegap.

• List KPIs and share tools used by both parties to track metrics, i.e. steam stats, elastic/Prometheus, datadog, etc.

• Ensure data collection of key metrics before the dry run (i.e. CPU usage, peak CCU, average match duration, and any useful metrics for you to track everything is fine) on the game server and services is properly setup or programmed if not currently available.

• List communication channels typically used by your players (i.e. specific discord servers, Reddit, etc.) to help with player issues monitoring.

• Provide details on how you generate load on your end. Edgegap has tools to generate game server deployments but if you have internal tools or want to involve a group of players/QA team, let us know.

• If possible, please provide a few game keys for Edgegap team to test before/during/after the entire procedure.

• Enable debug mode on Edgegap accounts (if available).

• Establish who will be the controller on both sides (the controller is the main person handling the communication and giving orders; think of it as an airport controller).

• Write down the list of steps needed (on both side) to migrate from the current state to the new one. This called a “METHOD OF PROCEDURE”, or “MOP”. (i.e. launch, migrate from another platform, apply a patch, etc.) Each controller (Edgegap & game team) should have the list handy.

  • For details, see the section at the bottom of this document)

• Is a rollback possible? If so, the list of activities to rollback needs to be written down for both sides.

Dry-Run

The dry run is meant to be an exact recreation of the launch procedure. Both teams will work together, on a planned date, and execute the same series of steps to happen during launch.

• Setup a web conference between both teams

• Establish a key point of contact from each side (i.e. the controller)

• Open all the right tools, dashboards, and monitoring elements.

• Each controller to go through their “MOP” with their respective team, stopping at the “go-live” point

• Get a “ready to go” from both controllers before moving forward.

• Studio’s controller keeps moving through the “MOP”, passing the “go-live” procedure on their end (i.e. migrate traffic from another vendor, launch the game/patch, etc.)

• Load-testing tool, or QA team, is engaged to generate traffic.

• Both teams monitor metrics, controllers raising flags if something happens.

• Go/no-go rollback: if required, a rollback could be requested if the launch did not work as expected.

• Load-test/QA team is asked to stop.

Post “Dry Run”

• List the KPI collected and evaluate them.

• List the critical items which should be fixed before launch day

• Both controllers will update their “MOP” to address any flaw/elements to look for

• List the nice-to-have/not-critical items which should be fixed (after?) the launch date.

• Go/no-go for the launch date.

1 Day (“T-1”) Before Launch

• Validate on both sides that what’s required for the launch is ready, i.e. latest source code, no other activities during the launch, the right monitoring tools enabled, etc. Especially anything which requires a few hours to setup.

1 Hour Before launch

• Start web conferences with both teams.

• Both Controllers start running through their “MOP”.

• Track key metrics from both sides.

Launch

• Agree on go/no-go between both controllers.

• Studio’s controllers execute the “MOP” to go live.

• Both teams start monitoring.

1 Hour After, Post-Launch

• Identify any play experience impacting bugs/problems which need to be fixed quickly.

• Work on fixes/patches if needed.

• Check metrics compared to before launch (when possible).

• Go/no-go for a rollback if possible.

• Communicate support channels on both sides.

1 Day After, Post-launch

• List non-critical changes required.

• Plan/schedule non-critical changes/patches.

• Evaluate ongoing KPI and trends.

And that is the full checklist we recommend for your game studio to prepare ahead of a major milestone.

For more details on how Edgegap handles your game’s traffic in case of an unplanned surge in traffic, the breakdown can be found in this article titled “Managing unplanned traffic surge – how Edgegap’s orchestrator handles scaling for your game”.