​

Consumo de PlayFab: procedimientos recomendados

Con el modelo de precios basado en el consumo de PlayFab, solo paga por el uso real del servicio de sus títulos. Pero esto plantea una pregunta obvia: ¿cuál es la mejor manera de optimizar esos títulos para ahorrar dinero y, al mismo tiempo, implementar todas las características que necesita? En este documento, profundizamos en esos detalles y hablamos de los procedimientos recomendados que le ayudarán a planificar con antelación. Antes de pasar los títulos del modo de desarrollo a Live, puede revisar la información de los medidores en la pestaña Billing Summary de Game Manager. Hay seis medidores de consumo: eventos, perfil, contenido y configuración, CloudScript, Insights y servicios multijugador. La mejor manera de empezar a optimizar un título es examinar cada uno de los medidores que usa y ver cómo se acumula a lo largo del tiempo. Esto le permite deducir rápidamente algunas mejoras obvias. Para obtener más información sobre los medidores, consulte Medidores de precios.

​

Eventos

Hay dos tipos de eventos en PlayFab: PlayStream y telemetría. PlayFab procesa los eventos de PlayStream para comprobar si desencadenan acciones de PlayStream que haya definido y para actualizar la segmentación de usuarios. Algunos eventos de PlayStream se generan automáticamente como resultado de llamadas a características del servicio, como la autenticación y las actualizaciones de estadísticas. Los títulos pueden generar sus propios eventos personalizados para ampliar esta funcionalidad. PlayStream no procesa los eventos de telemetría. Estos eventos se usan para análisis y van directamente al almacenamiento de datos. Los eventos de telemetría no se generan automáticamente en PlayFab; son eventos personalizados generados por el título. Para ambos tipos de eventos, las cargas de datos más grandes aumentan la cantidad total de uso del medidor. Puede reducir ese uso general asegurándose de enviar solo los datos que necesita. Como guía aproximada, cualquier evento incrementa el medidor en cuestión en 1 por cada 1 KB de datos en el cuerpo del evento. Para elegir qué ruta de eventos se adapta mejor a su uso, debe tener un plan claro de cómo pretende usar cada evento personalizado que genere. Los eventos que solo se necesitan para la evaluación sin conexión del título deben ir por la ruta de telemetría. Esto puede ayudar a reducir significativamente los costos, ya que los cargos por excedente de los eventos de telemetría son menos de la mitad que los de PlayStream. Si usa uno de los SDK precompilados, es importante recordar que algunos datos de análisis sobre el comportamiento de los usuarios se generan automáticamente, tal como se describe en la referencia del modelo de eventos de PlayStream. Para desactivar los eventos opcionales, cambie la configuración de análisis en la pestaña Settings/Data Collection de su juego en Game Manager de PlayFab. Del mismo modo, aunque es una buena idea tener activada la opción “generate PlayStream event” para las ejecuciones de CloudScript durante la depuración, debe asegurarse de deshabilitarla antes de pasar a producción. En el caso de los CloudScripts desencadenados por acciones de PlayStream, siempre puede volver a activarlos más adelante si necesita depurar algún comportamiento en producción.

​

Perfil

El perfil es, en la práctica, “todo lo relativo al jugador”, incluidos elementos comunes como el inventario, los datos guardados y las estadísticas. También contiene la metainformación que usa para ofrecer experiencias únicas a través de las funcionalidades de LiveOps en PlayStream, como la segmentación de usuarios mencionada anteriormente. Además, algunas características heredadas de nivel de título, como Title Data, los catálogos y las tiendas, se incluyen en este medidor, ya que su implementación de datos es prácticamente la misma que la de User Data. Dado que este conjunto de medidores se ve afectado por todas las acciones de los jugadores y las acciones realizadas sobre los jugadores, es con diferencia el que requiere más planificación de optimización. Los principales factores que contribuyen al uso capturado por los medidores de precios son la cantidad de datos que se leen, almacenan y escriben, y la frecuencia con la que se llama a las API que generan datos que se miden. Para obtener más información sobre las llamadas a API específicas que generan “consumo” en estos medidores, consulte Medidores de precios. Comenzaremos con User Data y las estadísticas, ya que sus patrones de uso son similares, y luego hablaremos de la administración del inventario del jugador.

