Shared Group Data es una manera sencilla de que los jugadores compartan cierta información con una lista estrechamente restringida de otros jugadores.
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.
Shared Group Data no debe ser utilizado por grupos de más de una docena de jugadores aproximadamente, como máximo. Un problema es que si demasiados jugadores intentan leer los mismos datos al mismo tiempo, se producirán retrasos en la lectura de los datos (Shared Group Data no está particionado ni almacenado en caché, como sí lo están los datos pensados para ser leídos por muchos jugadores a la vez, como Title Data). Y se debe tener especial cuidado para evitar que los jugadores sobrescriban los datos de los demás. En el caso de que varios jugadores intenten escribir en la misma clave al mismo tiempo, solo una de esas escrituras “ganará”, lo que provocará la pérdida de los datos del otro usuario.
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.
A un nivel general, puede usar Shared Group Data para implementar grupos (parties)/raids u otros grupos semipermanentes de jugadores, siempre que el tamaño del grupo sea relativamente pequeño, como se ha indicado.
Aunque actualmente no hay un límite estrictamente aplicado, el uso con muchos jugadores no es compatible y, en casos extremos, puede provocar la limitación de la característica del título para evitar el impacto en otros usuarios del servicio.
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.
Consideraciones sobre los permisos del cliente
No hay un sistema de roles/rangos dentro de un grupo, lo que significa que cualquier miembro del grupo tiene autoridad absoluta dentro del grupo (no hay un líder definido).
Dicho sin rodeos, esto significa que, a menos que deshabilite los métodos de cliente de Shared Group Data con nuestra directiva de acceso a la API, los clientes tendrán control completo de los datos, lo que podría dar lugar a la explotación de los datos.
La práctica recomendada es no usar Shared Group Data para datos que afecten al juego, o bien deshabilitar los métodos de Shared Group Data en la API de cliente.