Descripción general de la infraestructura de videojuegos en la nube

Last reviewed 2022-01-28 UTC

Esta solución proporciona una descripción general de los componentes y los patrones de diseño comunes utilizados para alojar la infraestructura de videojuegos en plataformas en la nube.

Los videojuegos evolucionaron en las últimas décadas hasta convertirse en un negocio de entretenimiento próspero. Con la expansión de Internet de banda ancha, uno de los factores clave en el crecimiento de los videojuegos fue el juego en línea.

El juego en línea se presenta en varias formas, como partidas multijugador basadas en sesiones, mundos virtuales masivos de multijugadores y experiencias combinadas de un solo jugador.

Antes, los videojuegos que usaban un modelo cliente-servidor requerían la compra y el mantenimiento de servidores dedicados locales o instalados juntos para ejecutar la infraestructura en línea. Solo los grandes estudios o publicadores podían pagarlo. Además, se necesitaban las proyecciones exhaustivas y la planificación de capacidad para satisfacer las demandas de los clientes sin gastar de más en hardware fijo. Con los recursos informáticos actuales basados en la nube, los desarrolladores y publicadores de videojuegos de cualquier tamaño pueden solicitar y recibir recursos a pedido, lo que ayuda a evitar gastos monetarios iniciales altos y los peligros de un hardware de aprovisionamiento excesivo o insuficiente.

Componentes de alto nivel

En el siguiente diagrama, se ilustra la porción en línea de una arquitectura de videojuegos.

Diagrama de la infraestructura de videojuegos en Google Cloud con componentes de frontend y backend

Los componentes del frontend de la arquitectura de videojuegos son los siguientes:

Servicios de la plataforma de juegos que proporcionan funciones adicionales a los juegos.
Servidores dedicados que alojan el juego

Los componentes del backend de la arquitectura de videojuegos son los siguientes:

Estado del juego, que persiste en el sistema de registro y, por lo general, se almacena en la base de datos del juego
Pila de estadísticas que almacena y consulta eventos del juego y análisis

Estos componentes se pueden alojar en una variedad de entornos: locales, en la nube pública o privada, o incluso en una solución completamente administrada. Siempre que el sistema reúna tus requisitos de latencia para la comunicación entre los componentes y los usuarios finales, cualquiera de estos entornos puede funcionar.

Frontend

El frontend proporciona interfaces con las que los clientes pueden interactuar, ya sea directamente o a través de una capa de balanceo de cargas.

Por ejemplo, en un juego de disparos en primera persona basado en sesiones, el frontend suele incluir un servicio de creación de partidas como Open Match. Este servicio distribuye información de conexión de las instancias de servidores dedicados para juegos a los clientes:

Un cliente envía una solicitud al servicio de creación de partidas.
El servicio de creación de partidas asigna al jugador a una instancia dedicada del servidor de juegos según los criterios de coincidencia.
El servicio de creación de partidas envía información de conexión al cliente.
Luego, el cliente puede conectarse directamente a la instancia del servidor dedicada para juegos mediante el Protocolo de datagramas de usuario (UDP).

No solo los clientes externos usan servicios de frontend. Es normal que los servicios de frontend se comuniquen entre sí y con los servicios de backend.

Sin embargo, como los servicios de frontend están disponibles a través de Internet, pueden estar aún más expuestos a ataques. Deberías considerar la posibilidad de endurecer los servicios de frontend para protegerlos contra ataques de denegación del servicio y paquetes con errores de formato y, de esta manera, ayudar a resolver estos problemas de seguridad y confiabilidad. Por otro lado, en general, solo se puede acceder a los servicios de backend con el código de confianza y, por lo tanto, pueden ser más difíciles de atacar.

Servicios de la plataforma de juegos

Los nombres comunes para este componente son servicios de plataforma o servicios en línea. Los servicios de plataforma proporcionan interfaces para las funciones esenciales de metajuego, como permitir que los jugadores se unan a la misma instancia del servidor dedicado del juego o conservar el grafo social de “lista de amigos” en el juego. Es habitual que la plataforma en la que se ejecuta el juego, como Steam, Xbox Live o Google Play Juegos, proporcione estos servicios:

Historial de partidas y tabla de clasificación
Creación de partidas
Vestíbulo en línea
Chat
Administración del inventario
Autorización
Grupo
Perfil
Gremio
Desbloqueo de multiplataforma
Feeds
Asignación de identidad social
Estadísticas
Presencia

Los servicios de la plataforma de juegos evolucionaron de manera similar a los servicios web:

A principios de 2000, un conjunto típico de servicios de plataforma se ejecutaba como un servicio monolítico, implementado con frecuencia como un singleton. Incluso si está federado, este diseño no es recomendable para las implementaciones en la nube.
El patrón de la arquitectura orientada al servicio (SOA), ahora conocido, se hizo popular a mediados de 2000, cuando en el sector se cambiaron varios servicios para que fueran escalables de forma independiente. Además, ahora no solo pueden acceder a los servicios los clientes de juegos y servidores, sino también los servicios web y, finalmente, las aplicaciones de smartphones.
En los últimos cinco años, muchos desarrolladores adoptaron el enfoque de microservicios promovido por las empresas web que escalan rápidamente. La mayoría de los desafíos fundamentales de los servicios de plataforma y aplicaciones web son los mismos, como permitir ciclos de desarrollo rápidos y ejecutar servicios altamente distribuidos en todo el mundo. Los microservicios pueden ayudar a resolver estos problemas y son una opción ideal en el momento de diseñar aplicaciones para ejecutar en las plataformas en la nube.
Además, en la actualidad, existen muchos servicios alojados o administrados que ofrecen una manera de compilar servicios de plataforma o servicios de plataforma completamente administrados.

Servicios de plataforma de backend

Aunque a la mayoría de los servicios de plataforma acceden clientes externos, a en ocasiones, tiene sentido que a un servicio de plataforma accedan solo otras porciones de la infraestructura en línea, como un servicio de clasificación interna de jugadores competitivos que no se expone a la Internet pública. Aunque normalmente esos servicios de plataforma de backend no tienen una ruta de red externa y una dirección IP, siguen las mismas prácticas de diseño que los servicios de plataforma de frontend.

Recursos del servicio de la plataforma de juegos de Google Cloud

Los siguientes recursos proporcionan más información sobre cómo crear servicios de plataforma en Google Cloud.

Servidor dedicado para juegos

Los servidores dedicados para juegos proporcionan la lógica del juego. A fin de reducir la latencia percibida por el usuario, las aplicaciones de juegos para clientes, por lo general, se comunican directamente con los servidores dedicados de juegos. Esto hace que sean parte de la arquitectura de servicios de frontend.

En la industria, no existe terminología estándar; para este instructivo, se utilizarán los siguientes términos:

El término máquina hace referencia a la máquina virtual o física en la que se ejecutan los procesos del servidor de juegos.
El término servidor de juegos hace referencia al proceso del servidor de juegos. En una máquina se pueden ejecutar varios procesos del servidor de juegos de forma simultánea.
El término instancia hace referencia a un único proceso del servidor de juegos.

Tipos de servidores dedicados de videojuegos

El término dedicado puede ser confuso en el caso de los servidores de juegos de backend actuales. En su contexto original, dedicado hace referencia a los servidores de juegos que se ejecutan en hardware dedicado en una proporción de 1:1. Hoy en día, la mayoría de los publicadores de juegos administran varios procesos de servidores de juegos que se ejecutan de manera simultánea en una máquina. A pesar de que estos procesos no suelen tener máquinas enteras dedicadas a ellos, el término servidor dedicado para juegos aún se usa con frecuencia en la industria de los videojuegos.

Los servidores dedicados para juegos son tan variados como los tipos de juegos que ejecutan. En la siguiente sección, se analizan algunas de las categorías de servidores de juegos de alto nivel.

Simulaciones en tiempo real

Hasta hace poco tiempo, casi todos los servidores dedicados de juegos para un producto comercializado eran parte del frontend de un juego de simulación en tiempo real. Históricamente, los servidores de juegos de simulación en tiempo real desafiaron los límites del escalamiento vertical. Los juegos más exigentes se trasladaron a tácticas de escalamiento horizontal y manual, como la ejecución de varios procesos del servidor por máquina o la fragmentación geográfica del mundo. La comunicación UDP con el control de flujo personalizado, la confiabilidad y la prevención de la congestión es el paradigma de red dominante.

