Présentation de l'infrastructure de jeu dans le cloud

Last reviewed 2022-01-28 UTC

Cette solution offre une présentation des composants et des modèles de conception courants utilisés pour héberger une infrastructure de jeu sur des plates-formes cloud.

Ces dernières décennies, le secteur du jeu vidéo est devenu une industrie de divertissement florissante. Avec la généralisation de l'Internet haut débit, le jeu en ligne constitue l'un des principaux moteurs de croissance du marché des jeux vidéo.

Le jeu en ligne se présente sous plusieurs formes : les matchs multijoueurs basés sur des sessions, les mondes virtuels massivement multijoueurs et les expériences solo.

Auparavant, les jeux utilisant un modèle client-serveur nécessitaient l'achat et la gestion de serveurs dédiés sur site ou co-localisés pour exécuter l'infrastructure en ligne. Des dépenses que seuls les grands studios et éditeurs pouvaient se permettre. En outre, des projections approfondies et une planification des capacités considérable étaient nécessaires pour répondre à la demande des clients sans dépasser le budget en termes de matériel fixe. Avec les ressources de calcul actuelles basées sur le cloud, les développeurs et les éditeurs de jeux de toutes tailles peuvent demander et recevoir toutes leurs ressources à la demande. Ceci leur permet de réduire les investissements initiaux et d'éviter les risques liés à une mauvaise évaluation du provisionnement du matériel.

Composants de haut niveau

Le schéma suivant illustre la partie en ligne d'une architecture de jeu.

Schéma de l'infrastructure de jeu sur Google Cloud avec composants frontend et backend.

Les composants frontend de l'architecture de jeu incluent les éléments suivants :

  • Des services de plate-forme de jeu offrant des fonctionnalités supplémentaires
  • Des serveurs de jeux dédiés hébergeant le jeu

Les composants backend de l'architecture de jeu incluent les éléments suivants :

  • L'état des jeux, conservé dans le système d'enregistrement et généralement stocké dans la base de données du jeu
  • Une pile analytique, qui stocke et interroge les analyses et les événements relatifs à la jouabilité

Ces composants peuvent être hébergés dans divers environnements : sur site, dans un cloud privé ou public, ou même dans une solution entièrement gérée. Du moment que le système répond à vos exigences en matière de latence pour la communication entre les composants et les utilisateurs finaux, vous pouvez envisager n'importe laquelle de ces solutions.

Frontend

Le frontend fournit des interfaces avec lesquelles les clients peuvent interagir, que ce soit directement ou via une couche d'équilibrage de charge.

Par exemple, dans un jeu de tir à la première personne basé sur des sessions, le frontend inclut généralement un service de mise en correspondance tel que Open Match. Ce service distribue les informations de connexion pour les instances de serveur de jeu dédiées aux clients.

  1. Un client envoie une requête au service de mise en correspondance.
  2. Le service de mise en correspondance attribue au joueur une instance de serveur de jeu dédiée en fonction des critères de correspondance.
  3. Le service de mise en correspondance envoie des informations de connexion au client.
  4. Le client peut alors se connecter directement à l'instance de serveur de jeu dédiée à l'aide du protocole de datagramme utilisateur (UDP).

Les services frontend ne sont pas nécessairement réservés aux clients externes. Il est courant qu'ils communiquent entre eux et avec le backend.

Les services frontend étant disponibles sur Internet, ils sont susceptibles d'être davantage exposés à des attaques. Pensez à renforcer votre service frontend contre les attaques par déni de service et les paquets mal formés afin de résoudre plus facilement ces types de problèmes liés à la sécurité et la fiabilité. En comparaison, les services backend ne sont généralement accessibles qu'à l'aide d'un code de confiance et ils sont donc a priori plus difficiles à attaquer.

Services de plate-forme de jeu

