En este documento, se describen las prácticas recomendadas a fin de ejecutar un backend de juego para dispositivos móviles basado en API en Google Cloud. En este documento, se proporciona una referencia que los desarrolladores de juegos pueden usar como punto de partida a fin de diseñar una arquitectura en línea de juegos para dispositivos móviles. Las prácticas recomendadas de este documento se pueden aplicar a cualquier tipo de juego para dispositivos móviles. Sin embargo, este documento se centra en los juegos que almacenan el progreso del jugador y la información de la cuenta en una base de datos y que acceden a esos datos a través de una API de interfaz personalizada escrita por los desarrolladores del juego.
Este documento es para equipos que desarrollan videojuegos para dispositivos móviles, como Pokémon Go de Niantic, Super Mario Run de Nintendo o Candy Crush Saga de King. Las prácticas recomendadas de este documento no son para juegos de azar (juegos de cartas y casino) o apps de deportes de fantasía (por ejemplo, fútbol de fantasía), que por lo general se escalan como una app web típica o aplicaciones sociales.
La naturaleza exitosa de un juego puede impulsar aumentos masivos en la demanda durante las horas de mayor consumo. Debido a que tu app puede aparecer en una tienda de aplicaciones o la puede adoptar una comunidad de transmisión, es importante considerar los casos de éxito y asegurarte de que tengas una ruta clara para escalar cuando un juego se hace popular. Tomar decisiones fundamentadas durante el desarrollo puede ayudar a minimizar el riesgo.
Calcula la carga esperada de tu usuario
Cuando diseñas el backend en línea de tu juego para dispositivos móviles, es importante tener una estimación aproximada de la carga del usuario. Si diseñas tu arquitectura para que use la mayoría de sus recursos con la carga esperada, es posible que falle si recibe atención de la comunidad de gamers más grande y no puede escalar a fin de satisfacer esa demanda. Si no se escala, se pueden perder oportunidades de ingresos y dañar la reputación de tu estudio. Diseñar una arquitectura que se ejecute bien con la carga esperada puede ser difícil, pero tiene una ruta clara a una escala mucho mayor si tienes un éxito inesperado.
Las estimaciones de carga del usuario siempre se basan en muchos datos, pero hay dos categorías esenciales que deben incluirse:
- Cantidad de jugadores y frecuencia de las sesiones de juego: Esto suele ser una suposición basada en la cantidad de jugadores que participan en juegos similares en el mercado y según tu presupuesto para obtener usuarios a través de la inversión en marketing.
- Carga de la API que causa cada jugador: Se puede medir mediante pruebas de cargas completas.
Realiza una estimación inicial
Cuando realices una estimación inicial, considera todos los factores disponibles, como los siguientes:
- Éxito de juegos anteriores o juegos similares en el mercado
- Popularidad de cualquier propiedad intelectual (PI) incluida
- Momento de la publicación la aplicación en el mercado
- Cantidad de registros previos o promociones cruzadas en el resto de tu cartera de apps
- Presupuesto de marketing
Después de estimar la cantidad de usuarios, es una práctica habitual crear la mejor situación posible cuatro veces (4X) que la estimación. Sin embargo, te recomendamos que consideres un caso de éxito en la que un juego se vuelve viral o tiene un éxito inesperado. Algunos estudios aumentan su estimación del usuario 10 veces (10X), pero los lanzamientos de juegos anteriores en Google Cloud aumentaron su estimación 20 veces (20X) o, incluso, 40 veces (40X) en circunstancias extremas. Incluso si esas cifras son muy poco probables, es importante calcular estos números y validar que la arquitectura pueda escalar a esos niveles.
Ejecuta una prueba de carga
Conocer la cantidad esperada de usuarios no es suficiente a fin de comprender las necesidades de escalamiento del juego para dispositivos móviles. Es fundamental ejecutar pruebas de carga con condiciones que sean lo más cercanas posible a las circunstancias reales. Se debe ejecutar una prueba de carga con verificadores beta cerrados que usen una versión casi definitiva del juego. Las pruebas de carga te permiten generar perfiles de rendimiento de la base de datos de almacenamiento de estado y la capa de la API a fin de asegurarte de que haya suficiente espacio disponible. Los usuarios reales a menudo pueden crear patrones de uso que los desarrolladores no pueden predecir. Por lo tanto, es importante obtener un perfil de uso de jugador en vivo para usarlo como modelo a fin de realizar pruebas de carga a mayor escala. Te recomendamos usar un framework de prueba de carga para replicar los patrones de usuario de la prueba beta a la escala que determine la estimación inicial que calculaste en la sección anterior.
Cuando ejecutes una prueba de carga a gran escala, comunícate con el equipo de Ventas de Google Cloud y presenta un ticket de Atención al cliente de Cloud adecuado para el período en el que planeas realizar una prueba de esfuerzo. Enviar un ticket de Atención al cliente permite que el equipo te solicite de forma proactiva aumentos de cuota cuando sea necesario. También ayuda a garantizar que un ingeniero de Atención al cliente esté disponible para responder tus preguntas en caso de que un producto de Google Cloud no se comporte como esperas.
Valida con la arquitectura de referencia
En el siguiente diagrama, se proporciona una arquitectura de referencia para las prácticas recomendadas de este documento:
En el diagrama anterior, los clientes del juego se conectan al backend del juego para dispositivos móviles a través de un balanceador de cargas. El backend tiene una conexión directa a la base de datos de registros del jugador, con una capa de caché de alta velocidad opcional que almacena y recupera el progreso del jugador, las autorizaciones y otros datos. El backend emite métricas y registros de operaciones a Google Cloud Observability. Las métricas y los registros son fundamentales para supervisar el rendimiento del backend, y tu almacén de datos puede acceder a ellos. Los especialistas en análisis pueden acceder directamente al almacén de datos mediante BigQuery, y AutoML se puede usar para generar modelos que se utilizan a fin de predecir los gastos y la deserción. Estas predicciones se pueden poner a disposición del backend del juego. Los siguientes componentes se describen en detalle más adelante en este documento:
- Procesamiento usado para API orientadas al cliente
- Base de datos usada para el almacenamiento de estado
- Observabilidad y supervisión de Google Cloud Observability
- Análisis
Algunos juegos para dispositivos móviles ofrecen el modo multijugador en tiempo real mediante un servidor dedicado a videojuegos o servidores TURN/STUN. Las prácticas recomendadas de este documento no incluyen explícitamente estos servidores, pero son compatibles con los servidores de juegos.
Opciones de Compute
Google Cloud proporciona varias opciones de procesamiento para el backend del juego para dispositivos móviles, desde opciones escalables completamente administradas, como App Engine, hasta entornos completamente personalizables, como Google Kubernetes Engine (GKE). Es importante que comprendas tus necesidades en detalle y decidas en consecuencia. Todas las opciones en las siguientes secciones ofrecen una integración completa con Cloud Load Balancing para que el tráfico HTTP(S) pueda aprovechar el escalamiento continuo. Las opciones también incluyen funciones de Google Cloud Armor, como la protección contra DSD de nivel empresarial.
Usa App Engine para obtener un escalamiento sin servidores comprobado
App Engine es la plataforma sin servidores completamente administrada de Google Cloud que te permite enfocarte en escribir código sin tener que administrar la infraestructura subyacente. Puedes configurar App Engine para que ajuste la escala según las necesidades de tu juego. También permite tiempos de iteración más rápidos para tus desarrolladores mediante la compilación y la implementación directa desde la fuente con un solo comando. App Engine es una opción ideal para equipos pequeños o con experiencia limitada en el escalamiento de operaciones de infraestructura. Se prueba a gran escala a través de varios lanzamientos de juegos para dispositivos móviles, incluidos los lanzamientos de Nintendo, Madfinger Games, Pocket Gems, y Backflip Studios.
Cuando evalúas si App Engine es adecuado para tu juego, es importante comprender que las instancias se pueden iniciar o detener según la tasa de consultas de los jugadores. Por lo tanto, los diseños de servicios no deberían planificar mantener el estado en la memoria entre solicitudes de usuarios. Si necesitas mantener el estado entre las solicitudes, debes almacenar y recuperar ese estado en una base de datos de almacenamiento de estado (que se explica en la siguiente sección) o usar una caché diferente como Memorystore (Memcached o Redis).
Es posible que las apps de App Engine requieran tiempo o recursos adicionales para ejecutarlas de manera eficiente en otros entornos de ejecución. Si necesitas un objetivo de entorno de ejecución único que se pueda implementar en entornos de nube híbrida o de múltiples nubes, te recomendamos Cloud Run o Google Kubernetes Engine.
Usa Cloud Run para apps nuevas sin servidores
Cloud Run te permite desarrollar una app nueva en contenedores para el backend del videojuego, sin tener que administrar clústeres de Kubernetes. Cloud Run puede realizar el ajuste de escala automático en tus contenedores de API para satisfacer las necesidades de solicitudes de tu base de jugadores. Ofrece muchos de los beneficios de App Engine, incluido un entorno de ejecución completamente administrado en el que se abstrae la infraestructura y el escalamiento se maneja de forma automática según la configuración que selecciones. Debido a que se compila en Knative, un estándar abierto, puede ser más sencillo escribir servicios portátiles cuando usas Cloud Run. Las apps de Cloud Run se ejecutan en contenedores en Kubernetes, lo que proporciona una ruta clara para migrar a Kubernetes autoadministrado si necesitas tener más control en el futuro.
Usa GKE para obtener un control total sobre tus cargas de trabajo
Google Kubernetes Engine es una opción para los desarrolladores que necesitan más control o que trabajan con equipos de operaciones experimentados. Si tus equipos ya usan Kubernetes para las pilas de apps, GKE les permite ejecutar el backend del videojuego junto con los servicios existentes, mediante la misma interfaz de Kubernetes y la interfaz de línea de comandos (CLI). Si tus equipos quieren ejecutar apps en varias nubes o de manera local, GKE proporciona una plataforma de destino única para las apps compiladas en la nube (apps nativas de la nube). Varios juegos se lanzaron con éxito a escala masiva en GKE, incluido Pokémon GO.
Bases de datos de almacenamiento de estado
Cuando selecciones la base de datos de tu juego para dispositivos móviles, debes considerar cómo escalar y administrar bases de jugadores cada vez más grandes, así como aumentar la complejidad de los juegos. Spanner y Firestore cuentan con muchas funciones, ofrecen una experiencia administrada y han probado historias de éxito de juegos para dispositivos móviles a gran escala. Google Cloud también ofrece Cloud SQL, una base de datos administrada de MySQL. Sin embargo, Cloud SQL puede ser difícil de escalar porque la fragmentación o el agrupamiento en clústeres de la base de datos manual puede presentar dificultades y complejidad significativas a tu capa de almacenamiento de estado, lo que genera un tiempo de inactividad no deseado y un impacto en el cliente.
Usa Spanner para videojuegos globales con intercambios entre usuarios
Spanner es una base de datos relacional completamente administrada con escalamiento ilimitado, coherencia sólida y disponibilidad de hasta el 99.999%. Incluye una semántica de SQL y una interfaz familiar para los desarrolladores que están acostumbrados a trabajar con bases de datos relacionales. Spanner se puede implementar a nivel mundial, pero se puede acceder a él de forma regional, por lo que tienes la simplicidad de una sola instancia de base de datos con el rendimiento de las réplicas distribuidas.
Spanner proporciona escalamiento infinito, por lo que funciona bien con los perfiles de jugador y el almacenamiento de inventario. También proporciona garantías de transacción que te permiten proporcionar una funcionalidad confiable de intercambio entre jugadores o de casa de subastas para tus clientes de juegos. Spanner proporciona varias herramientas de migración, desarrollo, observabilidad e introspección para la integración de desarrolladores y la administración de bases de datos. Spanner escala de forma gradual millones de consultas por segundo (QPS). Para un lanzamiento grande, como uno que espera más de 1,000 QPS el día 1, te recomendamos seguir las prácticas recomendadas de preparación y comparativas.
Spanner puede escalar a casos de uso de miles de millones de usuarios y proporciona la flexibilidad de administrar el escalamiento para cumplir con el rendimiento que necesitas. Spanner tiene un uso significativo en el espacio de juegos para dispositivos móviles. A fin de obtener información para usarlo en tu juego, consulta Prácticas recomendadas para usar Spanner como un base de datos de videojuegos.
Usa Firestore para lograr una velocidad de desarrollo y una sobrecarga operativa baja
Firestore es una base de datos de documentos NoSQL escalable y completamente administrada. Ofrece una experiencia optimizada para los desarrolladores y no requiere actualizaciones del esquema cuando deseas almacenar información nueva. También ofrece coherencia sólida, garantías transaccionales y disponibilidad de hasta el 99.999%. También se puede acceder a Firestore directamente desde el juego para dispositivos móviles que usa la biblioteca cliente de Firebase.
Un enfoque típico consiste en usar un solo documento de Firestore por jugador y almacenar todo el progreso en ese documento en una jerarquía que funcione bien con el diseño del juego. Cuando diseñes un juego para que use Firestore, ten en cuenta las limitaciones de Firebase y las prácticas recomendadas de Firestore. En función de estas prácticas recomendadas, es posible que las cargas de trabajo que requieren actualizaciones frecuentes en el mismo documento no sean adecuadas. Los videojuegos extremadamente grandes, como Pokémon GO, se iniciaron con Firestore (antes conocido como Datastore). Los videojuegos pudieron escalar para satisfacer la gran demanda de más de 50 veces el tráfico estimado del jugador.
Firestore puede controlar el escalamiento de forma automática. Sin embargo, a fin de garantizar un escalamiento sin problemas para los aumentos repentinos de uso (por ejemplo, después de una inversión de marketing importante), debes tener una conversación de planificación de capacidad con el administrador de cuentas de Google Cloud.
Vuelve a evaluar el almacenamiento en caché como una optimización del rendimiento
Si deseas optimizar el rendimiento, es una estrategia común de juegos para dispositivos móviles colocar una caché en memoria frente a la base de datos. La caché en la memoria contiene datos que se leen con frecuencia o agrupa en lotes actualizaciones de baja prioridad. Esta estrategia puede agregar complejidad de diseño a la arquitectura y, a menudo, no es necesaria con una base de datos administrada y escalable, como Spanner o Firestore, que pueda controlar las cargas de lectura y escritura. Si pruebas la carga de tus patrones de acceso a la base de datos y aún necesitas una caché, considera una opción administrada, como Memorystore para Redis o Memcached, a fin de reducir la sobrecarga de administración.
Selecciona una localidad de datos para satisfacer los requisitos de cumplimiento
Cuando se juegan en todo el mundo, muchos videojuegos deben cumplir con leyes de ubicación de datos, como GDPR. Para satisfacer las necesidades del GDPR, consulta Informe de Google Cloud y GDPR y selecciona la opción correcta Spanner o Configuración regional de Firestore.
Observabilidad
Te recomendamos que implementes la observabilidad con anticipación. La observabilidad de la infraestructura de la app y del backend es importante para encontrar y solucionar problemas con rapidez, permitir ciclos de desarrollo más rápidos y reducir el impacto del cliente cuando algo sale mal. Puedes ahorrar tiempo y dinero si adoptas un formato que funcione bien con Google Cloud Observability al comienzo del desarrollo.
Usa estándares de código abierto para llevar las métricas de tu app a Cloud Monitoring
Todos tus recursos de Google Cloud tienen instrumentación ya integrada en Cloud Monitoring y visible en la consola de Google Cloud. Por lo tanto, te recomendamos que instrumentes el backend del juego para dispositivos móviles a fin de integrarlo en Cloud Monitoring. La integración en Cloud Monitoring te permite usar un panel de supervisión de interfaz unificada (a veces llamada panel único) para tu infraestructura y app. El uso de una interfaz unificada te permite ver las métricas clave de la interfaz y la app en paralelo, y te ayuda a encontrar y aislar problemas con rapidez.
Cuando implementes métricas personalizadas y el seguimiento distribuido en tu app, te recomendamos usar OpenTelemetry, un proyecto gratuito de código abierto que antes se conocía como OpenCensus. OpenTelemetry proporciona compatibilidad con proveedores neutrales para recopilar métricas y seguimientos en muchos lenguajes y puede exportarlos a muchos productos de observabilidad, incluidos Cloud Monitoring y Cloud Trace. Para obtener más información, consulta Métricas personalizadas con OpenCensus.
Usa el registro estructurado
Cuando seleccionas un formato de registro, te recomendamos que uses el registro estructurado y ordenes las características interesantes de tus registros en campos JSON. Esta implementación te permite ordenar, buscar y filtrar con rapidez los registros en Cloud Logging. Muchos lenguajes de programación tienen bibliotecas o módulos de registro estructurados populares que se pueden exportar a Cloud Logging. Google Cloud también ofrece muchas bibliotecas cliente de Logging idiomáticas.
Crea un receptor de registros de BigQuery
Si necesitas analizar los registros más tarde o conservarlos debido a las leyes de retención de datos de la región en la que operas, configura un receptor de BigQuery para los registros con anticipación. Solo los registros nuevos que se generan después de crear un receptor se escriben en BigQuery. Si escribes grandes volúmenes de registros en BigQuery, te recomendamos que selecciones la opción para usar tablas particionadas.
Análisis
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 más fácil para que extraigas datos y puedas obtener estadísticas. Aunque puedes usar la extracción, transformación y carga (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. Te recomendamos que revises las presentaciones y los testimonios de Square Enix, King y LINE GAMES. Estas presentaciones pueden proporcionarte estadísticas reales sobre el uso de los productos de estadísticas de Google Cloud a fin de mejorar tus juegos para dispositivos móviles.
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 para 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.
Normaliza datos para el entrenamiento de modelos personalizados de AutoML Tables
Generar un modelo de AA eficaz generalmente requiere de una vasta experiencia en aprendizaje automático para seleccionar atributos 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 manejar 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, se necesita un formato diferente a fin de entrenar un modelo del AA. Un caso de uso común del AA en los juegos para dispositivos móviles es crear un modelo personalizado que prediga cuándo los jugadores gastarán dinero por primera vez en el juego. AutoML Tables puede simplificar en gran medida el proceso de entrenamiento. Si deseas obtener una descripción general, consulta Prepara los datos de entrenamiento y Prácticas recomendadas para crear datos de entrenamiento de AutoML Tables.
Varios estudios y publicadores de juegos obtuvieron excelentes resultados mediante el 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, y que contiene un recuento acumulativo de la cantidad de veces que el jugador activó el evento hasta ese día. En esta fila, se proporciona un resumen diario de todos los eventos potencialmente importantes que un jugador activó hasta el momento, 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, se le puede asignar una fila de lista diaria y proporcionar predicciones de las probabilidades de que el jugador realice una compra. Los enfoques similares a find de dar formato a los datos también se pueden usar junto con diferentes marcas a fin de entrenar modelos para hacer diferentes predicciones, incluida la deserción o cualquier otro comportamiento de los jugadores. Si realizas una inversión inicial en la compilación de formatos de datos normalizados, puedes probar los modelos con rapidez para predecir cualquier acción del jugador que puedas imaginar. Este modelado puede ayudarte a monetizar tu juego o priorizar características que produzcan resultados de los jugadores deseados.
Realiza estadísticas en la base de datos de videojuegos de Spanner
Spanner también permite que los administradores y los especialistas en estadísticas accedan a los datos sin afectar el tráfico de la base de datos del videojuego. La federación de BigQuery y Spanner permite que BigQuery consulte datos en Spanner en tiempo real, sin copiarlos ni moverlos. Spanner también admite la exportación de datos mediante plantillas de Dataflow que puedes analizar en Looker o en la consola de Google Cloud, o que puedes almacenar en otras plataformas de estadísticas que elijas.
Distribución, notificaciones y otros temas
El desarrollo de juegos para dispositivos móviles es un campo vasto y variado. Aunque todos los aspectos no se pueden abordar en una sola guía, en las siguientes secciones, se describen consideraciones importantes adicionales.
Usa Cloud CDN para distribuir los elementos de juego
Cloud CDN puede distribuir los elementos del juego a los clientes que usan dispositivos móviles. Tiene integraciones de Cloud Monitoring y Cloud Logging integradas. Si tienes una relación de proveedor existente, la mayoría de las CDN principales pueden usar Cloud Storage como un servidor de origen.
Reduce los comportamientos abusivos mediante reCAPTCHA
Aunque reCAPTCHA no es técnicamente parte de tu infraestructura de backend, puede ser una integración valiosa en tu cliente. Usa desafíos adaptables a fin de reducir las actividades abusivas en tu app y, en el caso de los juegos para dispositivos móviles, se suele usar para reducir la cantidad de registros de usuarios automatizados (bot). Para obtener más información, consulta la documentación de reCAPTCHA.
Notificación push a clientes con Firebase Cloud Messaging
Si tu juego para dispositivos móviles debe enviar notificaciones push o brindar a los usuarios la capacidad de intercambiar mensajes entre sí, considera usar Firebase Cloud Messaging (FCM). FCM es un servicio de mensajería multiplataforma que te permite enviar mensajes de forma segura y gratuita. También se puede usar para enviar mensajes de datos, lo que te permite determinar por completo lo que sucede en el código de tu app. Puedes escribir tu propia app de backend de mensajería o usar la Cloud Functions sin servidores para crear los mensajes y, luego enviarlos mediante el SDK de Firebase Admin o Protocolos de servidor FCM.
Simplifica la distribución de la configuración de juegos
Un enfoque común para el balanceo de juegos en juegos para dispositivos móviles es tener la mayoría de los parámetros de juego definidos en los datos. Luego, puedes distribuir de forma segura las actualizaciones a los clientes cuando necesites corregir parámetros como la tasa de caídas o estadísticas de ataque de armas. Firebase Remote Config está diseñado para que puedas cambiar el comportamiento y la apariencia sin que los usuarios descarguen una actualización de la app. Te permite definir valores predeterminados en tu app, que puedes anular para todos los segmentos o segmentos específicos de tu base de usuarios mediante Firebase console o de manera programática desde las API de backend de Remote Config.
Evalúa el AA para el balanceo de videojuegos
La investigación sobre el uso del AA para el balanceo de juegos generó varios casos de éxito que se presentaron en GDC y otros eventos. Muchos de estos casos de éxito provienen de soluciones personalizadas compiladas por ingenieros del AA y científicos de datos y no se pueden replicar con facilidad sin un equipo con experiencia. Si quieres evaluar el AA para el balanceo de videojuegos o como oponente de IA, las herramientas como AutoML Tables pueden ayudarte a experimentar con modelos personalizados sin necesidad de ser experto en AA. A fin de predecir el comportamiento de los jugadores, como su selección de elementos o siguientes movimientos, usa enfoques similares a los descritos antes en Normaliza datos para entrenamiento de modelos de AutoML Tables en este documento.
¿Qué sigue?
- Google Cloud para videojuegos
- Descripción general de la infraestructura de juegos en Cloud
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.