Ce document décrit les bonnes pratiques pour exécuter un backend de jeu mobile basé sur des API sur Google Cloud. Ce document fournit une référence que les développeurs de jeux peuvent utiliser comme point de départ pour concevoir une architecture en ligne pour les jeux mobiles. Les bonnes pratiques décrites dans ce document peuvent s'appliquer à tout type de jeu mobile. Toutefois, ce document se concentre sur les jeux qui stockent les informations de progression et d'accès au compte dans une base de données, et qui accèdent à ces données via une API d'interface personnalisée écrite par les développeurs du jeu.
Ce document est destiné aux équipes qui développent des jeux vidéo mobiles similaires à Pokemon Go de Niantic, Super Mario Run de Nintendo ou encore Candy Crush Saga de King. Les bonnes pratiques décrites dans ce document ne sont pas destinées aux jeux de hasard (jeux de carte et de casino), ni aux applications de ligue sportive imaginaire (par exemple, le "Fantasy Football"), qui évoluent le plus souvent comme des applications Web classiques ou des applications sociales.
La nature du jeu peut générer des pics de demande pendant les heures de pointe. Votre application pouvant être mise en avant par une plateforme de téléchargement d'applications ou subitement plébiscitée par la communauté des streamers, il est important d'envisager les scénarios de succès important ou de sinistre majeur afin de vous assurer de disposer d'un plan d'action clair pour passer à la vitesse supérieure si le jeu devient populaire. Prendre des décisions éclairées lors du développement peut contribuer à réduire les risques.
Estimer la charge utilisateur prévue
Lorsque vous concevez le backend en ligne de votre jeu mobile, il est important d'estimer aussi bien que possible la charge utilisateur prévue. Si vous concevez votre architecture pour qu'elle utilise la majeure partie de ses ressources lorsque cette charge utilisateur prévue est atteinte, elle risque de ne pas pouvoir évoluer et répondre à la demande si elle attire soudainement l'attention d'une grande communauté de joueurs. Une architecture qui ne parvient pas à évoluer constitue un risque de perte d'opportunités de revenus et peut potentiellement entacher la réputation de votre studio. Il peut s'avérer difficile de concevoir une architecture qui fonctionne bien à la charge attendue tout en ayant un plan d'action clair pour la faire évoluer en cas de succès inattendu.
Bien que les estimations de charge utilisateur soient toujours basées sur de nombreux éléments de données, deux catégories doivent systématiquement être incluses :
- Nombre de joueurs et fréquence des sessions de jeu : il s'agit généralement d'une estimation basée sur le nombre de joueurs qui jouent à des jeux similaires sur le marché et sur votre budget marketing pour l'acquisition d'utilisateurs.
- Charge API causée par chaque joueur : elle peut être mesurée via des tests de charge complets.
Faire une estimation initiale
Pour réaliser une estimation initiale, tenez compte de tous les facteurs disponibles, par exemple ceux ci-dessous :
- Le succès de vos jeux passés ou de jeux similaires sur le marché
- La popularité des éléments de propriété intellectuelle inclus
- La ériode de mise sur le marché
- Le nombre de préinscriptions ou de promotions croisées dans le reste de votre portefeuille d'applications
- Budget marketing
Une fois que vous avez estimé le nombre d'utilisateurs, l'usage est généralement de créer un scénario optimal avec quatre fois plus d'utilisateurs que l'estimation. Toutefois, nous vous recommandons d'envisager un scénario "catastrophe" dans lequel un jeu devient viral ou a un succès inattendu. Certains studios multiplient leur estimation de nombre d'utilisateurs par 10, mais nous avons pu constater des estimations multipliées par 20 voire même par 40 dans des circonstances extrêmes pour certaines sorties passées sur Google Cloud. Même si ces chiffres sont très peu probables, il est utile de les prendre en compte pour vérifier que votre architecture est capable d'évoluer pour répondre à une telle demande.
Réaliser un test de charge
Connaître le nombre attendu d'utilisateurs ne suffit pas à comprendre les besoins de scaling de votre jeu mobile. Il est essentiel d'exécuter des tests de charge avec des conditions aussi proches que possible des circonstances réelles. Un test de charge doit être exécuté avec des testeurs en bêta fermée et en utilisant une version presque finale du jeu. Les tests de charge vous permettent de profiler les performances de la base de données de stockage d'état et de la couche d'API afin de vous assurer de disposer d'une marge de capacité suffisante. Les utilisateurs réels créent souvent des modèles d'utilisation que les développeurs ne peuvent pas anticiper. Par conséquent, il est important de profiler l'utilisation de véritables joueurs afin d'utiliser ces données comme modèle pour les tests de charge à grande échelle. Nous vous recommandons d'utiliser un framework de test de charge pour répliquer les modèles utilisateur de la bêta à l'échelle déterminée grâce à l'estimation initiale réalisée dans la section précédente.
Lorsque vous exécutez un test de charge à grande échelle, contactez votre équipe commerciale Google Cloud et soumettez une demande appropriée au service client Cloud pour la période pendant laquelle vous prévoyez d'effectuer un test de contrainte. L'envoi d'une demande d'assistance client permet à l'équipe de vous aider à demander des augmentations de quotas de manière proactive, si nécessaire. Elle permet également de s'assurer qu'un ingénieur du service client est disponible pour répondre à vos questions si un produit Google Cloud ne se comporte pas comme prévu.
Valider par rapport à l'architecture de référence
Le schéma suivant fournit une architecture de référence pour les bonnes pratiques du présent document :
Dans le schéma précédent, vos clients de jeu se connectent à votre backend de jeu mobile via un équilibreur de charge. Le backend dispose d'une connexion directe à votre base de données d'enregistrements de joueurs, avec une couche de cache haut débit facultative qui stocke et récupère la progression, les droits d'accès et d'autres données concernant les joueurs. Le backend émet des métriques d'opérations et crée des journaux dans Google Cloud Observability. Les métriques et les journaux sont essentiels pour surveiller les performances de votre backend et sont également accessibles à votre entrepôt de données. Les spécialistes de l'analytique peuvent accéder directement à l'entrepôt de données à l'aide de BigQuery et AutoML peut être utilisé pour générer des modèles permettant de prédire les dépenses et les pertes d'utilisateurs. Ces prédictions peuvent ensuite être mises à disposition du backend de jeu. Les composants suivants sont décrits en détail dans la suite du présent document :
- Puissance de calcul utilisée pour les API destinées aux clients
- Base de données utilisée pour le stockage d'état
- Observabilité et surveillance avec Google Cloud Observability
- Analyse
Certains jeux mobiles proposent un mode multijoueur en temps réel qui utilise un serveur de jeu dédié ou des serveurs de type TURN/STUN. Bien qu'elles n'incluent pas explicitement ce type de serveur, les bonnes pratiques décrites dans le présent document sont compatibles avec les serveurs de jeu.
Options de calcul
Pour votre backend de jeu mobile Google Cloud propose plusieurs solutions allant des options évolutives entièrement gérées comme App Engine en passant par des environnements entièrement personnalisables comme Google Kubernetes Engine (GKE). Il est important de bien identifier et comprendre vos besoins afin de faire un choix éclairé. Toutes les options des sections suivantes offrent une intégration complète avec Cloud Load Balancing afin que votre trafic HTTP(S) puisse bénéficier d'un scaling fluide. Les options incluent également des fonctionnalités Google Cloud Armor, telles que la protection DDoS de niveau professionnel.
Utiliser App Engine pour une architecture sans serveur évolutive et éprouvée
App Engine est la plateforme sans serveur entièrement gérée de Google Cloud qui vous permet de vous concentrer sur l'écriture du code sans avoir à gérer l'infrastructure sous-jacente. Vous pouvez configurer App Engine pour évoluer en fonction des besoins de votre jeu. Cela permet également de réduire les temps d'itération pour vos développeurs qui peuvent créer et déployer directement depuis la source avec une seule commande. App Engine est un choix idéal pour les équipes de petite taille ou qui ont une expérience limitée des opérations de mise à l'échelle d'infrastructure. L'efficacité de cette solution a été démontrée à grande échelle grâce à plusieurs lancements de jeux mobiles dont des jeux Nintendo, Madfinger Games, Pocket Gems et Backflip Studios.
Pour déterminer si App Engine est le bon choix pour votre jeu, il est important de comprendre que les instances peuvent être démarrées ou arrêtées en fonction du taux de requêtes des joueurs. Par conséquent, les conceptions de services ne doivent pas prévoir de conserver un état en mémoire entre les requêtes des utilisateurs. Pour conserver un état en mémoire entre des requêtes, vous devez stocker et récupérer cet état dans une base de données de stockage d'état (décrite dans la section suivante) ou utiliser un cache distinct comme Memorystore (Memcached ou Redis).
Les applications App Engine peuvent nécessiter du temps ou des ressources supplémentaires pour fonctionner efficacement dans d'autres environnements d'exécution. Si vous avez besoin d'une seule cible d'exécution pouvant être déployée dans des environnements cloud hybrides ou dans des environnements multi-cloud, nous vous recommandons plutôt d'utiliser Cloud Run ou Google Kubernetes Engine.
Utiliser Cloud Run pour vos nouvelles applications sans serveur
Cloud Run vous permet de développer une nouvelle application en conteneurs pour votre backend de jeu sans avoir à gérer les clusters Kubernetes. Cloud Run peut adapter automatiquement vos conteneurs d'API afin de répondre aux besoins de votre base de joueurs. Cette solution offre de nombreux avantages similaires à App Engine, à savoir un environnement d'exécution entièrement géré dans lequel l'infrastructure est abstraite et l'évolutivité est gérée automatiquement en fonction de la configuration sélectionnée. Cette solution étant basée sur le standard Open Source Knative, il peut s'avérer plus simple d'écrire des services portables avec Cloud Run. Les applications Cloud Run s'exécutant dans des conteneurs Kubernetes, la procédure pour passer à Kubernetes autogéré est relativement simple si vous avez besoin de davantage de contrôle dans le futur.
Utiliser GKE pour contrôler entièrement votre charge de travail
Google Kubernetes Engine est une option pour les développeurs qui ont besoin de davantage de contrôle ou qui travaillent avec des équipes en charge des opérations particulièrement expérimentées. Si vos équipes utilisent déjà Kubernetes pour leurs piles d'applications, GKE leur permet d'exécuter leur backend de jeu avec leurs services existants en utilisant la même interface Kubernetes et la même interface de ligne de commande (CLI). Si vos équipes souhaitent exécuter des applications sur plusieurs clouds ou sur site, GKE fournit une plateforme à cible unique pour les applications conçues pour le cloud (applications cloud natives). De nombreux jeux ont été lancés à grande échelle sur GKE, y compris Pokémon GO.
Bases de données de stockage d'état
Lorsque vous choisissez une base de données pour votre jeu mobile, vous devez réfléchir à comment procéder pour faire évoluer cette base de données pour gérer une base de joueurs croissante et un jeu de plus en plus complexe. Avec de nombreuses fonctionnalités et des expériences gérées, Spanner et Firestore ont démontré leurs forces pour les jeux mobiles à grande échelle. Google Cloud propose également Cloud SQL, une base de données MySQL gérée. Cependant, Cloud SQL peut s'avérer difficile à mettre à l'échelle car la segmentation ou le clustering manuels des bases de données peuvent considérablement complexifier votre couche de stockage d'état, ce qui entraîne des temps d'arrêt indésirables et des répercussions sur le client.
Utiliser Spanner pour les jeux internationaux avec échanges entre utilisateurs
Spanner est une base de données relationnelle entièrement gérée offrant une évolutivité illimitée, une cohérence forte et une disponibilité jusqu'à 99,999 %. Cette solution intègre la sémantique SQL avec une interface familière pour les développeurs habitués à travailler avec des bases de données relationnelles. Spanner peut être déployé à l'échelle mondiale, mais l'accès se fait à l'échelle régionale. Vous disposez donc de la simplicité d'une instance de base de données unique, associée aux performances d'instances répliquées et distribuées.
Spanner offre une évolutivité infinie. Il est donc bien adapté pour les profils des joueurs et le stockage d'inventaire. Il fournit également des garanties de transaction qui vous permettent de proposer aux clients de votre jeu une fonctionnalité fiable d'échange entre joueurs ou d'enchères privées. Spanner fournit plusieurs outils pour la migration, le développement, l'observabilité et l'introspection pour l'intégration des développeurs et l'administration de bases de données. Spanner évolue progressivement jusqu'à des millions de requêtes par seconde (RPS). Pour un lancement important, par exemple lorsque plus de 1 000 RPS sont attendues dès le premier jour, nous vous recommandons de suivre les bonnes pratiques de préchauffage et d'analyse comparative.
Spanner peut accepter les cas d'utilisation supposant plusieurs milliards d'utilisateurs, et offre la flexibilité nécessaire pour gérer cette évolutivité afin d'offrir les performances attendues. Spanner est particulièrement utile dans le domaine du jeu mobile. Pour savoir comment l'exploiter pour votre projet de jeu mobile, consultez la page Bonnes pratiques pour utiliser Spanner en tant que base de données de gaming.
Utiliser Firestore pour accélérer le développement et réduire les coûts opérationnels
Firestore est une base de données de documents NoSQL entièrement gérée et évolutive. Cette solution offre une expérience de développement simplifiée et ne nécessite pas de mises à jour de schéma si vous souhaitez stocker de nouvelles informations. Il offre également une cohérence forte, des garanties transactionnelles et une disponibilité jusqu'à 99,999 %. Firestore est également accessible directement depuis votre jeu mobile en utilisant la bibliothèque cliente Firebase.
Une approche type consiste à utiliser un seul document Firestore par joueur et à stocker toute sa progression dans ce document, dans une hiérarchie compatible avec la conception de votre jeu. Lorsque vous concevez un jeu pour utiliser Firestore, tenez compte des limitations de Firebase et des bonnes pratiques de Firestore. Selon ces bonnes pratiques, les charges de travail nécessitant des mises à jour fréquentes du même document peuvent ne pas convenir. Les jeux à très grande échelle tels que Pokémon GO ont été lancés avec Firestore (anciennement Datastore). Les jeux ont pu évoluer pour répondre à une demande exceptionnelle correspondant à plus de 50 fois le trafic de joueurs estimé.
Firestore peut gérer la mise à l'échelle automatiquement pour vous. Toutefois, pour garantir une mise à l'échelle fluide en cas d'augmentation soudaine de l'utilisation (par exemple, à la suite d'une dépense marketing importante), vous devez vous entretenir sur la planification des capacités avec votre responsable de compte Google Cloud.
Réévaluer la mise en cache comme un vecteur d'optimisation des performances
Pour optimiser les performances, il est courant de placer un cache en mémoire avant la base de données. Le cache en mémoire contient les données fréquemment lues et regroupe les mises à jour de faible priorité. Cette stratégie peut complexifier la conception de l'architecture et est rarement nécessaire avec une base de données gérée et évolutive telle que Spanner ou Firestore capable de gérer les charges de lecture et d'écriture. Si vous effectuez un test de charge des modèles d'accès à votre base de données et que vous avez toujours besoin d'un cache, envisagez une option gérée telle que Memorystore pour Redis ou Memcached afin de réduire les frais d'administration.
Choisir un emplacement de données répondant aux exigences de conformité
Lorsqu'ils sont disponibles dans le monde entier, de nombreux jeux doivent se conformer aux législations relatives à l'emplacement des données telles que le RGPD. Pour vous aider à répondre aux exigences liées au RGPD, consultez l'article Google Cloud et le livre blanc sur le RGPD et sélectionnez la configuration régionale Spanner ou la configuration régionale Firestore appropriée.
Observabilité
Nous vous recommandons de mettre en œuvre l'observabilité dès que possible. L'observabilité de votre application et de l'infrastructure de backend est importante pour identifier et résoudre rapidement les problèmes, accélérer les cycles de développement et réduire l'impact sur les clients en cas de problème. Vous pouvez aussi gagner du temps et de l'argent en adoptant un format qui fonctionne bien avec Google Cloud Observability dès les premières phases du processus de développement.
Intégrer vos métriques d'application dans Cloud Monitoring à l'aide des normes Open Source
Toutes vos ressources Google Cloud disposent d'une instrumentation pré-intégrée à Cloud Monitoring et visible dans la console Google Cloud. Par conséquent, nous vous recommandons d'instrumenter votre backend de jeu mobile pour l'intégrer à Cloud Monitoring. L'intégration à Cloud Monitoring vous permet d'utiliser un tableau de bord de surveillance à interface unifiée (parfois appelé vue unique) pour votre infrastructure et votre application. L'utilisation d'une interface unifiée vous permet de visualiser les métriques clés de votre interface et de votre application côte à côte, mais aussi de rechercher et d'isoler rapidement les problèmes.
Lorsque vous mettez en œuvre des métriques personnalisées et un traçage distribué dans votre application, nous vous recommandons d'utiliser OpenTelemetry, un projet Open Source gratuit anciennement appelé OpenCensus. Indifféremment du fournisseur, OpenTelemetry collecte des métriques et des traces dans de nombreux langages de programmation et peut les exporter vers de nombreux produits d'observabilité tels que Cloud Monitoring et Cloud Trace. Pour en savoir plus, consultez la page Métriques personnalisées avec OpenCensus.
Utiliser la journalisation structurée
Lorsque vous sélectionnez un format de journalisation, nous vous recommandons d'utiliser la journalisation structurée et de trier les caractéristiques intéressantes de vos journaux dans des champs JSON. Cette implémentation vous permet de trier, rechercher et filtrer rapidement vos journaux dans Cloud Logging. De nombreux langages de programmation disposent de bibliothèques ou de modules de journalisation structurée populaires qui peuvent exporter leurs données vers Cloud Logging. Google Cloud propose également de nombreuses bibliothèques clientes idiomatiques pour la journalisation.
Créer un récepteur de journaux BigQuery
Si vous devez analyser vos journaux ultérieurement ou les conserver en raison des lois de conservation des données de votre région d'activité, configurez à l'avance un récepteur BigQuery pour vos journaux. Seuls les nouveaux journaux générés après la création d'un récepteur sont écrits dans BigQuery. Si vous écrivez de grands volumes de journaux dans BigQuery, nous vous recommandons de sélectionner l'option permettant d'utiliser des tables partitionnées.
Analyse
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. 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. Nous vous recommandons de consulter les présentations et les témoignages deSquare Enix, King et LINE GAMES. Ces présentations peuvent vous fournir des informations réelles sur l'utilisation des produits d'analyse de Google Cloud afin d'améliorer vos jeux mobiles.
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.
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é.
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.
Même si les événements d'analyse et les données de joueur sont utiles pour les requêtes d'analyse traditionnelles et les métriques d'informatique décisionnelle, l'entraînement d'un modèle de ML nécessite un format différent. Un cas d'utilisation courant du ML dans les jeux mobiles consiste à créer un modèle personnalisé pour prédire à quel moment les joueurs dépenseront de l'argent dans le jeu. AutoML Tables peut considérablement simplifier le processus d'entraînement. Pour obtenir une présentation générale, consultez les sections Préparer vos données d'entraînement et Bonnes pratiques pour la création de données d'entraînement de la documentation d'AutoML Tables.
Plusieurs studios et éditeurs de jeux ont obtenu d'excellents résultats en utilisant un format de cumul quotidien comme base d'entraînement. Un cumul quotidien est un format de ligne normalisé qui comporte un champ pour chaque événement d'analyse significatif, ledit champ contenant 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é jusqu'à présent, ainsi qu'un indicateur 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. Le modèle peut alors recevoir une ligne de cumul quotidien et fournir des prédictions de la probabilité pour que le joueur effectue un achat. Des approches similaires de mise en forme des données peuvent également être utilisées avec différents indicateurs pour entraîner des modèles à réaliser différentes prédictions, y compris la perte d'utilisateurs ou d'autres comportements de joueur. 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 possible. 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.
Effectuer des analyses sur votre base de données de jeu Spanner
Spanner permet également aux administrateurs et aux spécialistes de l'analyse d'accéder aux données sans affecter le trafic de la base de données de jeu. La fédération de BigQuery et Spanner permet à BigQuery d'interroger les données qui résident dans Spanner en temps réel, sans avoir à les copier ni à les déplacer. Spanner permet également d'exporter des données à l'aide de modèles Dataflow que vous pouvez analyser dans Looker ou dans la console Google Cloud, ou que vous pouvez stocker sur d'autres plates-formes d'analyse de votre choix.
Distribution, notifications et autres sujets
Le développement de jeux mobiles est un domaine vaste et varié. Bien que tous les aspects pertinents ne puissent pas être traités dans un seul guide, les sections suivantes décrivent des considérations supplémentaires importantes.
Utiliser Cloud CDN pour distribuer les éléments de votre jeu
Cloud CDN peut distribuer vos éléments de jeu aux clients mobiles et dispose également d'intégrations Cloud Monitoring et Cloud Logging. Si vous êtes engagé avec un autre fournisseur, la plupart des CDN peuvent utiliser Cloud Storage en tant que serveur d'origine.
Réduire les comportements abusifs à l'aide de reCAPTCHA
Même si reCAPTCHA n'est pas techniquement intégré à votre infrastructure backend, cette solution peut s'avérer particulièrement utile dans votre client. ReCAPTCHA utilise des défis adaptatifs pour réduire les activités abusives dans votre application et est souvent utilisé dans les jeux mobiles afin de réduire le nombre d'inscriptions d'utilisateurs automatisés (bots). Pour en savoir plus, consultez la documentation de reCAPTCHA.
Envoyer des notifications push aux clients avec Firebase Cloud Messaging
Si votre jeu mobile doit envoyer des notifications push ou offrir aux utilisateurs la possibilité de communiquer entre eux, envisagez d'utiliser Firebase Cloud Messaging (FCM). FCM est un service de messagerie multiplateforme qui vous permet d'envoyer des messages de manière fiable et gratuite. Il peut également être utilisé pour envoyer des messages de données, ce qui vous offre maitrise complète sur ce qui se passe dans le code de votre application. Vous pouvez écrire votre propre application backend de messagerie ou utiliser une architecture sans serveurCloud Functions pour créer les messages puis les envoyer à l'aide du SDK Admin Firebase ou des protocoles de serveur FCM.
Simplifier la distribution de la configuration des jeux
Une approche courante de l'équilibrage de charge dans les jeux mobiles consiste à définir la plupart des paramètres de jeu dans les données. Vous pouvez ensuite distribuer les mises à jour aux clients en toute sécurité lorsque vous devez corriger des paramètres tels qu'un taux d'apparition ou une statistique d'attaque. Firebase Remote Config est conçu pour vous permettre de modifier le comportement et l'apparence de votre application sans que les utilisateurs n'aient à télécharger une mise à jour. Cela vous permet de définir des valeurs par défaut dans votre application que vous pouvez ensuite remplacer pour tous les segments ou pour certains segments spécifiques de votre base d'utilisateurs, à l'aide de la console Firebase ou de manière automatisée à partir des API de backend Remote Config.
Tester le ML pour l'équilibrage du jeu
Les recherches sur l'utilisation du ML pour l'équilibrage de jeu ont généré plusieurs études de cas réussies lors de la conférence GDC et d'autres événements. La plupart de ces études de cas proviennent de solutions personnalisées créées par des data scientist et des ingénieurs en ML, difficilement reproductibles sans une équipe expérimentée. Si vous souhaitez tester le ML pour l'équilibrage de jeu ou en tant qu'adversaire IA, des outils tels qu'AutoML Tables peuvent vous aider à tester des modèles personnalisés sans expérience approfondie du ML. Pour prédire les comportements des joueurs, comme leur sélection d'objets ou leurs prochaines actions, utilisez des approches semblables à celles décrites dans la section Normaliser les données pour l'entraînement des modèles AutoML Tables plus tôt dans le présent document.
Étapes suivantes
- Google Cloud pour le secteur des jeux vidéo
- Présentation de l'infrastructure de jeu dans le cloud
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.