Les noms couramment utilisés pour ce composant sont services de plate-forme ou services en ligne. Les services de plate-forme fournissent des interfaces pour les fonctions essentielles du métajeu, à savoir, autoriser les joueurs à rejoindre la même instance de serveur de jeu dédiée ou maintenir le graphe social "liste d'amis" pour votre jeu. Souvent, c'est la plate-forme sur laquelle le jeu s'exécute, par exemple Steam, Xbox Live ou Google Play Games, qui fournit ces services :

  • Classement et historique des matchs
  • Mise en correspondance
  • Salon en ligne
  • Chat
  • Gestion de l'inventaire
  • Autorisation
  • Partie/groupe
  • Profil
  • Guilde
  • Déverrouillage multiplate-forme
  • Flux
  • Mappage d'identité sociale
  • Analyse
  • Présence

Les services de plate-forme de jeu ont évolué de manière similaire aux services Web :

  • Au début des années 2000, une suite classique de services de plate-forme fonctionnait comme un service monolithique, fréquemment mis en œuvre en tant que singleton. Même fédéré, ce modèle n'est pas recommandé pour les déploiements dans le cloud.

  • Aujourd'hui très répandu, le modèle d'architecture orientée services (SOA) est devenu populaire au milieu des années 2000, lorsque l'industrie a modifié les différents services pour les rendre évolutifs de manière indépendante. En outre, l'accès aux services est devenu possible pour les clients et les serveurs du jeu, mais aussi pour les services Web et les applications pour smartphone.

  • Au cours des cinq dernières années, de nombreux développeurs ont adopté l'approche des microservices, préconisée par les entreprises Web adeptes d'une forte évolutivité. La plupart des problèmes fondamentaux qui se posent avec les services de plate-forme et les applications Web sont similaires. Ils concernent notamment la mise en place de cycles de développement rapides et l'exécution de services hautement distribués dans le monde entier. Les microservices peuvent aider à résoudre ces problèmes et constituent un excellent choix pour la conception d'applications à exécuter sur des plates-formes cloud.

  • En outre, de nombreux services hébergés ou gérés offrent un moyen de créer des services de plate-forme ou des services de plate-forme entièrement gérés.

Services de plate-forme backend

Bien que la plupart des services de plate-forme soient accessibles à des clients externes, il est parfois logique qu'un service de plate-forme ne soit accessible qu'à d'autres parties de votre infrastructure en ligne, par exemple un service de classement des joueurs non exposé. Même si ces services de plate-forme backend ne disposent généralement pas d'une route réseau externe, ni d'une adresse IP, ils suivent les mêmes pratiques de conception que les services de plate-forme frontend.

Ressources de services de plate-forme de jeu Google Cloud

Les ressources suivantes fournissent des informations supplémentaires sur la création de services de plate-forme sur Google Cloud.

Serveur de jeu dédié

Les serveurs de jeu dédiés fournissent la logique de jeu. Pour minimiser la latence perçue par l'utilisateur, les applications de jeu clientes communiquent généralement directement avec les serveurs de jeu dédiés. Ainsi, elles sont intégrées à l'architecture du service frontend.

L'industrie ne propose pas de terminologie standard. Ainsi pour les besoins de cet article :

  • Machine fait référence à la machine physique ou virtuelle sur laquelle les processus du serveur de jeu sont exécutés.
  • Serveur de jeu fait référence au processus de serveur de jeu. Plusieurs processus de serveur de jeu peuvent s'exécuter simultanément sur une même machine.
  • Instance fait référence à un processus unique de serveur de jeu.

Types de serveurs de jeu dédiés

Le terme dédié peut être trompeur pour les serveurs de jeu backend actuels. Dans son contexte d'origine, dédié faisait référence à des serveurs de jeu s'exécutant sur du matériel dédié avec un ratio de 1:1. Aujourd'hui, la plupart des éditeurs de jeux gèrent plusieurs processus de serveur de jeu exécutés simultanément sur une machine. Même si aujourd'hui, ces processus ont rarement des machines entières qui leur sont dédiées, le terme serveur de jeu dédié est encore fréquemment utilisé dans l'industrie du jeu vidéo.

