​

Consommation PlayFab : pratiques exemplaires

Avec le modèle de tarification à la consommation de PlayFab, vous ne payez que l’utilisation réelle des services par vos titres. Mais cela soulève une question évidente : comment optimiser au mieux ces titres pour économiser de l’argent, tout en implémentant toutes les fonctionnalités dont vous avez besoin? Dans ce document, nous examinons ces détails et présentons des pratiques exemplaires qui vous aideront à anticiper. Avant de faire passer vos titres du mode Développement à la production, vous pouvez consulter les informations des compteurs dans l’onglet Billing Summary de Game Manager. Il existe six compteurs de consommation : Events, Profile, Content and Configuration, CloudScript, Insights et Multiplayer Services. La meilleure façon de commencer à optimiser un titre consiste à examiner chacun des compteurs qu’il utilise et à observer leur évolution dans le temps. Cela vous permet de dégager rapidement quelques améliorations évidentes. Pour plus d’informations sur les compteurs, consultez Compteurs de tarification.

​

Événements

Il existe deux types d’événements dans PlayFab : PlayStream et Telemetry. PlayFab traite les événements PlayStream afin de vérifier s’ils déclenchent des actions PlayStream que vous avez définies et de mettre à jour la segmentation des utilisateurs. Certains événements PlayStream sont générés automatiquement à la suite d’appels à des fonctionnalités de service telles que l’authentification et la mise à jour des statistiques. Les titres peuvent générer leurs propres événements personnalisés pour étendre cette fonctionnalité. Les événements de télémétrie ne sont pas traités par PlayStream. Ces événements sont utilisés pour l’analytique et sont envoyés directement à l’entrepôt de données. Les événements de télémétrie ne sont pas générés automatiquement dans PlayFab : il s’agit d’événements personnalisés générés par le titre. Pour les deux types d’événements, des charges utiles de données plus volumineuses augmentent l’utilisation totale des compteurs. Vous pouvez réduire cette utilisation globale en veillant à n’envoyer que les données dont vous avez besoin. En règle générale, un événement donné incrémente le compteur concerné de 1 pour chaque Ko de données dans le corps de l’événement. Pour choisir le chemin d’événement le mieux adapté à votre utilisation, vous devez avoir un plan clair de l’utilisation prévue de chaque événement personnalisé que vous générez. Les événements qui ne sont nécessaires que pour l’évaluation hors ligne du titre doivent emprunter la voie de la télémétrie. Cela peut réduire considérablement les coûts, car les frais de dépassement des événements de télémétrie sont inférieurs à la moitié de ceux de PlayStream. Si vous utilisez l’un des SDK prédéfinis, n’oubliez pas que certaines données analytiques sur le comportement des utilisateurs sont générées automatiquement, comme décrit dans la référence du modèle d’événements PlayStream. Pour désactiver les événements facultatifs, modifiez le paramètre d’analytique dans l’onglet Settings/Data Collection de votre jeu dans PlayFab Game Manager. De même, s’il est judicieux d’activer l’option “generate PlayStream event” pour vos exécutions CloudScript pendant le débogage, assurez-vous de la désactiver avant la mise en production. Dans le cas des CloudScripts déclenchés par des actions PlayStream, vous pouvez toujours les réactiver ultérieurement si vous devez déboguer un comportement en conditions réelles.

​

Profile