​

Datos y estadísticas

Al evaluar el uso de User Data, se aplica la misma lógica de aproximación que para los eventos: cada 1 KB aumenta el recuento del medidor en 1, aunque tenga en cuenta que cada “elemento” de una llamada debe considerarse distinto a efectos de este cálculo. Cada par clave-valor de una llamada para actualizar User Data se contabiliza por separado. En el caso de las lecturas, este cálculo de 1 KB se aplica al total de datos devueltos, independientemente del número de pares clave-valor. Esto significa que escribir 10 claves de 100 bytes cada una supone 10 “incrementos” del medidor de escrituras de perfil, ya que cada escritura de un par clave-valor es de un mínimo de 1 KB, mientras que una lectura de esas 10 claves supone 1 “incremento”, ya que es un total de 1 KB. Para obtener detalles más específicos sobre los usos, consulte Medidores de precios. Las estadísticas son ligeramente más complejas, ya que actualizan el perfil y también pueden afectar a las tablas de clasificación. Como regla general, puede considerar cada estadística actualizada como una actualización completa del perfil, mientras que las lecturas se basan en el tamaño total de los datos leídos en cada llamada. Y dado que el almacenamiento se cobra por gigabyte (GB) y las estadísticas suelen consumir solo unos pocos bytes cada una, nos centraremos en las lecturas y escrituras. Puesto que el tamaño total de los datos es importante, optimizarlo es el primer paso. Afortunadamente, hay una amplia gama de técnicas bien conocidas para ello: usar enumeraciones o identificadores en lugar de texto escrito para los elementos, empaquetar datos grandes como binarios o incluso usar campos de bits para empaquetar datos en espacios más pequeños. Una vez hecho eso, el siguiente paso es evaluar cuidadosamente cuándo es necesario realizar esas llamadas de lectura y escritura. Si viene del desarrollo para PC o consola, especialmente de juegos para un solo jugador, este podría ser un patrón nuevo. Pero en esos entornos, debe tener cuidado con los accesos a recursos y la recolección de elementos no utilizados en el dispositivo cliente, ya que pueden provocar una degradación del rendimiento en momentos críticos. Cuando el título usa recursos que están en la nube, es necesario ampliar esa lógica para considerar que cada acceso a un recurso tiene un costo real, además de un costo de rendimiento. ¿Cómo se determina la frecuencia óptima de lecturas y escrituras? Dos de las preocupaciones más comunes de los desarrolladores que quieren actualizar los datos y las estadísticas con más frecuencia son protegerse contra las trampas y disponer de información puntual almacenada en el servidor, ya sea para interacciones entre jugadores o para evitar la pérdida de datos si el juego se cierra de forma inesperada.

​

Protección contra trampas

Aunque pueda parecer que necesita actualizar constantemente los datos del back-end para garantizar una seguridad esencial, las actualizaciones frecuentes rara vez son necesarias si el juego no requiere un control totalmente autoritativo del servidor sobre la sesión. Para empezar, la pregunta fundamental es cuánta seguridad necesita realmente. Para algunos juegos, en particular los que se monetizan principalmente a través de anuncios dentro del juego y no tienen tablas de clasificación, las trampas no son una gran preocupación. En este caso, confiar en los datos que envía el cliente suele ser un enfoque viable, ya que la seguridad de esos datos no es realmente una preocupación. Para identificar comportamientos de trampas y decidir cómo quiere gestionarlos, se recomienda implementar procesos para revisar los eventos, los datos y las estadísticas de los jugadores. Para otros juegos en los que necesita respaldar la integridad de la competición o proteger la experiencia general del jugador, una seguridad más sólida es más importante. En función de sus requisitos específicos, ciertos enfoques pueden reducir la frecuencia de lecturas y escrituras de datos en esas situaciones. Si el juego no es en tiempo real, un enfoque que se recomienda es agregar información sobre la partida del jugador durante un período de tiempo (a menudo una “ronda” del juego, que dura varios minutos) y luego enviar esos datos a un script que determine si son válidos. Los elementos clave que se deben evaluar pueden depender del juego, pero algunos ejemplos de conceptos comunes que se deben considerar son:

• ¿Cuánto tiempo ha pasado desde el último informe de sesión y cuánto tiempo dice el cliente que jugó en el más reciente?
• ¿Qué puntuaciones registró el jugador y son razonables para ese jugador dado su nivel, equipamiento, etc.?

Para los juegos con requisitos más de tiempo real, como la necesidad de actualizar con frecuencia el estado autoritativo del jugador en el servidor, una solución mejor que las actualizaciones frecuentes de los datos almacenados en PlayFab es usar servidores de juego hospedados. En ese modelo, el jugador se conecta a un servidor al inicio de la sesión. El servidor lee todos los datos necesarios del servicio para el jugador y luego hospeda el estado de la simulación para ese jugador a lo largo del tiempo, mientras el cliente intercambia datos con el servidor a la frecuencia que necesite. A continuación, el servidor actualiza el “almacenamiento a largo plazo” en PlayFab con los datos más recientes del jugador, ya sea al final de una sesión o cada pocos minutos si las sesiones son particularmente largas. Este es el modelo que usan los juegos multijugador en tiempo real. También es una técnica válida para títulos de un solo jugador que requieren comprobaciones autoritativas del servidor, aunque si esa frecuencia es de solo unas pocas veces por minuto por jugador, CloudScript con Azure Functions podría ser la mejor opción. El costo total de CloudScript es fácil de calcular. Es el total de gigabyte-segundos que consume, con un mínimo de 128 MB y 100 ms por ejecución, más los cálculos normales de cualquier otra llamada a la API del servicio que use el script. Por ejemplo, si tiene una superficie total de memoria, entre el código del script y el uso de variables en el script, de 250 MB, tendría que ejecutar ese script durante 4 segundos (probablemente entre varios usuarios) para llegar a 1 GB/s. Y dentro de ese código de script, si lee o escribe Entity Objects, Title Data, User Data, etc., tendrá que calcular el consumo que cada una de esas llamadas genera en los medidores de perfil. Dado que los costos de los servidores de juego hospedados dependen de cuántos servidores esté ejecutando, y eso a su vez depende de cuántos jugadores se puedan hospedar en un servidor a la vez, no es necesariamente trivial determinar dónde está el punto de equilibrio entre ambos. Pero si descubre que necesita llamar a los scripts con una frecuencia alta y necesita leer y escribir datos del servicio cada vez, es muy probable que una solución de servidor de juego sea la mejor opción.

​

Puntualidad de los datos

Un tema común que hemos escuchado entre los desarrolladores con altas tasas de escritura de perfil es que les preocupa que el jugador pierda el progreso. Si el jugador sale del juego antes de que se pueda guardar y el estado local no se puede usar la próxima vez que se juegue, o si ese estado debe viajar entre dispositivos, querrá que la información de estado del jugador almacenada en PlayFab esté lo más actualizada posible. Para muchos juegos, puede abordar este problema con un latido regular y poco frecuente de actualizaciones al servicio (cada 15 minutos, por ejemplo). Pero incluir lógica adicional para alargar o acortar esa frecuencia también puede ayudar. Por ejemplo:

• Incluya una invalidación de “actualización importante” que provoque una escritura inmediata y restablezca el temporizador si el jugador hace activamente algo significativo, de modo que no pueda perderse.
• Si el juego sigue progresando sin la intervención del jugador, considere alargar el período del latido si no ha habido entrada durante mucho tiempo. Esto es especialmente importante para los juegos idle, en los que los jugadores suelen dejarlos en ejecución durante la noche.
• Ofrezca a los jugadores una forma de forzar una actualización directamente, como un botón en un menú de usuario. Sin embargo, en este caso, asegúrese de limitar la frecuencia con la que se realizan realmente las llamadas desde el dispositivo cliente a PlayFab, de modo que un jugador que pulse ese botón una y otra vez no genere una llamada cada vez.

