Liste de vérification avant le lancement du jeu multijoueur

La liste de vérification suivante décrit une procédure pour exécuter un "dry run" avant lancement aux côtés d'une option pour effectuer un "cut-over", afin d'aider votre jeu à être lancé.

Edgegap recommande que chacune des étapes énumérées soit exécutée avec soin pour vous aider à vous prémunir contre d'éventuels problèmes. Cependant, cela est facultatif et n'est pas une exigence pour utiliser Edgegap.

De plus, toutes les étapes de cette liste ne sont pas nécessaires. Si votre jeu est déjà en ligne et que vous migrez votre trafic depuis une autre plateforme, vous voudrez peut-être examiner la plupart des étapes. Si le jeu n'a pas encore été lancé et le sera bientôt, seule une partie peut être nécessaire. Je suppose que le message est de choisir ce qui convient le mieux à votre cas, mais il n'existe pas de chose telle que "trop préparé".

Avertissement

Utilisation des points de terminaison de l'API Status et Context
Pour assurer la stabilité de la plateforme, nous limitons le taux de votre organisation à 10 demandes par seconde par défaut pour les points de terminaison de l'API Context et Status. Dépasser cette limite renverra l'erreur Trop de demandes 429. Envisagez d'utiliser des variables d'environnement injectées illimitées et des webhooks à la place, chaque fois que cela est possible.

Avant le "Dry-Run" pré-lancement

Deux à trois semaines avant le lancement / patch / événement, assurez-vous que les éléments suivants sont discutés :

Partagez l'architecture et le flux de communication entre votre équipe de développement / backend et Edgegap (c'est-à-dire, diagramme de séquence web)
Fournissez le trafic prévu par joueur (c'est-à-dire sur la base des versions / patches précédents, du budget marketing et d'acquisition des joueurs, des streamers qui seront impliqués, etc.)
Assurez-vous que le jeu fonctionne bien avec la version actuelle et la plateforme d'Edgegap (c'est-à-dire que l'équipe QA utilise le jeu sur Edgegap).
Définissez les KPI et partagez les outils utilisés par les deux parties pour suivre les métriques, c'est-à-dire les statistiques de vapeur, elastic/Prometheus, datadog, etc.
Assurez-vous que la collecte de données sur les indicateurs clés avant le dry run (c'est-à-dire l'utilisation du CPU, le CCU maximal, la durée moyenne des matches, et toute métrique utile pour suivre que tout va bien) sur le serveur de jeu et les services est correctement configurée ou programmée si elle n'est pas actuellement disponible.
Dressez une liste des canaux de communication généralement utilisés par vos joueurs (c'est-à-dire des serveurs discord spécifiques, Reddit, etc.) pour aider à la surveillance des problèmes des joueurs.
Fournissez des détails sur la manière dont vous générez une charge de votre côté. Edgegap a des outils pour générer des déploiements de serveurs de jeu, mais si vous avez des outils internes ou souhaitez impliquer un groupe de joueurs / équipe QA, faites-le nous savoir.
Si possible, veuillez fournir quelques clés de jeu pour que l'équipe Edgegap puisse tester avant / pendant / après l'ensemble de la procédure.
Activez le mode débogage sur les comptes Edgegap (si disponible).
Établissez qui sera le contrôleur des deux côtés (le contrôleur est la personne principale qui gère la communication et donne les ordres ; pensez à un contrôleur d'aéroport).
Notez la liste des étapes nécessaires (des deux côtés) pour migrer de l'état actuel vers le nouvel état. Cela s'appelle une "MÉTHODE DE PROCÉDURE", ou "MOP". (c'est-à-dire lancement, migration depuis une autre plateforme, application d'un patch, etc.) Chaque contrôleur (Edgegap et l'équipe de jeu) devrait avoir la liste à portée de main.
- Pour plus de détails, consultez la section en bas de ce document)
Une restauration est-elle possible ? Si oui, la liste des activités pour revenir en arrière doit être notée pour les deux parties.

Dry-Run

Le dry run est censé être une recréation exacte de la procédure de lancement. Les deux équipes travailleront ensemble, à une date planifiée, et exécuteront la même série d'étapes qui se produiront lors du lancement.

Organisez une webconférence entre les deux équipes
Établissez un point de contact clé de chaque côté (c'est-à-dire le contrôleur)
Ouvrez tous les bons outils, tableaux de bord et éléments de surveillance.
Chaque contrôleur doit passer en revue leur "MOP" avec leur équipe respective, en s'arrêtant au point "go-live"
Recevez un "prêt à avancer" des deux contrôleurs avant de continuer.
Le contrôleur du studio continue à avancer à travers le "MOP", en passant la procédure "go-live" de leur côté (c'est-à-dire migration du trafic depuis un autre fournisseur, lancement du jeu / patch, etc.)
L'outil de test de charge ou l'équipe QA est engagée pour générer du trafic.
Les deux équipes surveillent les métriques, les contrôleurs levant des alertes si quelque chose se produit.
Rollback Go/no-go : si nécessaire, un rollback pourrait être demandé si le lancement n'a pas fonctionné comme prévu.
L'équipe de test de charge / QA est priée de s'arrêter.

Post "Dry Run"

Listez les KPI collectés et évaluez-les.
Listez les éléments critiques qui devraient être corrigés avant le jour du lancement
Les deux contrôleurs mettront à jour leur "MOP" pour traiter tout défaut / élément à surveiller
Listez les éléments souhaitables / non critiques qui devraient être corrigés (après ?) la date de lancement.
Go/no-go pour la date de lancement.

1 Jour (“T-1”) Avant le Lancement

Validez des deux côtés que ce qui est requis pour le lancement est prêt, c'est-à-dire le dernier code source, aucune autre activité pendant le lancement, les bons outils de surveillance activés, etc. Surtout tout ce qui nécessite quelques heures pour être configuré.

1 Heure Avant le Lancement

Commencez les web conférences avec les deux équipes.
Les deux contrôleurs commencent à parcourir leur "MOP".
Suivez les indicateurs clés des deux côtés.

Lancement

Partez sur un accord go/no-go entre les deux contrôleurs.
Les contrôleurs du studio exécutent le "MOP" pour le lancement.
Les deux équipes commencent à surveiller.

1 Heure Après, Post-lancement

Identifiez les bugs/problèmes impactant l'expérience des joueurs qui doivent être corrigés rapidement.
Travaillez sur des correctifs/patches si nécessaire.
Vérifiez les métriques par rapport à avant le lancement (lorsque cela est possible).
Go/no-go pour un rollback si possible.
Communiquez les canaux de support des deux côtés.