Le profil correspond en pratique à « tout ce qui concerne le joueur », y compris des éléments courants tels que l’inventaire, les données enregistrées et les statistiques. Il contient également les métadonnées que vous utilisez pour offrir des expériences uniques grâce aux fonctionnalités LiveOps de PlayStream, comme la segmentation des utilisateurs mentionnée ci-dessus. En outre, certaines fonctionnalités héritées au niveau du titre, telles que Title Data, Catalogs et Stores, sont incluses dans ce compteur, car l’implémentation de leurs données est en pratique identique à celle de User Data. Comme cet ensemble de compteurs est alimenté par toutes les actions des joueurs et toutes les actions effectuées sur les joueurs, c’est de loin celui qui nécessite le plus de planification en matière d’optimisation. Les principaux facteurs qui contribuent à l’utilisation enregistrée par les compteurs de tarification sont la quantité de données lues, stockées et écrites, ainsi que la fréquence d’appel des API qui génèrent des données mesurées. Pour plus d’informations sur les appels d’API spécifiques qui font « tourner » ces compteurs, consultez Compteurs de tarification. Nous allons commencer par User Data et Statistics, car leurs modèles d’utilisation sont similaires, puis nous aborderons la gestion de l’inventaire des joueurs.

​

Données et statistiques

Pour évaluer votre utilisation de User Data, la même logique d’approximation que pour les événements s’applique (chaque Ko augmente le compteur de 1), mais gardez à l’esprit que chaque « élément » d’un appel doit être considéré comme distinct dans ce calcul. Chaque paire clé-valeur d’un appel de mise à jour de User Data est comptabilisée séparément. Pour les lectures, ce calcul par Ko s’applique au total des données retournées, quel que soit le nombre de paires clé-valeur. Cela signifie que l’écriture de 10 clés de 100 octets chacune correspond à 10 « incréments » du compteur d’écriture de profil, puisque chaque écriture de paire clé-valeur compte pour 1 Ko au minimum, tandis qu’une lecture de ces 10 clés correspond à 1 « incrément », puisque le total est de 1 Ko. Pour plus de détails sur les utilisations, consultez Compteurs de tarification. Les statistiques sont un peu plus complexes, car elles mettent à jour le profil et peuvent également avoir une incidence sur les classements. En règle générale, vous pouvez considérer chaque mise à jour de statistique comme une mise à jour complète du profil, tandis que les lectures dépendent de la taille totale des données lues lors de chaque appel. Et comme le stockage est facturé par gigaoctet (Go) et que les statistiques ne consomment généralement que quelques octets chacune, nous nous concentrerons sur les lectures et les écritures. Comme la taille totale des données est importante, son optimisation constitue la première étape. Heureusement, il existe un large éventail de techniques bien connues : utiliser des énumérations ou des ID à la place du texte en toutes lettres pour les objets, empaqueter les données volumineuses au format binaire, voire utiliser des champs de bits pour réduire l’espace occupé par les données. Une fois cela fait, l’étape suivante consiste à évaluer soigneusement à quel moment vous devez effectuer ces appels de lecture et d’écriture. Si vous venez du développement PC ou console, en particulier de jeux solo, ce modèle peut être nouveau pour vous. Dans ces environnements, vous devez faire attention à la consommation de ressources et au garbage collection sur l’appareil client, car ils peuvent dégrader les performances à des moments critiques. Lorsque votre titre utilise des ressources situées dans le nuage, il est nécessaire d’étendre cette logique en considérant que chaque sollicitation de ressource a un coût réel, en plus d’un coût en performances. Comment déterminer la fréquence optimale des lectures et des écritures? Deux des préoccupations les plus courantes des développeurs qui souhaitent mettre à jour plus fréquemment les données et les statistiques sont la protection contre la triche et la disponibilité d’informations à jour côté serveur, que ce soit pour les interactions entre joueurs ou pour éviter les pertes de données si le jeu se ferme de façon inattendue.

​

Protection contre la triche