Si el cliente tiene la información de estado la próxima vez que se juegue, puede comparar localmente la marca de tiempo con la de los datos del servicio y decidir cuál usar, o incluso ofrecer al jugador la opción de elegir. La información del perfil de un jugador puede ser relevante para más personas que él mismo. En algunos juegos, es posible que necesite consultarla entre jugadores, ya sea para estimular la competición o para influir directamente en la experiencia del jugador a través de interacciones asincrónicas con amigos, desafíos, etc. Para la competición, las tablas de clasificación son una forma ideal de generar esa tensión compartiendo un subconjunto de información sobre otros jugadores (a menudo los que están cerca de la puntuación del jugador actual) mediante una sola llamada al servicio. Dado que es posible devolver otros elementos del perfil, como estadísticas y etiquetas, mediante las restricciones de vista de perfil, puede presentar un conjunto enriquecido de información sobre estos otros jugadores. Pero es importante no iterar por la lista de todos los jugadores de la tabla de clasificación intentando leer información adicional de cada uno, ya que esto multiplicaría rápidamente el número total de lecturas de perfil y aumentaría los costos. Para los juegos que usan datos entre jugadores directamente en la sesión, la optimización más común es leer solo la información de los pocos jugadores específicos con los que interactúa el jugador local. Para los juegos de acción en tiempo real, esto se suele hacer en el servidor que hospeda la sesión. Para otros, como los juegos en los que los jugadores pueden atacar las bases de los demás, los enfoques más comunes son leer todos esos datos en el dispositivo local o enviar al jugador local solo el subconjunto de los datos del otro jugador que el jugador local debe conocer. Los juegos que hacen lo primero usan lógica del lado servidor para evaluar los resultados finales que envía el cliente. Los juegos que hacen lo segundo actualizan los datos de forma iterativa durante el transcurso de la sesión con más datos, cuando el jugador local debe tener acceso a ellos. Pero incluso entonces, también usan lógica del lado servidor para evaluar los resultados finales. Una vez más, el punto de inflexión para decidir si esto debe hacerse mediante script o en un servidor hospedado depende de la frecuencia. Si es más de unas pocas veces por minuto, es mejor usar un servidor hospedado para la parte de la sesión que requiere esos datos.

​

Economía e inventario

El inventario, y la economía en general, requieren un enfoque diferente. No se puede evitar el hecho de que, si un jugador está entregando algo de valor real (dinero) o percibido (moneda virtual o contenedores consumibles), tiene la expectativa implícita de que la transacción se respetará. Para cualquier juego con compras dentro de la aplicación, un incremento del medidor de perfil por una compra realizada por el jugador con moneda del mundo real es un costo insignificante. En muchos tipos de juegos, las actualizaciones de inventario son lo suficientemente infrecuentes como para no suponer una gran preocupación por aumentar significativamente el uso general. Pero para aquellos con actualizaciones de inventario más frecuentes, incluso si no tiene monetización dentro del juego, existen trucos de optimización que ayudan a reducir los costos. Un procedimiento recomendado es pensar en el inventario solo en sentido literal, como un inventario razonablemente finito. Por ejemplo, en un juego incremental (o “idle”), puede resultar tentador pensar en cada recurso que el jugador adquiere como un elemento, incrementando el número total cada vez que el jugador compra otro. Pero ese modelo se desmorona rápidamente cuando calcula la frecuencia con la que los jugadores realizan esas acciones. De inmediato, tendría que lidiar con que cada jugador incremente el medidor cientos o incluso miles de veces en una sesión. Para situaciones como esta, es mejor pensar en esos elementos como User Data y actualizarlos en el servicio siguiendo las recomendaciones de la sección Perfil anterior. En cuanto a los juegos que tienen tasas más altas de actualización del inventario, volvemos a la cuestión de la puntualidad de los datos. Por ejemplo, un juego de acción podría hacer un seguimiento del número de balas que tiene un jugador, pero los datos del back-end de esa “pila” de balas no necesitan actualizarse con cada disparo, especialmente si el estado del juego se administra en un servidor hospedado. Los elementos apilables le ofrecen una ventaja de rendimiento y costo, ya que puede representar muchas instancias virtuales de un elemento como una sola instancia real con un recuento. A menudo puede agregar los cambios en las pilas de elementos a lo largo del tiempo y actualizarlos al final de una sesión, o periódicamente durante la sesión. Al actualizar una pila, es una buena idea llamar a Player Item Management - Modify Item Uses para comprobar si puede simplemente cambiar el recuento de la pila, en lugar de agregar N instancias del elemento, que deben procesarse una a una para agregarlas a la pila y luego limpiarse. Por su naturaleza, ciertos géneros de juegos, como los juegos de cartas coleccionables, sí necesitan actualizar el inventario del jugador con una frecuencia algo mayor. Pero incluso aquí, todavía hay oportunidades para agregar los cambios de inventario y reducir el uso total en los medidores de perfil. Por ejemplo, en los juegos que usan tablas de botín, el diseño suele emplear un contenedor que tiene una o varias “extracciones” de cada una de varias tablas de botín diferentes. Normalmente, si estas extracciones son solo una acción ocasional, el costo incremental es lo suficientemente pequeño como para no causar preocupación. Pero si los jugadores pueden coleccionar muchos de esos contenedores y abrir varios en un corto período de tiempo, podría ofrecer una opción de “abrir N” o incluso “abrir todos”. En ese caso, use CloudScript de PlayFab con Azure Functions o su servidor de juego personalizado para consultar Player Item Management - Get Random Result Tables para el conjunto de tablas de botín o llamar a Player Item Management - Evaluate Random Result Table sin generar los elementos de inventario. Después, podría actualizar el inventario del jugador de forma mucho más eficiente agregando instancias solo donde sea necesario y actualizando el recuento de las pilas de elementos para el resto.