Les serveurs de jeu dédiés sont aussi variés que les types de jeux qu'ils exécutent. Des catégories de serveurs de jeu de haut niveau sont présentées dans la section suivante.

Simulations en temps réel

Pour les jeux de simulation en temps réel, jusqu'à récemment, presque tous les serveurs de jeu dédiés d'un produit commercialisé faisaient partie du frontend. Les serveurs de jeux de simulation en temps réel ont toujours repoussé les limites du scaling vertical. Les jeux les plus exigeants ont adopté des tactiques de scaling horizontal manuel, telles que l'exécution de plusieurs processus de serveur par machine ou la segmentation géographique du monde. La communication UDP, qui offre contrôle de flux personnalisé, fiabilité et réduction de l'encombrement, est le paradigme réseau dominant.

La plupart des serveurs de jeu de simulation en temps réel sont mis en œuvre sous la forme d'une boucle sans fin, l'objectif étant de terminer la boucle dans les limites d'un budget-temps donné. Les budgets-temps classiques sont de 16 ou 33 millisecondes, ce qui donne un taux de mise à jour de l'état de 60 ou 30 fois par seconde, respectivement. Le taux de mise à jour est également appelé fréquence d'images ou fréquence de rafraîchissement. Même si le serveur met à jour sa simulation à une fréquence élevée, il lui arrive de ne communiquer les mises à jour d'état aux clients qu'après la réussite de plusieurs mises à jour. Cela maintient la bande passante requise du réseau à un niveau raisonnable. Les effets d'une mise à jour moins fréquente peuvent être atténués à l'aide de stratégies telles que la compensation des délais de réaction, l'interpolation et l'extrapolation.

En d'autres termes, les serveurs de jeu de simulation en temps réel exécutent des charges de travail sensibles à la latence, qui demandent beaucoup de temps de calcul et de bande passante. Il est donc nécessaire d'examiner attentivement la conception du serveur de jeu et les plates-formes de calcul sur lesquelles il est exécuté. Google Cloud a fondé le projet Open Source Agones pour simplifier l'exécution de serveurs de jeu dédiés sur des clusters Kubernetes tels que Google Kubernetes Engine (GKE).

Jeux basés sur des sessions ou des matchs

Les jeux dans lesquels les serveurs sont conçus pour exécuter des sessions discrètes sont aujourd'hui très courants. Les sessions multijoueurs de jeux de tir à la première personne tels que Call of Duty™, Overwatch™ ou Titanfall™, ou les jeux de combat d'arène en ligne multijoueur (MOBA) tels que Dota 2™ ou League of Legends™ en sont de parfaits exemples. Les serveurs de ces jeux nécessitent une jouabilité très rapide et des calculs détaillés de l'état du jeu, souvent avec des threads consacrés à la simulation de l'IA ou de la physique.

Mondes persistants massivement multijoueurs

Il y a près de vingt ans, Ultima Online™ a ouvert la voie à une véritable explosion de jeux de rôle en ligne massivement multijoueurs (MMO). Les MMO actuels les plus populaires, tels que World of Warcraft™ et Final Fantaxy XIV™, se caractérisent par des conceptions de serveur complexes, dotées d'un ensemble en constante évolution fonctionnalités.

Les serveurs de jeux MMO donnent souvent lieu à des problèmes complexes, tels que le transfert d'entités de jeu entre les instances de serveur, la segmentation ou la mise en phase du monde du jeu et la colocation physique des instances simulant des zones du monde de jeu adjacentes. Les capacités de calcul et de mémoire nécessaires pour calculer les mises à jour de l'état d'un monde persistant contenant des centaines, voire des milliers, de joueurs peuvent mener à des solutions telles que la dilatation du temps, comme avec Eve Online™.