Même s’il peut sembler nécessaire de mettre constamment à jour vos données de back-end pour garantir une sécurité essentielle, des mises à jour fréquentes sont rarement nécessaires si votre jeu n’exige pas un contrôle de la session faisant entièrement autorité côté serveur. Pour commencer, la question fondamentale est de savoir quel niveau de sécurité vous est réellement nécessaire. Pour certains jeux, notamment ceux qui se monétisent principalement par la publicité en jeu et ne comportent pas de classements, la triche n’est pas vraiment un problème. Dans ce cas, faire confiance aux données envoyées par le client est souvent une approche viable, car la sécurité de ces données n’est pas réellement un enjeu. Pour identifier les comportements de triche et décider de la façon de les gérer, nous vous recommandons de mettre en place des processus d’examen des événements, des données et des statistiques de vos joueurs. Pour d’autres jeux, dans lesquels vous devez garantir l’intégrité de la compétition ou protéger l’expérience globale des joueurs, une sécurité renforcée est plus importante. Selon vos exigences spécifiques, certaines approches peuvent réduire la fréquence des lectures et des écritures de données dans ces situations. Si votre jeu ne se déroule pas en temps réel, une approche que nous recommandons consiste à agréger les informations sur la partie du joueur sur une certaine période (souvent une « manche » de quelques minutes), puis à envoyer ces données à un script qui détermine si elles sont valides. Les éléments clés à évaluer peuvent dépendre du jeu, mais voici quelques exemples de notions courantes à prendre en compte :

• Combien de temps s’est-il écoulé depuis le dernier rapport de session, et combien de temps le client indique-t-il avoir joué lors de la dernière session?
• Quels scores le joueur a-t-il enregistrés, et sont-ils plausibles compte tenu de son niveau, de son équipement, etc.?

Pour les jeux soumis à des exigences plus proches du temps réel, comme la nécessité de mettre à jour fréquemment l’état du joueur faisant autorité côté serveur, une meilleure solution que des mises à jour fréquentes des données stockées dans PlayFab consiste à utiliser des serveurs de jeu hébergés. Dans ce modèle, vous connectez le joueur à un serveur au début de la session. Le serveur lit depuis le service toutes les données nécessaires pour le joueur, puis héberge l’état de simulation de ce joueur au fil du temps, le client échangeant des données avec le serveur à la fréquence dont vous avez besoin. Le serveur met ensuite à jour le « stockage à long terme » dans PlayFab avec les dernières données du joueur, soit à la fin d’une session, soit toutes les quelques minutes si vos sessions sont particulièrement longues. C’est le modèle utilisé par les jeux multijoueurs en temps réel. C’est également une technique valable pour les titres solo qui nécessitent des vérifications faisant autorité côté serveur; toutefois, si cette fréquence se limite à quelques fois par minute et par joueur, CloudScript avec Azure Functions peut être la meilleure option. Le coût total de CloudScript est facile à calculer : il correspond au nombre total de gigaoctets-secondes consommés, avec un minimum de 128 Mo et 100 ms par exécution, plus les calculs habituels pour tous les autres appels d’API de service effectués par le script. Par exemple, si l’empreinte mémoire totale de votre code de script et des variables utilisées dans le script est de 250 Mo, vous devez exécuter ce script pendant 4 secondes (très probablement réparties entre plusieurs utilisateurs) pour atteindre 1 Go/s. Et si, dans ce code de script, vous lisez ou écrivez des objets d’entité, des Title Data, des User Data, etc., vous devez calculer l’incidence de chacun de ces appels sur les compteurs de profil. Comme le coût des serveurs de jeu hébergés dépend du nombre de serveurs que vous exécutez, lequel dépend à son tour du nombre de joueurs pouvant être hébergés simultanément sur un serveur, il n’est pas forcément simple de déterminer le seuil de rentabilité entre les deux. Mais si vous constatez que vous devez appeler vos scripts très fréquemment et lire et écrire des données depuis le service à chaque fois, une solution de serveur de jeu sera très probablement la meilleure option.

​

Actualité des données