​

Contenido y configuración

Mientras que el perfil se centra principalmente en el jugador, el contenido y la configuración se centran principalmente en el título. Varios componentes de nivel de título, como las notificaciones push, los servicios de correo electrónico y Title News, están incluidos en este medidor. Además, este es el medidor que se usa para hacer un seguimiento del uso de Entity Files. Del mismo modo, las solicitudes de las direcciones URL para cargar y descargar archivos de la CDN se registran en este medidor, aunque es importante aclarar que los costos de la CDN son independientes y se facturan según el total de gigabytes descargados, tal como se describe en Red de entrega de contenido (CDN). El cálculo de los medidores de lectura y almacenamiento de contenido y configuración es similar al de los medidores de perfil, en el sentido de que se basan en el tamaño de los datos, aunque obviamente las unidades son significativamente mayores que 1 KB. En el caso del medidor de escrituras de contenido y configuración, se basa únicamente en el número total de operaciones de escritura, y cada una incrementa el medidor en 1. Como nota al margen, el sistema Entity File es el servicio recomendado para datos de gran tamaño, ya estén asociados al título, a un grupo o a un jugador individual. Para los juegos con partidas guardadas de gran tamaño por jugador, el sistema Entity File suele ser más rentable; aunque tenga en cuenta que la frecuencia de esas actualizaciones afecta al uso que se registra. Lo mejor es optimizar el número de archivos que necesita en función de la frecuencia con la que deben actualizarse. En cuanto a la optimización de costos en el medidor de contenido y configuración, lo más importante que hay que controlar es la frecuencia con la que el título debe solicitar sus propios datos de configuración que rara vez cambian. Principalmente se trata de Title Data, que se usa habitualmente para administrar aspectos de sus juegos que son los mismos para todos los usuarios, como los datos de equilibrio/ajuste del juego, las definiciones de logros, los datos de localización, etc. Para los juegos que usan CloudScript, si descubre que hay una dependencia de estos datos de nivel de título en cada llamada a un script, puede considerar “integrar” esos datos directamente en el script. Puede hacerlo con el sencillo recurso de definirlos como datos codificados de forma rígida en el propio script, o bien usando variables estáticas, como medio de almacenamiento en caché, para leer la información del servicio una vez por instancia de máquina virtual (VM). De esta manera, los datos de nivel de título se cargan la primera vez que una máquina virtual determinada ejecuta el script y esa máquina virtual los reutiliza en ejecuciones posteriores. Hay tres cosas que debe tener en cuenta: en primer lugar, el script lo usan muchos usuarios diferentes, por lo que nada debe considerarse coherente para un usuario individual entre ejecuciones. En segundo lugar, el procesamiento de los datos debe considerarse sin estado, ya que un mismo jugador podría llegar a máquinas diferentes en cada llamada. Y, por último, debe hacer un seguimiento de la antigüedad de esos datos y recargarlos periódicamente para asegurarse de que tiene la versión más reciente.