Serveurs basés sur un modèle de requête/réponse

Techniquement, tous les serveurs de jeu dédiés sont basés sur une série de requêtes et de réponses. Toutefois, comme leurs besoins en communication en temps réel ne sont pas critiques, les serveurs de jeux mobiles sont ceux qui ont le plus largement adopté la sémantique de requête et de réponse HTTP, à l'image de celle utilisée dans l'hébergement Web.

Les défis relatifs aux serveurs de jeu basés sur un modèle de requête/réponse sont les mêmes que pour tout service Web, à savoir :

  • Conserver le temps de réponse du serveur de jeu aussi rapide que possible.
  • Distribuer les serveurs de jeu à l'échelle mondiale pour réduire la latence et ajouter de la redondance.
  • Valider les actions du client du jeu sur le serveur pour se protéger contre les failles ou la triche.
  • Renforcer les serveurs de jeu contre le déni de service et d'autres attaques.
  • Mettre en œuvre un délai exponentiel pour les tentatives de communication côté client.
  • Créer des sessions "persistantes" ou externaliser l'état du processus.

Les atouts des serveurs basés sur un modèle de requête/réponse, tels que la sémantique de communication compacte et la facilité de répétition des tentatives après une défaillance d'application ou de réseau, en font des solutions idéales pour les jeux mobiles et les jeux au tour par tour. Nous recommandons que les serveurs de ce type utilisent une API sans serveur sur une plate-forme telle qu'App Engine ou Cloud Run.

Externaliser l'état du monde du jeu

Aujourd'hui, les joueurs s'attendent de plus en plus à ne rencontrer aucune interruption de jeu. En conséquence, vous devez protéger leur expérience des problèmes liés aux instances de serveur individuelles. Pour y parvenir, un jeu doit conserver l'état du joueur en dehors d'un processus de serveur de jeu unique. Les avantages sont nombreux, tels que la résilience face aux processus de serveur en panne et un équilibrage de charge efficace.

Malheureusement, le simple fait d'utiliser des modèles d'état externalisés couramment employés dans les services Web peut poser problème pour plusieurs raisons :

  • La vitesse à laquelle les mises à jour peuvent être écrites dans un état externe peut être problématique lorsque de nombreuses entités uniques effectuent des mises à jour des dizaines de fois par seconde. Ceci est le cas même si vous utilisez des magasins de paires valeur/clé en mémoire cache tels que Memcached ou Redis.
  • La latence finale des requêtes sur les caches d'états externes constitue un problème important. Il est difficile de respecter les délais de mise à jour des états si 1 %, voire même 0,1 %, de vos requêtes a un temps de latence largement supérieur au délai de mise à jour.
  • Déterminer quels processus ont des droits en lecture seule ou en lecture/écriture sur les objets de votre cache d'état externe ajoute à la complexité du modèle de serveur.

La résolution de ces problèmes comprend plusieurs effets secondaires positifs. Un état externalisé disponible pour de nombreux processus avec une gestion des accès appropriée peut considérablement simplifier le calcul de parties de la mise à jour de l'état du jeu en parallèle. Les avantages sont les mêmes pour la migration d'entités entre les instances.

Ressources de serveurs de jeu dédiés Google Cloud

Les articles suivants expliquent comment exécuter des serveurs de jeu dédiés sur Google Cloud.

Backend

Les services backend ne présentent des interfaces qu'à d'autres services frontend et backend. Les clients externes ne peuvent pas communiquer directement avec un service backend. Les services backend vous permettent généralement de stocker les données et d'y accéder. Il s'agit par exemple des données relatives à l'état du jeu dans une base de données ou des événements de journalisation et d'analyse dans un entrepôt de données.

Base de données de jeu