L’une des préoccupations récurrentes des développeurs dont le taux d’écriture de profil est élevé est le risque de perte de progression du joueur. Si le joueur quitte le jeu avant qu’il puisse enregistrer et que l’état local ne peut pas être utilisé lors de la partie suivante, ou si cet état doit être transféré d’un appareil à l’autre, il faut que les informations d’état du joueur stockées dans PlayFab soient aussi à jour que possible. Pour de nombreux jeux, vous pouvez résoudre ce problème en mettant en place une pulsation régulière et peu fréquente de mises à jour vers le service (toutes les 15 minutes, par exemple). L’ajout d’une logique supplémentaire pour allonger ou raccourcir cette fréquence peut également être utile. Par exemple :

• Prévoyez un mécanisme de « mise à jour importante » qui déclenche une écriture immédiate et réinitialise le minuteur lorsque le joueur réalise activement une action importante, afin qu’elle ne puisse pas être perdue.
• Si votre jeu continue de progresser sans intervention du joueur, envisagez d’allonger la période de pulsation en l’absence d’intervention prolongée. C’est particulièrement important pour les jeux « idle », que les joueurs laissent souvent tourner toute la nuit.
• Offrez aux joueurs un moyen de forcer directement une mise à jour, par exemple à l’aide d’un bouton dans un menu utilisateur. Dans ce cas, veillez toutefois à limiter la fréquence réelle des appels de l’appareil client vers PlayFab, afin qu’un joueur qui appuie sur ce bouton à répétition ne génère pas un appel à chaque fois.

Si le client dispose des informations d’état lors de la partie suivante, vous pouvez comparer l’horodatage local à celui des données du service et décider lesquelles utiliser, voire laisser le joueur choisir. Les informations de profil d’un joueur peuvent être pertinentes au-delà du joueur lui-même. Dans certains jeux, vous pouvez avoir besoin de les interroger d’un joueur à l’autre, que ce soit pour stimuler la compétition ou pour influencer directement l’expérience de jeu au moyen d’interactions asynchrones entre amis, de défis, etc. Pour la compétition, les classements sont un moyen idéal de créer cette tension en partageant un sous-ensemble d’informations sur les autres joueurs (souvent ceux dont le score est proche de celui du joueur actuel) au moyen d’un seul appel au service. Comme il est possible de retourner d’autres éléments du profil, tels que les statistiques et les balises, à l’aide des contraintes d’affichage du profil, vous pouvez présenter un ensemble riche d’informations sur ces autres joueurs. Il est toutefois important de ne pas parcourir la liste de tous les joueurs du classement en essayant de lire des informations supplémentaires sur chacun d’eux, car cela multiplierait rapidement le nombre total de lectures de profil et ferait grimper vos coûts. Pour les jeux qui utilisent directement des données d’autres joueurs pendant la session, l’optimisation la plus courante consiste à ne lire que les informations des quelques joueurs avec lesquels le joueur local interagit. Pour les jeux d’action en temps réel, cela se fait généralement sur le serveur qui héberge la session. Pour les autres, comme les jeux dans lesquels les joueurs peuvent attaquer la base des autres, les approches les plus courantes consistent soit à lire toutes ces données sur l’appareil local, soit à n’envoyer au joueur local que le sous-ensemble des données de l’autre joueur qu’il doit connaître. Les jeux qui adoptent la première approche utilisent une logique côté serveur pour évaluer les résultats finaux envoyés par le client. Ceux qui adoptent la seconde mettent à jour les données de façon itérative au cours de la session, avec davantage de données lorsque le joueur local doit y avoir accès; mais même dans ce cas, ils utilisent également une logique côté serveur pour évaluer les résultats finaux. Là encore, le choix entre un script et un serveur hébergé dépend de la fréquence. Au-delà de quelques fois par minute, il vaut mieux utiliser un serveur hébergé pour la partie de la session qui nécessite ces données.

​

Économie et inventaire