La mayoría de los servidores de juegos de simulación en tiempo real se implementan como un bucle infinito, en el que el objetivo es finalizar el bucle con una distribución del tiempo determinada. Las distribuciones del tiempo habituales son de 16 o 33 milisegundos, que producen una frecuencia de actualización de estado de 60 o 30 veces por segundo, respectivamente. La frecuencia de actualización también se denomina velocidad de fotogramas o tick rate. Aunque el servidor actualice su simulación a alta frecuencia, no es raro que el servidor comunique actualizaciones de estado a los clientes solo después de que se hayan aprobado varias actualizaciones. Esto mantiene los requisitos de ancho de banda de la red en un nivel razonable. Los efectos de la actualización con menos frecuencia se pueden mitigar mediante el uso de estrategias, como la compensación de retraso, la interpolación y la extrapolación.

Todo esto significa que los servidores de juegos de simulación en tiempo real ejecutan cargas de trabajo que hacen un uso intensivo del ancho de banda y de los recursos informáticos, y que son sensibles a la latencia, por lo que requieren un análisis detenido del diseño del servidor de juego y de las plataformas informáticas en las que se ejecuta. Google Cloud fundó el proyecto de código abierto Agones para ayudar a simplificar la ejecución de servidores dedicados para juegos alojados en clústeres de Kubernetes, como Google Kubernetes Engine (GKE).

Juegos basados en sesiones o partidas

Los juegos en los que los servidores están diseñados para ejecutar sesiones discretas son muy comunes hoy en día. Los ejemplos típicos son las sesiones multijugador de juegos de disparos en primera persona (FPS), como Call of Duty™, Fortnite™, o Titanfall™ o juegos de arena de combate multijugador en línea (MOBA), como Dota 2™ o League of Legends™. Estos juegos tienen servidores que requieren jugabilidad acelerada y cálculos detallados de estado de juego, a menudo con conversaciones dedicadas a la IA o la simulación física.

Mundos persistentes de multijugador masivo

Hace casi dos décadas, Ultima Online™ sentó las bases para una gran cantidad de juegos de multijugador masivo en línea (MMO). Los juegos de MMO más populares en la actualidad, como World of Warcraft™ y Final Fantaxy XIV™, se caracterizan por tener diseños complicados de servidores con un conjunto en constante evolución de funciones.

Los problemas complejos son comunes en los servidores de juegos de MMO, como pasar entidades del juego entre las instancias del servidor, fragmentar o sincronizar el mundo del juego, y localizar físicamente de manera conjunta las instancias que simulan zonas adyacentes del mundo del juego. Los requisitos informáticos y de memoria para calcular las actualizaciones de estado de un mundo persistente que contiene cientos o miles de jugadores pueden conducir a soluciones, como la dilatación del tiempo de Eve Online™.

Servidores basados en solicitudes y respuestas

Técnicamente, todos los servidores dedicados para juegos se basan en una serie de solicitudes y respuestas. Sin embargo, en particular, los servidores de juegos móviles, sin una demanda crítica de comunicación en tiempo real, adoptaron la semántica de solicitud y respuesta HTTP, como la que se usa en hosting web.

Los desafíos de los servidores de juegos de solicitudes y respuestas son los mismos que los de cualquier servicio web, incluidos los siguientes:

Cómo mantener el tiempo de respuesta del servidor del juego lo más rápido posible
Cómo distribuir los servidores de juegos de manera global para reducir la latencia y agregar redundancia
Cómo validar las acciones del cliente del juego en el servidor para protegerlo contra vulnerabilidades o trampas
Cómo endurecer los servidores de juegos con el fin de protegerlos contra la denegación del servicio y otros ataques
Cómo implementar el retraso exponencial para los reintentos de comunicación por parte del cliente
Cómo crear sesiones “fijas” o externalizar el estado del proceso

Las fortalezas de los servidores de juegos de solicitudes y respuestas, como la semántica de comunicación compacta y la facilidad de reintentos después de una falla de la aplicación o la red, funcionan bien para los juegos móviles por turnos. Recomendamos que los servidores de este tipo usen una API sin servidores en una plataforma como App Engine o Cloud Run.

