Les données de groupe partagées ont été conçues à l’origine pour être pilotées de manière autoritaire par le serveur dans la plupart des cas, et il était auparavant conseillé de ne pas ajouter les joueurs directement aux données de groupe partagées, car cela leur accordait des autorisations de lecture/écriture (permettant la triche). Cependant, notre nouvelle stratégie d’accès aux API offre une bien plus grande flexibilité en matière de fonctionnalités et de sécurité par rapport à la conception d’origine. Vous trouverez plus de détails dans la section avancée de ce document.
Exemple : jeux multijoueurs asynchrones au tour par tour
Le cas d’usage d’origine, et toujours le meilleur, des données de groupe partagées peut se décrire comme le stockage de l’état d’un jeu de plateau en ligne. Les joueurs modifient les données à tour de rôle via CloudScript, selon un ordre de jeu clairement défini. Les joueurs peuvent se déconnecter et reprendre la partie plus tard, l’état de leur jeu étant stocké dans le cloud. L’exemple CloudScript suivant illustre la structure au tour par tour de n’importe quel jeu de plateau courant. Le jeu de plateau lui-même est représenté sous forme de pseudo-code.Hypothèses
Les données de groupe partagées qui représentent la partie ont déjà été initialisées, et leurs membres sont déjà définis.Principales restrictions
- Données de groupe partagées :
- Elles ne contiennent que des données simples de paires clé/valeur (chaînes). Pour une utilisation avec tout autre type de données (comme les objets d’inventaire, les statistiques, la monnaie virtuelle, etc.), le titre doit fournir les conversions nécessaires.
- Elles ne sont ni partitionnées ni mises en cache ; elles ne seront donc pas réactives en cas d’accès simultané par plusieurs joueurs. Les fonctionnalités qui les utilisent doivent être conçues pour de petits groupes de joueurs et ne pas permettre d’écritures simultanées.