L’inventaire, et l’économie en général, nécessitent une approche différente. Il est indéniable que si un joueur cède quelque chose ayant une valeur réelle (de l’argent) ou perçue (monnaie virtuelle ou conteneurs consommables), il s’attend implicitement à ce que la transaction soit honorée. Pour tout jeu offrant des achats intégrés, l’incrémentation du compteur de profil pour un achat effectué par le joueur avec de l’argent réel représente un coût négligeable. Dans de nombreux types de jeux, les mises à jour de l’inventaire sont suffisamment peu fréquentes pour ne pas augmenter sensiblement votre utilisation globale. Mais pour les jeux où les mises à jour de l’inventaire sont plus fréquentes, même sans monétisation en jeu, il existe des astuces d’optimisation pour vous aider à réduire vos coûts. Une bonne pratique consiste à ne considérer l’inventaire qu’au sens littéral, comme un inventaire raisonnablement fini. Par exemple, dans un jeu incrémental (ou « idle »), il peut être tentant de considérer chaque ressource acquise par le joueur comme un objet, en incrémentant le total à chaque fois que le joueur en achète un autre. Mais ce modèle s’effondre rapidement lorsque l’on calcule la fréquence à laquelle les joueurs effectuent ces actions : chaque joueur solliciterait immédiatement le compteur des centaines, voire des milliers de fois par session. Dans de telles situations, il est préférable de considérer ces éléments comme des User Data et de les mettre à jour sur le service en suivant les recommandations de la section Profile ci-dessus. Pour les jeux dont le taux de mise à jour de l’inventaire est plus élevé, nous revenons à la question de l’actualité des données. Par exemple, un jeu d’action peut suivre le nombre de balles dont dispose un joueur, mais les données de back-end de cette « pile » de balles n’ont pas besoin d’être mises à jour à chaque pression sur la détente, en particulier si l’état du jeu est géré sur un serveur hébergé. Les objets empilables vous offrent un avantage en termes de performances et de coûts, car vous pouvez représenter de nombreuses instances virtuelles d’un objet sous la forme d’une seule instance réelle assortie d’un nombre. Vous pouvez souvent agréger les modifications des piles d’objets au fil du temps et les mettre à jour à la fin d’une session, ou régulièrement au cours de celle-ci. Lors de la mise à jour d’une pile, il est judicieux d’appeler Player Item Management - Modify Item Uses pour vérifier si vous pouvez simplement modifier le nombre d’éléments de la pile, plutôt que d’ajouter N instances de l’objet qui doivent chacune être traitées pour être ajoutées à la pile, puis nettoyées. Par nature, certains genres de jeux, comme les jeux de cartes à collectionner, doivent mettre à jour l’inventaire des joueurs à un rythme un peu plus soutenu. Mais même dans ce cas, il reste possible d’agréger les modifications de l’inventaire et de réduire l’utilisation totale des compteurs de profil. Par exemple, dans les jeux qui utilisent des tables de butin, la conception fait souvent appel à un conteneur qui effectue un ou plusieurs « tirages » dans chacune de plusieurs tables de butin différentes. En général, si ces tirages ne sont qu’occasionnels, le coût supplémentaire est suffisamment faible pour ne pas poser de problème. Mais si les joueurs peuvent collecter un grand nombre de ces conteneurs et en ouvrir plusieurs en peu de temps, vous pouvez offrir une option « ouvrir N » ou même « tout ouvrir ». Dans ce cas, vous utilisez PlayFab CloudScript avec Azure Functions ou votre serveur de jeu personnalisé pour interroger Player Item Management - Get Random Result Tables afin d’obtenir l’ensemble des tables de butin, ou pour appeler Player Item Management - Evaluate Random Result Table sans générer les objets d’inventaire. Vous pouvez ensuite mettre à jour l’inventaire du joueur de façon beaucoup plus efficace, en n’ajoutant des instances que lorsque c’est nécessaire et en mettant à jour le nombre d’éléments des piles d’objets pour le reste.

​

Contenu et configuration