Externaliza el estado del mundo del juego

Cada vez más, los jugadores esperan que el tiempo de inactividad sea de cero. Esto significa que debes proteger su experiencia contra problemas que afectan las instancias individuales del servidor. Para poder hacerlo, un juego debe mantener el estado del jugador fuera de un único proceso del servidor de juegos. Las ventajas son muchas, como la resiliencia frente a las fallas en los procesos del servidor y la capacidad para balancear las cargas de manera efectiva.

Lamentablemente, el hecho de usar patrones de estado externalizados populares en los servicios web puede causar problemas por varias razones, como las siguientes:

La velocidad a la que se pueden escribir las actualizaciones a un estado externo puede presentar un desafío cuando tienes muchas entidades únicas que se actualizan decenas de veces por segundo. Esto es así incluso si usas almacenamientos clave-valor en la memoria caché, como Memcached o Redis.
La latencia final de las consultas contra las memorias caché externas representa un gran problema. Es difícil cumplir plazos de actualización de estado si el 1%, o incluso el 0.1%, de tus consultas tienen una latencia mucho mayor que el plazo de actualización.
Determinar qué procesos tienen autorización de solo lectura frente a la de solo escritura en los objetos que se encuentran en tu caché externa presenta una complejidad para el modelo del servidor.

Sin embargo, resolver estos problemas tiene varios efectos secundarios beneficiosos. Los estados que se externalizaron con éxito y que están disponibles para muchos procesos con una administración de acceso existente adecuada pueden simplificar de manera significativa la capacidad de calcular porciones de la actualización del estado del juego en paralelo. Es igualmente beneficioso para migrar entidades entre las instancias.

Recursos sobre servidores de juegos dedicados de Google Cloud

En los siguientes artículos, se describe cómo ejecutar servidores dedicados de videojuegos en Google Cloud.

Backend

Los servicios de backend presentan interfaces solo para otros servicios de frontend y backend. Los clientes externos no pueden comunicarse directamente con un servicio de backend. Los servicios de backend suelen proporcionar una manera de almacenar los datos y acceder a ellos, como los datos del estado del juego en una base de datos, o los eventos de estadísticas y de registro en un almacén de datos.

Base de datos de juegos

Entre las situaciones que pueden hacer que los jugadores dejen de jugar y nunca regresen, están los servidores que no funcionan y la pérdida del progreso del jugador. Lamentablemente, los dos casos son posibles si tienes una capa de la base de datos mal diseñada.

La base de datos que conserva el estado del mundo del juego y los datos de la progresión del jugador se podría considerar la pieza más importante de la infraestructura del juego.

Deberías evaluar la capacidad de la base de datos de manejar no solo tu carga de trabajo esperada, sino también la carga de trabajo necesaria si tu juego se convierte en un gran éxito. Es poco probable que pueda servirle a alguien de manera confiable un backend diseñado y probado para una base de jugadores estimada, pero que de repente recibe una carga mucho más grande. Si no planificas un éxito inesperado, el juego puede fallar, ya que los jugadores pueden abandonarlo cuando no se puede reproducir debido a problemas en la base de datos.

Los juegos son particularmente vulnerables a este problema. La mayoría de las empresas que tienen un producto exitoso pueden esperar un crecimiento orgánico y gradual. Pero en un juego típico, habrá un gran aumento de interés al principio, seguido de una disminución rápida del uso. Si tu juego es un éxito, una base de datos sobrecargada puede tener grandes retrasos antes de guardar el progreso del usuario o incluso no guardarlo en absoluto. Ningún desarrollador de juegos quiere estar en una situación en la que tiene que decidir cuáles características del juego ya no van a admitir actualizaciones en tiempo real, así que planifica los recursos de la base de datos cuidadosamente.

Cuando se diseña una base de datos de juegos:

Toma una decisión fundamentada. No uses una base de datos durante el desarrollo porque es fácil para realizar pruebas y, luego, permitas que se convierta en la base de datos de producción sin evaluar todas las opciones. Es importante conocer el tipo y la frecuencia del acceso a la base de datos desde el juego en la base de jugadores esperada y en 10 veces esas estimaciones. Luego, puedes tomar una decisión fundamentada sobre cuál backend puede manejar mejor esas situaciones. No te pongas en la situación de tratar de aprender cómo lidiar con una crisis en la base de datos cuando se desate.
No supongas que una solución es la adecuada. No hay una regla que diga que solo puedes ejecutar un tipo de base de datos. Muchos juegos exitosos almacenan información de cuenta y procesan compras dentro del juego, mediante el uso de una base de datos relacional, al mismo tiempo que conservan la información del estado del juego en una base de datos NoSQL separada. La base de datos NoSQL es mejor para manejar cargas de trabajo de baja latencia y de gran volumen, mientras que la base de datos relacional puede proporcionar transacciones garantizadas.
Crea una copia de seguridad de los datos. Las copias de seguridad frecuentes y distribuidas geográficamente son importantes para recuperarse de una falla en la base de datos.

Bases de datos relacionales

Muchos equipos de desarrollo de juegos comienzan con una única base de datos relacional. Cuando los datos y el tráfico aumentan al punto en que el rendimiento de la base de datos ya no es aceptable, el primer enfoque común es escalar la base de datos. Cuando el escalamiento ya no es viable, muchos desarrolladores implementan una capa de servicio de base de datos personalizada. En esta capa, puedes priorizar las consultas y los resultados en caché, que limitan el acceso a la base de datos. Mediante la adición del escalamiento y de una capa de servicio de base de datos, puedes crear un backend de juego que pueda controlar grandes cantidades de jugadores. Sin embargo, estos métodos pueden ocasionar algunos problemas comunes:

Escalamiento: Las bases de datos relacionales tradicionales se centran en un enfoque de escalamiento vertical. Sin embargo, cuando se planifica un backend de juegos nativo de la nube, se recomienda usar un enfoque de escalamiento horizontal, ya que la cantidad de núcleos que puede haber en una única VM siempre será limitada, mientras que agregar VM adicionales a tu proyecto de Cloud es bastante simple. Las bases de datos relacionales tienen patrones para el escalamiento horizontal, como la fragmentación, el agrupamiento en clústeres y las réplicas en niveles, pero puede ser difícil agregarlas a una base de datos en ejecución sin tiempo de inactividad. Si hay alguna posibilidad de que tu tráfico o datos superen una sola base de datos, comienza con un clúster pequeño. No tendrás que aprender cómo escalar tu base de datos cuando se desate la crisis. Agregar nodos a un clúster mientras se ejecuta no está exento de problemas, pero es posible.
Cambios en el esquema: Muy pocos juegos exitosos se inician con un esquema de base de datos que dure toda la vida del juego. Los jugadores exigen contenido y características nuevas, y estas incorporaciones requieren el almacenamiento de nuevos tipos de datos en la base de datos. Al principio del proceso de desarrollo, deberías determinar cómo actualizarás tu esquema. Intentar actualizar tu esquema después de lanzar el juego sin un proceso establecido podría dar como resultado un tiempo de inactividad no planificado o incluso la pérdida de datos del jugador.
Administración: Escalar una base de datos relacional en ejecución y actualizar su esquema son operaciones complejas. Las bases de datos relacionales administradas de forma automática son servicios comunes de las plataformas en la nube, pero el ritmo de adopción de las bases de datos administradas de forma automática para los backends del juego es, por el momento, bajo. Esto se debe a las cargas de trabajo con alto volumen de escritura de los backends del juego.

Google ofrece Spanner, que es una base de datos relacional administrada que puede ayudarte a mitigar estos problemas. Spanner es un servicio de base de datos escalable, de nivel empresarial, distribuido en todo el mundo y con coherencia sólida que está diseñado para la nube. Combina los beneficios de la estructura de las bases de datos relacionales con el escalamiento horizontal no relacional. Muchas empresas de videojuegos consideran que Spanner es adecuado para reemplazar las bases de datos de autenticación y de estado del juego en los sistemas a escala de producción. Puedes ajustar la escala para lograr un mayor almacenamiento o rendimiento mediante el uso de la consola de Google Cloud para agregar nodos. Spanner puede manejar con transparencia la replicación global con coherencia sólida para que no tengas que administrar réplicas regionales. Si deseas obtener más información, consulta Prácticas recomendadas para usar Spanner como base de datos de videojuegos.

Bases de datos NoSQL