Plusieurs raisons peuvent pousser un joueur à quitter définitivement un jeu, par exemple si les serveurs ne fonctionnent pas ou si le joueur perd sa progression. Malheureusement, ces deux cas de figure peuvent se produire si votre couche de base de données est mal conçue.

La base de données qui contient les données relatives à l'état du monde du jeu et à la progression du joueur peut être considérée comme l'élément le plus critique de l'infrastructure de votre jeu.

Vous devez évaluer la capacité de la base de données à gérer la charge de travail attendue, mais aussi la charge de travail requise si votre jeu rencontre une énorme succès. Un backend conçu et testé pour une base de joueurs estimée, mais qui reçoit soudainement plus de charge que prévu, ne sera pas capable de fonctionner correctement. Si vous ne prévoyez pas les ressources suffisantes en cas de succès, votre jeu sera un échec, car les joueurs auront tendance à l'abandonner s'il devient injouable en raison de problèmes de base de données.

Les jeux sont particulièrement vulnérables à ce problème. La plupart des entreprises dont le produit rencontre le succès peuvent s'attendre à une croissance organique progressive. Or, un jeu classique connaîtra un pic d'intérêt au départ, suivi d'une chute rapide en raison d'une utilisation beaucoup moins importante. Si votre jeu est un succès, une base de données surchargée peut rencontrer des délais importants avant de sauvegarder la progression de l'utilisateur, voire même ne pas l'enregistrer complètement. Se voir contraint de choisir les fonctionnalités du jeu qui ne pourront plus accepter les mises à jour en temps réel est une situation que tout développeur de jeux souhaite éviter. C'est la raison pour laquelle vous devez planifiez soigneusement les ressources de votre base de données.

Lors de la conception d'une base de données de jeux, veuillez prendre en compte les éléments suivants :

  • Prenez une décision réfléchie. N'utilisez pas de base de données durant le développement, car il est facile d'exécuter des tests, puis d'en faire votre base de données de production sans évaluer toutes les options. Il est important de comprendre le type et la fréquence des accès à la base de données depuis votre jeu, d'abord pour votre base de joueurs prévue, puis pour cette base multipliée par 10. Vous pouvez ensuite choisir le backend le plus adapté pour gérer ces scénarios. Évitez d'avoir à apprendre comment gérer une "crise" de base de données au moment où celle-ci survient.
  • Ne vous contentez pas d'une seule solution. Aucune règle ne stipule que vous ne pouvez exécuter qu'un seul type de base de données. De nombreux jeux populaires stockent les informations de compte et traitent les achats intégrés dans le jeu à l'aide d'une base de données relationnelle tout en conservant les informations sur l'état du jeu dans une base de données NoSQL distincte. La base de données NoSQL offre une meilleure gestion des charges de travail à volume élevé et à faible latence, tandis que la base de données relationnelle peut garantir des transactions.
  • Sauvegardez vos données. Les sauvegardes régulières et distribuées géographiquement sont importantes pour la reprise après échec de la base de données.

Bases de données relationnelles