Alors que Profile concerne principalement le joueur, Content and Configuration concerne principalement le titre. Plusieurs composants au niveau du titre, tels que les notifications Push, les services de courriel et Title News, sont inclus dans ce compteur. En outre, c’est ce compteur qui permet de suivre l’utilisation des fichiers d’entité (Entity File). De même, les demandes d’URL de téléversement et de téléchargement de fichiers CDN sont suivies par ce compteur; il est toutefois important de préciser que les coûts CDN sont distincts et facturés en fonction du nombre total de gigaoctets téléchargés, comme décrit dans Réseau de distribution de contenu (CDN). Le calcul des compteurs de lecture et de stockage de Content and Configuration est similaire à celui des compteurs de profil, car il repose sur la taille des données, même si les unités sont évidemment bien supérieures à 1 Ko. Le compteur d’écriture de Content and Configuration repose uniquement sur le nombre total d’opérations d’écriture, chacune l’incrémentant de 1. Par ailleurs, le système Entity File est le service recommandé pour les données volumineuses, qu’elles soient associées au titre, à un groupe ou à un joueur individuel. Pour les jeux qui enregistrent des données volumineuses par joueur, le système Entity File est généralement plus rentable; gardez toutefois à l’esprit que la fréquence de ces mises à jour a une incidence sur l’utilisation suivie. Il est préférable de trouver le bon équilibre entre le nombre de fichiers dont vous avez besoin et la fréquence à laquelle ils doivent être mis à jour. Pour optimiser les coûts du compteur Content and Configuration, l’élément le plus important à surveiller est la fréquence à laquelle votre titre doit demander ses propres données de configuration, qui changent rarement. Il s’agit principalement des Title Data, couramment utilisées pour gérer les aspects de vos jeux qui sont identiques pour tous les utilisateurs, comme les données d’équilibrage/de réglage du jeu, les définitions des succès, les données de localisation, etc. Pour les jeux qui utilisent CloudScript, si vous constatez que chaque appel à un script dépend de ces données au niveau du titre, vous pouvez envisager d’« intégrer » ces données directement dans le script. Pour ce faire, il suffit de les définir sous forme de données codées en dur dans le script lui-même, ou d’utiliser des variables statiques, comme moyen de mise en cache, pour lire les informations depuis le service une fois par instance de machine virtuelle (VM). Ainsi, les données au niveau du titre sont téléversées la première fois qu’une machine virtuelle exécute votre script, puis réutilisées par cette machine virtuelle lors des exécutions suivantes. Trois points sont à garder à l’esprit : premièrement, le script est utilisé par de nombreux utilisateurs différents; rien ne doit donc être considéré comme constant pour un utilisateur donné d’une exécution à l’autre. Deuxièmement, le traitement des données doit être considéré comme sans état, car un même joueur peut solliciter des machines différentes à chaque appel. Enfin, vous devez suivre l’ancienneté de ces données et les recharger régulièrement, afin de vous assurer de disposer de la dernière version.

​

CloudScript

Il s’agit de l’un des principaux « joints de dilatation » du service PlayFab : il vous permet d’exécuter une logique faisant autorité côté serveur depuis un appareil client ou un serveur, voire de la déclencher au moyen de règles PlayStream (par exemple, lorsqu’un joueur entre dans un segment). Contrairement à l’hébergement de serveurs de jeu personnalisés, vous ne payez que les gigaoctets-secondes (Go/s) d’exécution du script, avec des minimums par exécution de 128 Mo et 100 ms. Ainsi, si votre script utilise un total de 250 Mo d’espace (code de script et données compris), il doit s’exécuter pendant 4 secondes au total (probablement réparties entre plusieurs exécutions) pour atteindre un Go/s. Comme les cas d’usage de CloudScript consistent généralement à effectuer des actions pour le compte de vos joueurs, nous avons couvert l’essentiel de ce à quoi vous devez réfléchir en matière d’optimisation dans les deux dernières sections, consacrées aux compteurs de profil et de contenu/configuration. Toutefois, le nombre total d’exécutions d’un titre est également suivi dans le cadre de la mesure de l’utilisation de CloudScript; il est donc utile d’examiner la fréquence à laquelle vous devez appeler CloudScript pour chaque joueur. Pour certains jeux, il peut être nettement plus rentable d’utiliser un serveur de jeu hébergé pour disposer d’un magasin de données « à chaud » pour les joueurs actifs, plutôt que d’essayer de gérer un magasin de données au moyen d’appels successifs à CloudScript.

