Shared Group Data se diseñó originalmente para funcionar de forma autoritativa desde el servidor en la mayoría de los casos, y la recomendación anterior era no agregar jugadores directamente a Shared Group Data, ya que eso les otorgaba permisos de lectura/escritura (lo que permitía hacer trampas). Sin embargo, nuestra nueva directiva de acceso a la API permite una variedad mucho mayor de funcionalidad y seguridad respecto al diseño original. Hay más detalles disponibles en la sección avanzada de este documento.
Ejemplo: juegos multijugador asincrónicos por turnos
El caso de uso original, y aún el mejor, de Shared Group Data se describe mejor como el almacenamiento del estado de un juego de mesa en línea. Los jugadores se turnan para modificar los datos mediante CloudScript, con un orden de turnos claro. Los jugadores pueden cerrar sesión y reanudar la partida más tarde, con el estado del juego almacenado en la nube. El siguiente ejemplo de CloudScript es la estructura por turnos de cualquier juego de mesa común. El juego de mesa en sí se representa como pseudocódigo.Supuestos
El Shared Group Data que representa el juego ya se ha iniciado y su membresía ya está definida.Restricciones clave
- Shared Group Data:
- Solo contiene datos simples de pares clave/valor (cadenas). Para usarlo como cualquier otro tipo de datos (como objetos de inventario, estadísticas, moneda virtual, etc.), el título debe proporcionar las conversiones necesarias.
- No está particionado ni almacenado en caché, por lo que no responderá bien cuando varios jugadores accedan a él simultáneamente. Las características que lo usen deben diseñarse pensando en grupos pequeños de jugadores y no permitir escrituras simultáneas.