De nombreuses équipes de développement de jeux commencent par une seule base de données relationnelle. Lorsque les données et le trafic augmentent au point que les performances de la base de données ne sont plus acceptables, une première approche courante consiste à procéder au scaling de la base de données. Une fois que le scaling n'est plus possible, de nombreux développeurs mettent en œuvre une couche de service de base de données personnalisée. Dans cette couche, vous pouvez hiérarchiser les requêtes et les résultats du cache, ce qui limite l'accès à la base de données. Avec le scaling et la couche de service de base de données, vous pouvez créer un backend de jeu capable de gérer un nombre immense de joueurs. Toutefois, ces méthodes peuvent présenter des problèmes courants :

  • Scaling : les bases de données relationnelles traditionnelles se concentrent sur une approche de scaling vertical. Toutefois, lors de la planification d'un backend de jeu cloud natif, il est fortement recommandé d'utiliser une approche de scaling horizontal, car le nombre de cœurs pouvant être présents dans une seule VM sera toujours limité, alors que l'ajout de VM à votre projet cloud est assez simple. Les bases de données relationnelles possèdent des modèles pour le scaling horizontal, comme la partition, la mise en clusters et les instances dupliquées par tranches, mais il peut être difficile de les ajouter à une base de données en cours d'exécution sans temps d'arrêt. Si une seule base de données risque de ne pas suffire pour gérer votre trafic ou vos données, commencez par un petit cluster. Mieux vaut éviter d'apprendre à effectuer le scaling d'une base de données en pleine situation de crise. L'ajout de nœuds à un cluster en cours d'exécution représente un défi qui n'est pas insurmontable.
  • Modifications de schéma : très peu de jeux populaires sont lancés avec un schéma de base de données qui reste le même pendant toute la durée de vie du jeu. Les joueurs exigent de nouvelles fonctionnalités et du contenu inédit. Ces ajouts nécessitent la sauvegarde de nouveaux types de données dans la base de données. Au début de votre processus de développement, vous devez déterminer la méthode de mise à jour de votre schéma. Tenter de mettre à jour votre schéma après avoir lancé votre jeu sans processus établi peut entraîner des temps d'arrêt imprévus, voire la perte des données des joueurs.
  • Administration : le scaling d'une base de données relationnelle en cours d'exécution et la mise à jour de son schéma sont des opérations complexes. Les bases de données relationnelles gérées automatiquement sont des services communs aux plates-formes cloud, mais le taux d'adoption de bases de données gérées automatiquement pour les backends de jeu est actuellement faible. Ce phénomène est dû aux charges de travail lourdes en écriture des backends de jeu.

Google propose Spanner, une base de données relationnelle gérée qui peut vous aider à atténuer ces problèmes. Spanner est un service de base de données évolutif à cohérence forte, distribué dans le monde entier et pensé pour les entreprises. Il a été conçu pour le cloud. Il combine les avantages de la structure de base de données relationnelle à l'évolutivité horizontale non relationnelle. De nombreux éditeurs de jeux vidéo considèrent que Spanner est particulièrement adapté pour remplacer à la fois les bases de données d'authentification et d'état de jeu dans les systèmes de production. En ajoutant des nœuds depuis Google Cloud Console, vous pouvez procéder à un scaling afin d'obtenir des performances supplémentaires ou davantage d'espace de stockage. Spanner peut gérer de manière transparente la duplication mondiale avec cohérence forte, ce qui vous évite de gérer des instances dupliquées régionales. Pour plus d'informations, consultez la page Bonnes pratiques pour utiliser Cloud Spanner en tant que base de données de gaming.

Bases de données NoSQL

Les bases de données non relationnelles peuvent être la solution pour les exploitations à grande échelle, en particulier avec des charges de travail lourdes en écriture. Toutefois, elles nécessitent que vous compreniez les modèles de données NoSQL, les modèles d'accès et les garanties transactionnelles.

Il existe de nombreux types de bases de données NoSQL. Les bases de données adaptées pour stocker l'état du monde du jeu présentent les caractéristiques suivantes :

  • Scaling : leur conception est adaptée au scaling horizontal et elles sont souvent utilisées par défaut. En règle générale, le redimensionnement des clusters est une opération pouvant s'effectuer sans interruptions, bien qu'il arrive parfois que les performances diminuent jusqu'à ce que les nœuds supplémentaires soient complètement intégrés.

  • Modifications de schéma : le schéma est dynamique et appliqué par la couche d'application. Il s'agit d'un avantage considérable, permettant par exemple d'ajouter très simplement un champ pour une nouvelle fonctionnalité de jeu.

  • Administration : la plupart des fournisseurs de cloud offrent au moins un moteur de stockage de données NoSQL hébergé ou géré. Google Cloud Platform offre plusieurs options.

Ressources de base de données de jeu Google Cloud