​

Insights

Ce compteur est associé à toutes les fonctionnalités d’analytique du service PlayFab, de l’ingestion et de l’exportation des événements à la recherche dans l’historique des événements et aux requêtes Data Explorer. Votre utilisation est ici influencée par la vitesse à laquelle vous avez besoin que les événements soient traités, la quantité de données d’événements que vous souhaitez conserver « à chaud » (pour les requêtes dans Game Manager) et la mesure dans laquelle vous utilisez le service pour évaluer vos données, que ce soit au moyen de requêtes Data Explorer ou au moyen d’un logiciel de visualisation connecté directement à vos données. Ce compteur est influencé à la fois par l’activité en jeu (événements) et hors jeu (analytique). En définitive, cela signifie que les coûts d’Insights dépendent de la quantité de données d’événements que vous obtenez des joueurs et du volume de traitement analytique que vous effectuez sur ces données. En matière de pratiques exemplaires, les conseils relatifs aux événements ci-dessus s’appliquent au premier point; pour le second, vous pouvez maîtriser vos coûts de deux façons. Premièrement, et c’est le plus simple, vous pouvez définir le stockage total dans l’onglet Insights Management de Game Manager pour votre titre, afin de contrôler la quantité totale de données d’événements conservées dans PlayFab. Ensuite, dans ce même onglet, vous pouvez définir le niveau de performances de votre titre. Celui-ci détermine la quantité totale de ressources processeur allouées à votre titre, ainsi que la quantité de données stockées « à chaud » pour les requêtes dans l’historique des événements. Vos besoins pour chacun de ces paramètres dépendent de ceux des membres de votre équipe d’analyse des données; il est donc préférable de les examiner avec eux pour déterminer vos paramètres. Pour plus d’informations sur Insights et son utilisation, consultez Qu’est-ce que PlayFab Insights?. Pour plus d’informations sur les pratiques exemplaires relatives à Insights, consultez Pratiques exemplaires et FAQ.

​

Services multijoueurs

C’est le cas le plus simple de tous, puisque la tarification est totalement inchangée. En bref, les Multiplayer Servers hébergés et le service Party ont toujours été facturés en fonction de l’utilisation. Pour les serveurs de jeu hébergés en particulier, vous pouvez réduire vos coûts en optimisant le nombre de cœurs de serveur qui doivent être en cours d’exécution à un moment donné pour prendre en charge le plus grand nombre de joueurs possible. Si des temps de ping faibles sont importants sur ces serveurs, vous pouvez choisir les régions dans lesquelles exécuter les serveurs. Pour la plupart des jeux, les plus grandes concentrations de joueurs se limitent à certaines régions clés; mais si votre population de joueurs est très dispersée, en particulier lorsque votre jeu est dans sa phase de longue traîne, vous devrez peser le coût de l’exécution de serveurs dans chaque région proche de vos joueurs par rapport à l’incidence de temps de ping plus longs sur le sous-ensemble de joueurs situés dans des zones comptant peu de joueurs. Pour vous y aider, assurez-vous d’utiliser notre service QoS pour choisir les régions dans lesquelles placer les joueurs, puis déterminez le nombre minimal de joueurs actifs requis pour qu’une région soit viable.

​

Gestion de votre jeu en production