​

CloudScript

Este es uno de los principales “puntos de expansión” del servicio de PlayFab, ya que le permite ejecutar lógica autoritativa del servidor desde un dispositivo cliente o un servidor, o incluso desencadenarla mediante reglas de PlayStream (por ejemplo, cuando un jugador entra en un segmento). A diferencia del hospedaje de servidores de juego personalizados, solo paga por los gigabyte-segundos (GB/s) que se ejecuta el script, con mínimos por ejecución de 128 MB y 100 ms. Por lo tanto, si el script usa un total de 250 MB de espacio (entre el código del script y los datos), tendría que ejecutarse un total de 4 segundos, probablemente entre varias ejecuciones, para llegar a un GB/s. Dado que los casos de uso de CloudScript generalmente giran en torno a realizar acciones en nombre de los jugadores, ya hemos cubierto la mayor parte de lo que debería tener en cuenta para las optimizaciones en las dos últimas secciones sobre los medidores de perfil y de contenido/configuración. Sin embargo, el número total de ejecuciones de un título también se registra como parte de la medición del uso de CloudScript, por lo que resulta útil revisar con qué frecuencia necesita realizar llamadas a CloudScript por jugador. Para algunos juegos, podría ser significativamente más rentable usar un servidor de juego hospedado para tener un almacén de datos “activo” para los jugadores activos, en lugar de intentar administrar un almacén de datos con llamadas iterativas a CloudScript.

​

Insights

Este medidor está asociado a todas las funcionalidades de análisis del servicio de PlayFab, desde la ingesta y exportación de eventos hasta la búsqueda en el historial de eventos y las consultas de Data Explorer. Su uso aquí depende de la rapidez con la que necesite que se procesen los eventos, de la cantidad de datos de eventos que quiera mantener hospedados “activos” (para consultas en Game Manager) y de cuánto use el servicio para evaluar sus datos, ya sea mediante consultas de Data Explorer o software de visualización que conecte directamente a los datos. Este medidor se ve afectado tanto por la actividad dentro del juego (eventos) como por la actividad fuera del juego (análisis). En última instancia, esto significa que los costos de Insights dependen de la cantidad de datos de eventos que obtiene de los jugadores y de cuánto procesamiento de análisis realiza sobre esos datos. En cuanto a los procedimientos recomendados, los consejos sobre eventos anteriores se aplican a lo primero, mientras que para lo segundo puede controlar los costos de dos maneras. La primera, y más sencilla, es que puede establecer el almacenamiento total en la pestaña Insights Management de Game Manager para el título con el fin de controlar la cantidad total de datos de eventos que conserva en PlayFab. La segunda, y en esa misma pestaña, puede establecer el nivel de rendimiento del título. Esto determina la cantidad total de recursos de CPU asignados al título, así como la cantidad de datos que se almacenan “activos” para las consultas en el historial de eventos. La cantidad que necesita para cada uno depende de las necesidades de los miembros de su equipo de análisis de datos, por lo que es mejor revisar esto con ellos para saber cuál debe ser su configuración. Para obtener información sobre Insights y cómo usarlo, consulte ¿Qué es PlayFab Insights?. Para obtener información sobre los procedimientos recomendados de Insights, consulte Procedimientos recomendados y preguntas frecuentes.

​

Servicios multijugador

Este es el más sencillo de todos, ya que los precios no han cambiado en absoluto. En resumen, los servidores multijugador hospedados y el servicio Party siempre se han cobrado según el uso. Específicamente para los servidores de juego hospedados, puede minimizar los costos optimizando el número de núcleos de servidor que debe tener en ejecución en un momento dado para dar soporte al mayor número de jugadores posible. Si los tiempos de ping bajos son importantes en esos servidores, puede elegir en qué regiones ejecutar los servidores. Para la mayoría de los juegos, las mayores concentraciones de jugadores se limitan a ciertas regiones clave, pero si tiene una población de jugadores muy dispersa, especialmente cuando está en la cola larga de su juego, tendrá que sopesar el costo de ejecutar servidores en todas las regiones cercanas a sus jugadores frente al impacto de tiempos de ping más largos en el subconjunto de jugadores de zonas con pocos jugadores. Algo que puede ayudar con esto es asegurarse de usar nuestro servicio de QoS para elegir en qué regiones colocar a los jugadores y, después, determinar cuál es su límite para el número mínimo de jugadores que necesita que jueguen en una región para que sea viable.