Analyse

L'analyse est devenue un élément important des jeux modernes. Les services en ligne et les clients du jeu peuvent envoyer des événements d'analyse et de télémétrie à un point de collecte commun, où les événements sont stockés dans une base de données. Ils peuvent ensuite être interrogés par tous, à savoir les programmeurs et concepteurs de la jouabilité, les analystes de la veille stratégique et les représentants du service clientèle. Au fur et à mesure que les analyses collectées gagnent en complexité, il est de plus en plus nécessaire de conserver ces événements dans un format pouvant être interrogé facilement et rapidement.

La popularité d'Apache™ Hadoop®, le framework Open Source basé sur les travaux publiés par Google, s'est considérablement accrue au cours de ces dix dernières années. L'extension de l'écosystème Hadoop a augmenté l'utilisation des opérations complexes d'extraction, de transformation et de chargement (ETL) par lots pour formater et insérer des événements d'analyse dans un entrepôt de données. L'utilisation de MapReduce a accéléré la vitesse de publication de résultats exploitables. Cette vitesse accrue a également contribué à la création d'analyses plus gourmandes en ressources de calcul.

Pendant ce temps, les technologies disponibles dans le cloud ont continué d'évoluer. Plusieurs d'entre elles sont disponibles en tant que services gérés. Leur apprentissage est rapide et elles ne nécessitent aucune équipe d'exploitation dédiée. Le dernier paradigme ETL de diffusion en continu de Google offre une approche unifiée du traitement par lots et par flux. Il est disponible à la fois en tant que service cloud géré et en tant que projet Open Source Apache Beam. Les améliorations constantes en matière de tarification du stockage de données dans le cloud permettent désormais de conserver une quantité énorme d'événements de journaux et d'analyse dans d'immenses bases de données cloud gérées qui optimisent la manière dont les données sont écrites et lues. Les moteurs de requête les plus récents pour ces bases de données sont capables d'agréger des To de données en quelques secondes. Pour obtenir un exemple, consultez l'analyse de 50 milliards de pages vues sur Wikipédia en 5 secondes.

Nous vous recommandons de mettre en forme vos données analytiques en ayant une vision axée sur le futur. Lorsque vous choisissez les événements et les métriques que votre jeu écrit dans votre backend d'analyse, tenez compte du format le plus simple à utiliser pour exploiter les données. Bien que vous puissiez utiliser ETL (extraction, transformation et chargement) pour copier les données écrites par votre application dans un format adapté aux requêtes d'analyse, cela peut s'avérer long et coûteux.A lieu de cela, investir dans la conception de votre format de sortie d'analyse peut vous permettre de réaliser des économies considérables et de bénéficier d'informations analytiques en temps réel.

Utiliser le traitement par lot pour les formats existants

Si vous souhaitez analyser des données de métriques dans un format de sortie que vous ne contrôlez pas (par exemple, des données provenant d'une intégration ou d'un service tiers), nous vous recommandons de commencer par enregistrer les données de métriques dans Cloud Storage. Si le format de données est compatible, vous pouvez l'interroger directement à partir de l'interface BigQuery en utilisant les requêtes fédérées BigQuery. Si le format des données n'est pas compatible, vous pouvez utiliser ETL pour copier les données de Cloud Storage à l'aide de Dataflow ou d'autres outils, puis stocker les données formatées dans BigQuery avec des données provenant d'autres sources. Nous vous recommandons de configurer une tâche par lot standard afin de réduire les coûts plutôt que d'utiliser le streaming, sauf si vous avez un besoin urgent de données en temps réel. Pour plus d'informations sur cette approche, consultez la page Optimiser l'ingestion à grande échelle d'événements et de journaux d'analyse.

Prédire les pertes d'utilisateurs et les dépenses grâce à des modèles éprouvés