Voilà pour les principes fondamentaux des compteurs, mais à quoi devez-vous réfléchir une fois votre titre en production? La gestion de votre communauté de joueurs implique principalement l’analytique (Insights, dans la section ci-dessus) et les mises à jour de Content and Configuration. En outre, la plupart des jeux doivent interagir avec les joueurs en dehors de leurs interactions habituelles avec le jeu lui-même. Des campagnes de réengagement (pour inciter les joueurs à revenir) aux récompenses communautaires pour les activités liées au méta-jeu, en passant par les remerciements adressés aux joueurs pour leur propre travail communautaire en dehors du jeu, une pratique courante aujourd’hui consiste à utiliser des techniques LiveOps pour maintenir un engagement élevé des joueurs. L’un des éléments clés consiste à cibler efficacement votre segmentation sur des groupes bien définis, non seulement pour limiter les coûts, mais aussi pour garantir un traitement rapide de votre logique. Prenons par exemple le réengagement des joueurs, qui consiste à faire revenir les joueurs qui ont cessé de jouer depuis un certain temps. Une bonne approche consiste à définir plusieurs périodes d’inactivité des utilisateurs, par exemple les joueurs qui n’ont pas joué depuis 3, 7 et 21 jours. Pour chacune d’elles, vous pouvez adopter une approche de réengagement différente, en commençant par un simple message « vous nous manquez » et en terminant par un message « voici de l’or/de l’énergie/etc. gratuit » (associé, bien sûr, à l’ajout automatique de ces éléments au compte du joueur). Pour chacune de ces périodes, l’approche recommandée consiste à définir une fenêtre d’une heure basée sur la dernière connexion du joueur au jeu. Ainsi, vous ciblez non seulement la dernière fois qu’il a joué, mais vous limitez aussi l’ensemble des joueurs du segment, afin de rendre l’opération aussi efficace que possible. À l’aide d’une tâche planifiée qui se déclenche toutes les heures sur chacun de ces segments, vous envoyez les messages et ajoutez les objets ou la monnaie virtuelle (VC) à l’inventaire des joueurs.

​

Résumé

En définitive, ce sont les fonctionnalités dont votre jeu a besoin qui déterminent son utilisation d’un service de back-end comme PlayFab. Tout se résume à une question globale : quelles sont vos exigences pour ces fonctionnalités? Que vous privilégiiez la sécurité, l’actualité des données, le niveau d’interaction/de compétition entre joueurs ou tout autre aspect, de nombreux facteurs peuvent vous pousser vers un niveau d’interaction plus élevé avec les données de back-end. Être capable d’examiner ces exigences d’un œil critique et de distinguer celles qui sont indispensables de celles qui ne le sont pas s’apparente beaucoup à l’optimisation de n’importe quelle autre partie du code de votre jeu. Il s’agit d’examiner attentivement les endroits où votre utilisation des ressources est élevée et de déterminer si elle doit vraiment l’être, ou s’il existe des moyens de repenser cette logique pour réduire l’utilisation. Si l’interaction se fait en temps réel, entre joueurs, tout dépend de la complexité de cette interaction. Pour la plupart des jeux de ce type, des serveurs hébergés qui gèrent l’état de simulation et ne mettent à jour les données de back-end qu’à la fin d’une session (ou toutes les quelques minutes si les sessions sont longues) constituent généralement la meilleure solution. Mais dans de nombreux cas, l’interaction bénéficie d’une confiance totale, comme dans les jeux coopératifs ou ceux auxquels on ne joue qu’avec (ou contre) des amis, ce qui réduit l’incitation à tricher. D’autres encore n’ont que des exigences minimales quant à la vérification des données d’une session, ce qui permet aux deux joueurs de simplement envoyer leurs rapports après chaque session, afin que des vérifications côté serveur puissent les comparer. Pour tout jeu sans exigence de temps réel, demandez-vous si le joueur a vraiment besoin d’une précision à la seconde près. Dans les jeux très compétitifs dotés d’une forte interaction communautaire, c’est peut-être le cas. Mais pour de nombreux jeux, des informations datant de quelques minutes n’ont aucune incidence sur l’expérience des joueurs.