​

Administración del juego en producción

Esto cubre los aspectos fundamentales de los medidores, pero ¿en qué debería pensar una vez que su título esté en producción? La administración de su comunidad de jugadores implica principalmente análisis (Insights, en la sección anterior) y actualizaciones de contenido y configuración. Además, la mayoría de los juegos necesitan interactuar con los jugadores fuera de sus interacciones normales con el propio juego. Desde campañas de reactivación (para atraer a los jugadores a que vuelvan) hasta recompensas de comunidad por la actividad del metajuego, e incluso agradecer a los jugadores su propio trabajo comunitario fuera del juego, una práctica común hoy en día es usar técnicas de LiveOps para mantener a los jugadores muy involucrados. Una de las claves para ello es asegurarse de dirigir eficazmente la segmentación a grupos bien definidos, no solo para mantener bajos los costos, sino también para asegurarse de que la lógica se procese rápidamente. Tomemos, por ejemplo, la reactivación de jugadores: conseguir que los jugadores vuelvan después de haber dejado de jugar durante algún tiempo. Una buena forma de abordar esto es definir varios períodos de tiempo de usuarios inactivos, por ejemplo, jugadores que no han jugado durante 3, 7 y 21 días. Para cada uno, puede adoptar un enfoque diferente de reactivación, comenzando con un simple mensaje de “te echamos de menos” y culminando con un mensaje de “aquí tienes oro/energía/etc. gratis” (acompañado, por supuesto, de la adición automática de eso a la cuenta del jugador). Para cada uno de ellos, el enfoque recomendado es definir una ventana de una hora basada en la última vez que el jugador inició sesión para jugar. De esta manera, no solo se dirige a la última vez que jugaron, sino que también mantiene minimizado el conjunto de jugadores del segmento, con el fin de que la operación sea lo más eficiente posible. Mediante una tarea programada que se activa una vez cada hora en cada uno de esos segmentos, envía los mensajes y agrega los elementos o monedas virtuales (VC) a los inventarios de los jugadores.

​

Resumen

En última instancia, son las características que necesita su juego las que determinan su uso de un servicio de back-end como PlayFab. En realidad, todo se reduce a una pregunta global: ¿qué requisitos tiene para esas características? Ya sea que priorice la seguridad, la puntualidad de los datos, el nivel de interacción/competición entre jugadores o cualquier otra cosa, hay muchos factores que pueden empujarle hacia un mayor nivel de interacción con los datos del back-end. Ser capaz de examinar esos requisitos con ojo crítico y discernir cuáles son necesidades imprescindibles y cuáles no, es muy parecido a la optimización de cualquier otro código de su juego. Se trata de examinar detenidamente dónde es alto el uso de recursos y decidir si realmente necesita que lo sea, o si hay formas de rediseñar esa lógica para reducir el uso. Si la interacción es en tiempo real, de jugador a jugador, depende de la complejidad de esa interacción. Para la mayoría de los juegos de este tipo, los servidores hospedados que administran el estado de la simulación y solo actualizan los datos del back-end al final de una sesión (o cada pocos minutos, si las sesiones son largas) suelen ser la mejor solución. Pero hay muchos casos en los que la interacción es totalmente de confianza, como los juegos cooperativos o los que se juegan solo con (o contra) amigos, lo que minimiza el incentivo para hacer trampas. Otros tienen solo requisitos mínimos sobre cómo deben comprobarse los datos de una sesión, lo que permite que ambos jugadores simplemente envíen sus informes después de cada sesión, para que las comprobaciones del lado servidor puedan comparar los dos. Para cualquier juego sin un requisito de tiempo real, considere si el jugador realmente necesita una precisión al segundo. En juegos altamente competitivos con una fuerte interacción comunitaria, puede que sea así. Pero para muchos juegos, una información desactualizada por unos pocos minutos no afecta a la experiencia del jugador.