Vous utilisez peut-être déjà l'une des nombreuses autres fonctionnalités de Firebase pour votre jeu mobile : configuration à distance, messagerie dans l'application ou bibliothèques clientes Firestore, par exemple. Firebase propose également des modèles de machine learning (ML) intégrés pour prédire les pertes d'utilisateur et les dépenses. Vous pouvez intégrer la personnalisation Remote Config pour appliquer le ML à vos données d'analyse et potentiellement créer des segments d'utilisateurs dynamiques basés sur le comportement prédit de vos utilisateurs. Ces données peuvent être utilisées pour déclencher d'autres fonctionnalités Firebase ou être exportées vers BigQuery pour plus de flexibilité. Firebase propose également des clients Unity et C++, et son utilisation ne se limite pas aux jeux mobiles.

Normaliser les données pour l'entraînement d'un modèle personnalisé AutoML Tables

La génération d'un modèle de ML efficace nécessite généralement une vaste expertise en machine learning pour sélectionner les caractéristiques pertinentes et régler les hyperparamètres. Toutefois, le respect des consignes de préparation des données améliore grandement la capacité de ces outils automatisés modernes à gérer ces tâches à votre place et à générer pour vous un modèle utile. Une fois un modèle généré, il peut être hébergé sur Google Cloud afin d'effectuer des prédictions en ligne ou par lot, par exemple pour prédire si un joueur est plus susceptible d'effectuer un achat en jeu ou d'arrêter de jouer.

Bien que les événements d'analyse et les données de joueur soient utiles pour les requêtes d'analyse traditionnelles et les métriques d'informatique décisionnelle, vous avez besoin d'un format différent pour entraîner un modèle de ML. Un cas d'utilisation courant du ML dans les jeux consiste à créer un modèle personnalisé pour prédire à quel moment les joueurs dépenseront de l'argent dans le jeu pour la première fois. AutoML Tables peut vous aider à simplifier le processus d'entraînement. Pour plus d'informations sur AutoML Tables, consultez les pages Préparer les données d'entraînement et Bonnes pratiques pour la création de données d'entraînement.

Plusieurs studios et éditeurs de jeux ont obtenu des résultats en utilisant un format de daily-rollup (cumul quotidien) comme base d'entraînement. Un cumul quotidien est un format de ligne normalisé contenant un champ pour chaque événement d'analyse important. Le format de ligne contient le cumul du nombre de fois où le joueur a déclenché l'événement jusqu'à ce jour. Cette ligne fournit un instantané quotidien de tous les événements potentiellement importants qu'un joueur a déclenchés à ce jour, ainsi qu'une option has made a purchase vrai ou faux.

Le processus décrit dans la documentation de démarrage rapide d'AutoML Tables permet de générer des modèles de haute qualité lors de l'entraînement avec des données mises en forme de cette manière. Vous pouvez ensuite fournir au modèle une ligne de cumul quotidien et fournir des prédictions sur la probabilité que le joueur effectue un achat. Vous pouvez également utiliser des approches similaires pour mettre en forme les données avec différentes options afin d'entraîner les modèles à réaliser différentes prédictions, y compris la perte d'utilisateurs ou d'autres comportements des joueurs. L'investissement initial dans la création de formats de données normalisés peut vous aider à tester rapidement des modèles afin de prédire n'importe quelle action de joueur souhaitée. Cette modélisation peut potentiellement vous aider à monétiser votre jeu ou à hiérarchiser les fonctionnalités qui génèrent des résultats indésirables pour les joueurs.

Solutions d'analyse de jeu Google Cloud

Étapes suivantes

Les solutions pour les jeux en ligne suivent un schéma commun : les clients s'adressent à un frontend de services et à des serveurs de jeu, qui communiquent avec un backend d'analyses et de stockage d'état. Vous pouvez exécuter chacun de ces composants sur site, dans le cloud ou en combinant les deux. Pour des modèles plus détaillés, consultez la section sur les solutions de jeu.

  • Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.