Las bases de datos no relacionales pueden proporcionar la solución para el funcionamiento a gran escala, especialmente, con cargas de trabajo con alto volumen de escrituras. Sin embargo, es necesario que conozcas los modelos de datos NoSQL, los patrones de acceso y las garantías transaccionales.

Hay muchos tipos de bases de datos NoSQL, y las adecuadas para almacenar el estado del mundo del juego tienen las siguientes características:

Escalamiento: Están diseñadas teniendo en cuenta el escalamiento horizontal y, a menudo, lo usan según la configuración predeterminada. Cambiar el tamaño de los clústeres es una operación que se puede realizar sin tiempo de inactividad, aunque, a veces, hay una pérdida de rendimiento hasta que se hayan integrado por completo los nodos adicionales.
Cambios en el esquema: El esquema es dinámico y la capa de aplicación lo implementa. Esta es una gran ventaja y significa que puede ser trivial agregar un campo nuevo para una característica nueva del juego.
Administración: La mayoría de los proveedores de servicios en la nube ofrecen, al menos, un motor de almacenamiento de datos NoSQL alojado o administrado, y Google Cloud ofrece varios.

Recursos de la base de datos de videojuegos de Google Cloud

Estadísticas

Las estadísticas se convirtieron en un componente importante de los juegos modernos. Tanto los servicios en línea como los clientes de juegos pueden enviar eventos de estadísticas y telemetría a un punto de recopilación común, en el que los eventos se almacenan en una base de datos. Todos pueden consultarlos, desde programadores y diseñadores de juegos hasta analistas de inteligencia empresarial y representantes del servicio de atención al cliente. A medida que aumenta la complejidad de las estadísticas que se recopilan, también aumenta la necesidad de mantener estos eventos en un formato que se pueda consultar con rapidez y facilidad.

En la última década, se observó un gran aumento en la popularidad de Apache™ Hadoop®, el marco de trabajo de código abierto basado en el trabajo publicado desde Google. La expansión del ecosistema de Hadoop aumentó el uso de operaciones complejas de extracción, transformación y carga (ETL) por lotes para dar formato y, luego, insertar eventos de estadísticas en un almacén de datos. El uso de MapReduce aceleró la velocidad a la que se entregan los resultados procesables, y esta velocidad, a su vez, ayudó a habilitar nuevas estadísticas de procesamiento intensivo.

Mientras tanto, las tecnologías disponibles en la nube siguieron evolucionando. Muchas de ellas se encuentran disponibles como servicios administrados que son fáciles de aprender y que no requieren personal de operaciones dedicado. El último paradigma ETL de transmisión de Google ofrece un enfoque unificado para el procesamiento por lotes y de transmisión, y se encuentra disponible como el servicio de nube administrado y el proyecto de código abierto Apache Beam. Las mejoras continuas en los precios de almacenamiento de datos en la nube ahora permiten conservar enormes cantidades de registros y eventos de estadísticas en bases de datos en la nube masivas y administradas que optimizan la forma en que se escriben y leen los datos. Los últimos motores de búsqueda para estas bases de datos pueden agregar TB de datos en segundos. Si deseas ver un ejemplo, consulta cómo analizar 50,000 millones de páginas vistas de Wikipedia en 5 segundos.

Te recomendamos que formatees tus estadísticas para el futuro. Cuando decidas qué eventos y métricas escribe tu juego en el backend de estadísticas, considera qué formato es el más fácil para que extraiga datos y puedas obtener estadísticas. Aunque puedes usar ETL para copiar los datos que escribe la app en un formato que funcione bien con las consultas de estadísticas, el proceso puede llevar tiempo y dinero para hacerlo. Si inviertes en el diseño del formato de salida de las estadísticas, puedes obtener ahorros de costos significativos y la posibilidad de obtener estadísticas en tiempo real.

Usa el procesamiento por lotes para los formatos existentes

