Notions de base de CloudScript
Pour tirer le meilleur parti de CloudScript, il est essentiel de savoir comment utiliser les entrées dont vous disposez, à savoir les arguments (args) et le contexte de votre gestionnaire. Par exemple, voici l’exemplehelloWorld du CloudScript de démarrage, chargé en tant que révision 1 dans tous les titres nouvellement créés (également disponible sur notre GitHub, illustré ci-dessous).
inputValue et utilise la valeur de cette clé dans le texte renvoyé dans les informations du journal de débogage de l’exécution.
Le paramètre d’entrée context
Cependant, il est également possible d’appeler un CloudScript à la suite d’un événement dans PlayStream, via une règle (Automation->Rules), une action d’entrée/sortie de segment (Players->Segments) ou le service de tâches (Automation->Tasks). Dans ce cas, le contexte transmis à la fonction fournit toutes les informations dont vous aurez besoin pour effectuer l’action appropriée. Pour découvrir les bases du fonctionnement des événements PlayStream, consultez notre article de blog Introducing PlayStream, et pour obtenir la liste des types d’événements PlayStream et de leurs propriétés, consultez notre référence de l’API PlayFab. Pour voir cette action, examinez le gestionnairehandlePlayStreamEventAndProfile du même exemple de CloudScript.
-
Il y a d’abord
playStreamEvent, que vous pouvez voir dans l’exemple de code ci-dessus.playStreamEventcontient l’événement complet qui a déclenché le gestionnaire sous forme d’objet JSON, avec tous les paramètres décrits dans la documentation des événements PlayStream. Ainsi, par exemple, si vous configurez dans votre titre une règle qui appellehandlePlayStreamEventAndProfilesur toutplayer_logged_in event,playStreamEvent.EventNamevaudraplayer_logged_in, etc. (voici l’ensemble complet des paramètres de cet événement). -
Ensuite, il y a
playerProfile, également illustré dans l’exemple précédent. Il contient des informations sur le joueur qui a déclenché l’événement. Vous trouverez ici tous les détails des paramètres du profil, mais il contient notamment l’ensemble complet des statistiques du joueur dans votre titre, ainsi que toutes les balises personnalisées que vous avez attribuées au joueur, afin que vous puissiez utiliser ces données pour une prise de décision avancée. -
Le dernier élément du contexte est
triggeredByTask. Contrairement aux deux premiers, qui sont définis lors de l’utilisation des règles et des déclencheurs d’entrée/sortie de segment,triggeredByTaskne s’applique que lorsque le gestionnaire s’exécute à la suite d’une tâche, qu’elle soit manuelle ou planifiée. Il ne contient que deux paramètres :
- Name : nom unique que vous avez donné à votre tâche lors de sa création.
- ID : identificateur unique généré automatiquement par PlayFab pour votre tâche.
playerProfile, mais pas de playStreamEvent.
Et pour une tâche simplement exécutée sur votre jeu, mais sans segment, il n’y aura pas de playerProfile, car l’objectif est d’exécuter quelque chose de plus général, comme définir des données de titre pour un événement.
C’est donc l’élément name que vous utiliserez dans le flux de code de votre gestionnaire pour déterminer l’action appropriée à effectuer.
PlayStream et CloudScript
À bien des égards, les gestionnaires CloudScript déclenchés par des actions PlayStream offrent encore plus de possibilités que ceux déclenchés directement par des appels àExecuteCloudScript, car un riche ensemble de données est mis à disposition via le contexte.
Cela vous permet de mettre à jour vos gestionnaires après le lancement avec davantage de logique exploitant des éléments de l’événement ou du profil du joueur que vous n’aviez pas prévus à l’origine, sans avoir besoin de mettre à jour votre code client de quelque manière que ce soit.
En outre, nous continuerons à enrichir le profil du joueur dans les futures mises à jour du service PlayFab, ce qui offrira encore plus d’options pour la logique côté serveur.