Si quieres analizar los datos de métricas que están en un formato de salida que no controlas (por ejemplo, datos de un servicio o una integración de terceros), te recomendamos que primero guardes los datos de métricas en Cloud Storage. Si se admite el formato de datos, puedes consultarlo directamente desde la interfaz de BigQuery mediante las consultas federadas de BigQuery. Si el formato de datos no es compatible, puedes usar ETL para copiarlos desde Cloud Storage mediante Dataflow o mediante otras herramientas y, luego, almacenar los datos con formato resultantes en BigQuery junto con los datos de otras fuentes. Te recomendamos configurar un trabajo por lotes normal para ahorrar costos en lugar de transmisión, a menos que tengas una necesidad urgente de los datos en tiempo real. Para obtener más información sobre este enfoque, consulta Optimiza la transferencia a gran escala de los eventos de estadísticas y registros.

Predice la deserción y gastos con modelos comprobados

Es posible que ya uses Firebase en tu juego para dispositivos móviles a fin de usar una de sus muchas otras funciones, como Remote Config, mensajes desde la app o bibliotecas cliente de Firestore. Firebase también ofrece modelos integrados del aprendizaje automático (AA) para la deserción y la inversión. Puedes integrar la personalización de Remote Config para aplicar el AA a tus datos de estadísticas, lo que puede crear segmentos de usuario dinámicos según el comportamiento previsto de tus usuarios. Estos datos se pueden usar a fin de activar otras funciones de Firebase o exportarse a BigQuery para mayor flexibilidad. Firebase también ofrece clientes de Unity y C++, y su uso no se limita a los juegos para dispositivos móviles.

Normaliza datos para el entrenamiento de modelos personalizados de AutoML Tables

La generación de un modelo de AA eficaz, por lo general, requiere una vasta experiencia en AA para seleccionar características relevantes y ajustar los hiperparámetros. Sin embargo, seguir los lineamientos de preparación de datos mejora la capacidad de las últimas herramientas automatizadas para realizar estas tareas y generar un modelo útil en tu nombre. Después de que se genere un modelo, puede alojarse en Google Cloud para hacer predicciones en línea o por lotes, por ejemplo, predecir si un jugador hará una compra en un juego o dejará de jugar.

Aunque los eventos de estadísticas y los datos del jugador son útiles para las consultas de estadísticas tradicionales y las métricas de inteligencia empresarial, necesitas un formato diferente a fin de entrenar un modelo de AA. Un caso de uso común del AA en los juegos es crear un modelo personalizado que prediga cuándo los jugadores gastarán dinero por primera vez en el juego. AutoML Tables puede ayudarte a simplificar el proceso de entrenamiento. Si deseas obtener más información sobre AutoML Tables, consulta Prepara los datos de entrenamiento y Prácticas recomendadas para crear datos de entrenamiento.

Varios estudios y publicadores de juegos obtuvieron excelentes resultados mediante el uso del formato de resumen diario como base para el entrenamiento. Un resumen diario es un formato de fila normalizado que tiene un campo para cada evento de estadísticas significativo. El formato de la fila contiene un recuento acumulativo de la cantidad de veces que el jugador activó el evento hasta la fecha. En esta fila, se proporciona una instantánea diaria de todos los eventos potencialmente importantes que un jugador activó hasta la fecha, junto con una marca has made a purchase verdadera o falsa.

El proceso que se describe en la documentación de la guía de inicio rápido de AutoML Tables puede generar modelos de alta calidad cuando se entrena con datos con formato de esta manera. Luego, puedes dar al modelo una fila de resumen diario y proporcionar predicciones de la probabilidad de que el jugador realice una compra. También puedes usar enfoques similares para dar formato a los datos junto con marcas diferentes a fin de entrenar modelos para realizar distintas predicciones, incluida la deserción y otros comportamientos de los jugadores. Realizar una inversión inicial en la compilación de formatos de datos normalizados puede ayudarte a probar los modelos con rapidez a fin de predecir cualquier acción del jugador que desees. Este modelado puede ayudarte a monetizar tu juego o priorizar características que produzcan resultados de los jugadores deseados.

Soluciones de estadísticas de juegos de Google Cloud

Qué sigue

Las soluciones para los juegos en línea siguen un patrón común: los clientes se comunican con un frontend de servicios y servidores de juegos, que se comunican a un backend de estadísticas y almacenamiento de estado. Puedes ejecutar cada uno de estos componentes de manera local, en la nube o en una combinación de los dos. Si deseas ver patrones exhaustivos, consulta las soluciones para videojuegos.

Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.