Neste documento, descrevemos as práticas recomendadas para executar um back-end de jogos para dispositivos móveis com base em API no Google Cloud. Este documento fornece uma referência que os desenvolvedores de jogos podem usar como ponto de partida para projetar uma arquitetura on-line para jogos para dispositivos móveis. As práticas recomendadas neste documento podem ser aplicadas a qualquer tipo de jogo para dispositivos móveis. No entanto, este documento se concentra nos jogos que armazenam informações de conta e progresso do jogador em um banco de dados e acessam esses dados por meio de uma API de interface personalizada criada pelos desenvolvedores do jogo.
Este documento é destinado a equipes que desenvolvem videogames para dispositivos móveis, como Pokemon Go da Niantic, Super Mario Run da Nintendo ou King's Candy Crush Saga. As práticas recomendadas neste documento não são para jogos de azar (jogos de cartas e jogos de cassino) ou apps de esportes de fantasia (por exemplo, futebol de fantasia), que geralmente são escalonados como um aplicativo da Web típico ou aplicativo social.
A natureza voltada para o hit de um jogo pode gerar grandes picos de demanda durante as horas de pico. Como seu app pode ser apresentado por uma loja de apps ou adotado pela comunidade de streaming, é importante considerar cenários de desastre e garantir que você tenha um caminho claro para o escalonamento quando um jogo se tornar popular. Tomar decisões informadas durante o desenvolvimento pode ajudar a minimizar riscos.
Estimar o carregamento esperado do usuário
Ao projetar o back-end on-line do seu jogo para dispositivos móveis, é importante ter uma estimativa aproximada da carga do usuário. Se você projetar sua arquitetura para usar a maioria dos recursos na carga esperada, ela poderá falhar se chamar a atenção da comunidade maior de jogadores e não puder ser escalonada para atender a essa demanda. O não escalonamento pode resultar em perda de oportunidades de receita e danos à reputação do seu estúdio. Pode ser um desafio projetar uma arquitetura que funcione bem na carga esperada, mas tem um caminho claro para uma escala muito maior se você tiver sucesso inesperado.
As estimativas de carga do usuário sempre são baseadas em muitos dados, mas há duas categorias essenciais para incluir:
- Número de jogadores e frequência das sessões de jogo: geralmente, é um palpite baseado no número de jogadores que jogam jogos semelhantes no mercado e no seu orçamento para adquirir usuários por meio de gastos de marketing.
- Carga da API causada por cada jogador: pode ser medida por meio de testes abrangentes de carga.
Fazer uma estimativa inicial
Ao fazer uma estimativa inicial, considere todos os fatores disponíveis, como os seguintes:
- Sucesso de jogos passados ou jogos semelhantes no mercado
- Popularidade de qualquer propriedade intelectual incluída (IP)
- Tempo de lançamento no mercado
- Número de pré-registros ou promoções cruzadas no restante do portfólio do seu app
- Orçamento de marketing
Depois de estimar o número de usuários, uma prática comum é criar um cenário de quatro vezes (4X) a melhor estimativa. No entanto, recomendamos que você considere um cenário de desastre em que um jogo se torne viral ou tenha um sucesso inesperado. Alguns estúdios aumentam a estimativa de usuários em 10 vezes (10x), mas os lançamentos anteriores de jogos no Google Cloud aumentaram a estimativa em 20 vezes (20x) ou até mesmo em40 vezes (40x) em circunstâncias extremas Mesmo que esses números sejam altamente improváveis, é importante calcular esses números e validar que sua arquitetura pode ser escalonada para esses níveis.
Executar um teste de carga
Saber o número esperado de usuários não é suficiente para entender as necessidades de escalonamento do jogo para dispositivos móveis. É fundamental executar testes de carga com condições o mais próximas possível das circunstâncias reais. Um teste de carga deve ser executado com testadores Beta fechados usando uma versão quase final do jogo. O teste de carga permite criar um perfil de desempenho do banco de dados de armazenamento de estado e da camada de API para garantir que haja espaço suficiente disponível. Usuários reais geralmente podem criar padrões de uso que os desenvolvedores não conseguem prever. Portanto, é importante ter algum perfil de uso de jogador ativo para usar como modelo para testes de carga em grande escala. Recomendamos que você use uma estrutura de teste de carga para replicar os padrões de usuário do teste Beta na escala determinada pela estimativa inicial calculada na seção anterior.
Ao executar um teste de carga em grande escala, entre em contato com a equipe de vendas do Google Cloud e registre um tíquete adequado do Cloud Customer Care para o período em que você planeja realizar o teste de estresse. O registro do tíquete de atendimento ao cliente permite que a equipe solicite proativamente o aumento das cotas quando necessário. Ele também ajuda a garantir que um engenheiro de atendimento ao cliente esteja disponível para responder às suas perguntas caso um produto do Google Cloud não tenha o comportamento esperado.
Validar na arquitetura de referência
O diagrama a seguir fornece uma arquitetura de referência para as práticas recomendadas neste documento:
No diagrama anterior, os clientes do jogo se conectam ao back-end do jogo para dispositivos móveis por meio de um balanceador de carga. O back-end tem uma conexão direta com seu banco de dados de registros do jogador, com uma camada de cache de alta velocidade opcional à frente, que armazena e recupera o progresso do jogador, direitos e outros dados. O back-end emite métricas e registros de operações para o Google Cloud Observability. As métricas e os registros são essenciais para monitorar o desempenho de back-end e também podem ser acessados pelo armazenamento de dados. Os especialistas em análise podem acessar diretamente o armazenamento de dados usando o BigQuery, e o AutoML pode ser usado para gerar modelos usados para prever gastos e desligamento de usuários. Essas previsões podem ser disponibilizadas para o back-end do jogo. Os componentes a seguir são descritos em detalhes posteriormente neste documento:
- Computação usada para APIs voltadas para o cliente
- Banco de dados usado para armazenamento de estado
- Monitoramento e observabilidade do Google Cloud Observability
- Análise
Alguns jogos para dispositivos móveis oferecem multijogador em tempo real usando um servidor de jogos dedicado ou servidores TURN/STUN. As práticas recomendadas neste documento não incluem explicitamente esses servidores, mas são compatíveis com servidores de jogos.
Opções do Compute
O Google Cloud oferece várias opções de computação para o back-end de jogos para dispositivos móveis, desde opções totalmente gerenciadas e escalonáveis, como o App Engine, até ambientes totalmente personalizáveis, como o Google Kubernetes Engine (GKE). É importante entender suas necessidades em detalhes e decidir de acordo. Todas as opções nas seções a seguir oferecem integração total com o Cloud Load Balancing para que seu tráfego HTTP(S) possa aproveitar o escalonamento contínuo. As opções também incluem recursos do Google Cloud Armor, como proteção contra DDoS de nível empresarial.
Use o App Engine para servidor sem servidor escalonável comprovado
O App Engine é a plataforma sem servidor totalmente gerenciada do Google Cloud que permite que você se concentre em escrever o código sem precisar gerenciar a infraestrutura subjacente. É possível configurar o App Engine para escalonar de acordo com as necessidades do seu jogo. Ele também permite tempos de iteração mais rápidos para seus desenvolvedores criando e implantando diretamente da fonte com um único comando. O App Engine é a escolha ideal para equipes pequenas ou com pouca experiência no escalonamento de operações de infraestrutura. É comprovado em escala por meio de vários lançamentos de jogos para dispositivos móveis, incluindo lançamentos da Nintendo, do Madfinger Games, Pocket Gems e Backflip Studios.
Ao avaliar se o App Engine é adequado para seu jogo, é importante entender que as instâncias podem ser iniciadas ou interrompidas com base na taxa de consulta dos jogadores. Portanto, os designs de serviço não devem planejar manter o estado na memória entre as solicitações do usuário. Se for necessário manter o estado entre as solicitações, armazene e recupere esse estado em um banco de dados de armazenamento de estado (discutido na próxima seção) ou use um cache separado, como Memorystore (Memcached ou Redis).
Os aplicativos do App Engine podem exigir tempo ou recursos extras para que sejam executados com eficiência em outros ambientes de execução. Se você precisar de um único destino de ambiente de execução que possa ser implantado em ambientes de nuvem híbrida ou de várias nuvens, recomendamos o Cloud Run ou o Google Kubernetes Engine.
Usar o Cloud Run para novos apps sem servidor
O Cloud Run permite desenvolver um novo aplicativo em contêineres para o back-end do jogo, sem precisar gerenciar clusters do Kubernetes. O Cloud Run pode escalonar automaticamente seus contêineres de API para atender às necessidades de solicitação da sua base de jogadores. Ele oferece muitos dos benefícios do App Engine, incluindo um ambiente de execução totalmente gerenciado em que a infraestrutura é abstraída e o escalonamento é tratado automaticamente de acordo com a configuração selecionada. Como é baseado no Knative padrão aberto, pode ser mais simples gravar serviços portáteis quando você usa o Cloud Run. Os aplicativos do Cloud Run são executados em contêineres no Kubernetes, que fornece um caminho claro para a migração para o Kubernetes autogerenciado, se você precisar de mais controle no futuro.
Use o GKE para controle total sobre a carga de trabalho
O Google Kubernetes Engine é uma opção para desenvolvedores que precisam de mais controle ou que trabalham com equipes de operações experientes. Se as equipes já usam o Kubernetes para as pilhas de aplicativos, o GKE permite que elas executem o back-end do jogo junto com os serviços atuais, usando a mesma interface do Kubernetes e interface de linha de comando (CLI). Se as equipes quiserem executar aplicativos em várias nuvens ou no local, o GKE fornecerá uma plataforma de destino único para aplicativos criados para a nuvem (aplicativos nativos da nuvem). Vários jogos foram lançados com sucesso em grande escala no GKE, incluindo o Pokémon GO.
Bancos de dados estaduais
Ao selecionar o banco de dados para seu jogo para dispositivos móveis, você precisa considerar como escalonar e gerenciar a base crescente de jogadores e a complexidade do jogo. O Cloud Spanner e o Firestore são ricos em recursos, oferecem uma experiência gerenciada e têm histórias de sucesso comprovadas em jogos para dispositivos móveis em escala. O Google Cloud também oferece o Cloud SQL, um banco de dados MySQL gerenciado. No entanto, o Cloud SQL pode ser um desafio de escalonamento porque a fragmentação ou o clustering manual do banco de dados pode causar uma complexidade e complexidade significativas. à camada de armazenamento de estado, levando a tempo de inatividade indesejado e impacto ao cliente.
Use o Cloud Spanner para jogos globais com o comércio entre usuários
O Cloud Spanner é um banco de dados relacional totalmente gerenciado com escala ilimitada, consistência forte e disponibilidade de até 99, 999%. Ele apresenta a semântica do SQL e uma interface familiar para desenvolvedores acostumados a trabalhar com bancos de dados relacionais. O Cloud Spanner pode ser implantado globalmente, mas acessado regionalmente. Portanto, você tem a simplicidade de uma única instância de banco de dados com o desempenho das réplicas distribuídas.
O Cloud Spanner oferece uma escala infinita e, portanto, funciona bem nos perfis de jogadores e no armazenamento de inventário. Ele também oferece garantias de transação que permitem a você oferecer uma funcionalidade confiável de troca entre jogadores ou de leilão para os clientes do seu jogo. O Cloud Spanner fornece várias ferramentas para migração, desenvolvimento, observabilidade e introspecção para integração de desenvolvedores e administração de bancos de dados. O Cloud Spanner escalona gradualmente para milhões de consultas por segundo (QPS, na sigla em inglês). Para um grande lançamento, como um que espera mais de 1.000 QPS no dia 1, recomendamos seguir as práticas recomendadas de aquecimento e comparativo de mercado.
O Cloud Spanner pode ser escalonado para bilhões de casos de uso de usuários e oferece a flexibilidade de gerenciar a escala para atender ao desempenho necessário. O Cloud Spanner tem um uso significativo no espaço de jogos para dispositivos móveis. Para informações sobre como usá-lo no seu jogo, consulte Práticas recomendadas para usar o Cloud Spanner como um banco de dados de jogos.
Use o Firestore para velocidade de desenvolvimento e baixa sobrecarga operacional
O Firestore é um banco de dados de documentos NoSQL escalonável e totalmente gerenciado. Ele oferece uma experiência otimizada para desenvolvedores e não exige atualizações de esquema quando você quer armazenar novas informações. Ele também oferece consistência forte, garantias transacionais e disponibilidade de até 99,999%. O Firestore também pode ser acessado diretamente de seu jogo para dispositivos móveis que usa a biblioteca de cliente do Firebase.
Uma abordagem típica é usar um único documento do Firestore por jogador e armazenar todo o progresso nesse documento em uma hierarquia que funcione bem com o design do jogo. Ao projetar um jogo para usar o Firestore, considere as limitações do Firebase e as práticas recomendadas do Firebase. Com base nessas práticas recomendadas, as cargas de trabalho que exigem atualizações frequentes do mesmo documento podem não ser adequadas. Jogos de alta escala, como o Pokémon GO, foram lançados com sucesso usando o Firestore (anteriormente conhecido como Datastore). Os jogos conseguiram escalonar para atender à enorme demanda de mais de 50 vezes o tráfego estimado do jogador.
O Firestore pode lidar com o escalonamento automaticamente. No entanto, para garantir um escalonamento suave para aumentos repentinos no uso (por exemplo, após um grande gasto com marketing), é necessário ter uma conversa de planejamento de capacidade com antecedência com o gerente da sua conta do Google Cloud.
Reavalie o armazenamento em cache como uma otimização de desempenho
Para otimizar o desempenho, é comum que uma estratégia de jogos para dispositivos móveis coloque um cache na memória na frente do banco de dados. O cache na memória contém dados que são lidos com frequência ou agrupa atualizações de baixa prioridade. Essa estratégia pode adicionar complexidade de design à arquitetura e, muitas vezes, não é necessária com um banco de dados escalonável e gerenciado, como o Cloud Spanner ou o Firestore, que pode processar as cargas de leitura e gravação. Se você testar a carga dos padrões de acesso ao banco de dados e ainda precisar de um cache, considere uma opção gerenciada, como o Memorystore para Redis ou o Memcached, para reduzir a sobrecarga de administração.
Selecionar uma localidade de dados para atender aos requisitos de conformidade
Quando jogados em todo o mundo, muitos jogos precisam cumprir as leis regionais de dados, como o GDPR. Para ajudar a atender às suas necessidades do GDPR, consulte o artigo sobre o Google Cloud e o GDPR e selecione a configuração regional correta do Cloud Spanner ou do Firestore.
Observabilidade
Recomendamos que você implemente a observabilidade antecipadamente. A observabilidade do aplicativo e da infraestrutura de back-end é importante para encontrar e corrigir problemas rapidamente, permitindo ciclos de desenvolvimento mais rápidos e reduzindo o impacto no cliente quando algo dá errado. Você pode economizar tempo e dinheiro adotando um formato que funcione bem com o Google Cloud Observability no início do desenvolvimento.
Use padrões de código aberto para inserir as métricas do seu app no Cloud Monitoring
Todos os recursos do Google Cloud têm a instrumentação já integrada ao Cloud Monitoring e visível no Console do Google Cloud. Portanto, recomendamos que você também instrumente o back-end de jogos para dispositivos móveis para se integrar ao Cloud Monitoring. A integração com o Cloud Monitoring permite usar um painel de monitoramento de interface unificada (às vezes chamado de painel único) para sua infraestrutura e seu aplicativo. O uso de uma interface unificada permite visualizar as principais métricas da interface e do aplicativo lado a lado e ajuda a encontrar e isolar problemas rapidamente.
Ao implementar métricas personalizadas e rastreamento distribuído no aplicativo, recomendamos que você use o OpenTelemetry, um projeto gratuito de código aberto conhecido anteriormente como OpenCensus. A OpenTelemetry oferece suporte neutro para o fornecedor para coletar métricas e traces em vários idiomas, além de exportá-los para muitos produtos de observabilidade, incluindo o Cloud Monitoring e o Cloud Trace. Para mais informações, consulte Métricas personalizadas com o OpenCensus.
Usar a geração de registros estruturados
Ao selecionar um formato de geração de registros, recomendamos que você use o registro estruturado e classifique todos os recursos interessantes dos registros em campos JSON. Essa implementação permite classificar, pesquisar e filtrar rapidamente os registros no Cloud Logging. Muitas linguagens de programação têm bibliotecas ou módulos de geração de registros estruturados conhecidos que podem ser exportados para o Cloud Logging. O Google Cloud também oferece muitas bibliotecas de cliente idiomáticas do Logging.
Criar um coletor de registros do BigQuery
Se você precisar analisar seus registros posteriormente ou mantê-los devido às leis de retenção de dados da região em que trabalha, configure um coletor do BigQuery para os registros com antecedência. Somente registros novos gerados após a criação de um coletor são gravados no BigQuery. Se você estiver gravando grandes volumes de registros no BigQuery, recomendamos selecionar a opção de usar tabelas particionadas.
Análise
Recomendamos que você formate sua análise para o futuro. Ao decidir quais eventos e métricas seu jogo gravará no back-end de análise, considere o formato mais fácil para extrair dados para receber insights. Embora seja possível usar extrair, transformar e carregar (ETL, na sigla em inglês) para copiar os dados que seu aplicativo grava em um formato que funciona bem para consultas de análise, pode levar algum tempo. e dinheiro para fazer isso. Investir no design do seu formato de saída de análise pode gerar uma economia significativa e a possibilidade de insights de análise em tempo real. Recomendamos que você revise apresentações e depoimentos de Square Enix ,King eLINE GAMES. Essas apresentações podem fornecer insights reais sobre como usar os produtos de análise do Google Cloud para melhorar seus jogos para dispositivos móveis.
Usar processamento em lote para formatos existentes
Para analisar dados de métricas que estão em um formato de saída que você não controla (por exemplo, dados de uma integração ou serviço de terceiros), recomendamos começar salvando os dados das métricas em Cloud Storage Se o formato de dados for compatível, será possível consultá-lo diretamente da interface do BigQuery usando consultas federadas do BigQuery. Se o formato de dados não for compatível, use ETL para copiar os dados do Cloud Storage usando o Dataflow ou outras ferramentas e, em seguida, armazene os dados formatados resultantes no BigQuery junto com os dados de outras fontes. Recomendamos que você configure um job em lote regular para economizar custos em vez de fazer streaming, a menos que tenha uma necessidade urgente de dados em tempo real. Para mais informações sobre essa abordagem, consulte Como otimizar a ingestão em grande escala de eventos e registros de análise.
Preveja o desligamento e os gastos com modelos comprovados
Talvez você já use o Firebase no seu jogo para dispositivos móveis em um dos muitos recursos a seguir, como Configuração remota ,mensagens no app ouBibliotecas de cliente do Firestore , O Firebase também oferece modelos integrados de desligamento de usuários e machine learning (ML) de previsão de gastos. É possível integrar a personalização da Configuração remota para aplicar ML aos seus dados de análise, o que pode criar segmentos de usuários dinâmicos com base no comportamento previsto dos usuários. Esses dados podem ser usados para acionar outros recursos do Firebase ou exportados para o BigQuery para ter mais flexibilidade.
Normalizar dados para o treinamento de modelos personalizados do AutoML Tables
Para gerar um modelo de ML eficaz, normalmente é necessário ter ampla experiência em machine learning para selecionar recursos relevantes e ajustar hiperparâmetros. No entanto, seguir as diretrizes de preparação de dados melhora a capacidade das ferramentas automatizadas mais recentes de lidar com essas tarefas para você e gerar um modelo útil em seu nome. Depois que um modelo é gerado, ele pode ser hospedado no Google Cloud para fazer predições on-line ou em lote, por exemplo, prever se um jogador fará uma compra no jogo ou deixará de jogar.
Os eventos de análise e os dados do jogador são úteis para consultas de análise tradicionais e métricas de business intelligence, mas um formato diferente é necessário para treinar um modelo de ML. Um caso de uso comum do ML em jogos para dispositivos móveis é criar um modelo personalizado para prever quando os jogadores gastarão dinheiro no jogo pela primeira vez. O AutoML Tables pode simplificar muito o processo de treinamento. Para uma visão geral, consulte a documentação do AutoML Tables Como preparar os dados de treinamento e as Práticas recomendadas para criar dados de treinamento.
Vários estúdios e editores de jogos viram ótimos resultados usando um formato de divisão diária como base para o treinamento. Um agrupamento diário é um formato de linha normalizado que tem um campo para cada evento de análise significativo, contendo uma contagem cumulativa do número de vezes que o jogador acionou o evento até esse dia. Essa linha fornece um snapshot diário de todos os eventos potencialmente importantes que um jogador acionou até o momento, além de uma sinalização has made
a purchase verdadeira ou falsa.
O processo descrito na documentação do guia de início rápido do AutoML Tables pode resultar em modelos de alta qualidade ao treinar com dados formatados dessa maneira. O modelo pode receber uma linha de visualização completa diariamente e fornecer previsões da probabilidade de o jogador fazer uma compra. Abordagens semelhantes para formatação de dados também podem ser usadas com diferentes sinalizações para treinar modelos e fazer previsões distintas, incluindo desligamento de usuários ou outros comportamentos do jogador. Fazer um investimento antecipado na criação de formatos de dados normalizados pode ajudar você a testar modelos rapidamente para prever qualquer ação que você possa imaginar. Essa modelagem pode ajudar você a gerar receita com seu jogo ou priorizar recursos que resultam em resultados de jogador desejados.
Como realizar análises no banco de dados de jogos do Cloud Spanner
O Cloud Spanner também permite que administradores e especialistas em análise acessem dados sem afetar o tráfego do banco de dados do jogo. A federação BigQuery-Spanner permite que o BigQuery consulte dados que residem no Spanner em tempo real, sem copiar ou mover dados. O Cloud Spanner também oferece suporte à exportação de dados com modelos do Dataflow que podem ser analisados no Looker, no Console do Google Cloud ou armazenados em outras plataformas de análise de sua escolha.
Distribuição, notificações e outros tópicos
O desenvolvimento de jogos para dispositivos móveis é um campo grande e variado. Nem todos os aspectos podem ser abordados em um guia, mas as seções a seguir descrevem outras considerações importantes.
Usar o Cloud CDN para distribuir os recursos do seu jogo
O Cloud CDN pode distribuir recursos do jogo para clientes de dispositivos móveis e tem integrações integradas ao Cloud Monitoring e ao Cloud Logging. Se você já tiver uma relação de fornecedor, a maioria das CDNs importantes poderá usar o Cloud Storage como um servidor de origem.
Reduza comportamentos abusivos usando o reCAPTCHA
Embora o reCAPTCHA não seja tecnicamente uma parte da sua infraestrutura de back-end, ele pode ser uma integração valiosa em seu cliente. Ele usa desafios adaptáveis para reduzir atividades abusivas no app e, para jogos para dispositivos móveis, muitas vezes é usado para reduzir o número de registros de usuário automatizados (bot). Para mais informações, consulte a documentação reCAPTCHA.
Notificação push para clientes com o Firebase Cloud Messaging
Se seu jogo para dispositivos móveis precisar enviar notificações push ou oferecer aos usuários a capacidade de trocar mensagens, considere usar o Firebase Cloud Messaging (FCM). O FCM é um serviço de mensagens entre plataformas que permite a entrega confiável de mensagens sem custo. Ele também pode ser usado para enviar mensagens de dados, o que permite determinar completamente o que acontece no código do app. Você pode escrever seu próprio aplicativo de back-end de mensagens ou usar sem servidorCloud Functions criar as mensagens e enviá-las usando oSDK Admin do Firebase ou oProtocolos do servidor FCM.
Simplifique a distribuição de configurações de jogos
Uma abordagem comum para o balanceamento de jogos em jogos para dispositivos móveis é ter a maioria dos parâmetros de jogabilidade definidos nos dados. Depois disso, é possível distribuir as atualizações com segurança aos clientes quando você precisar corrigir parâmetros como uma taxa de queda ou estatísticas de ataque de arma. A Configuração remota do Firebase foi projetada para permitir que você altere o comportamento. e a aparência do seu app sem exigir que os usuários façam o download de uma atualização. Ele permite que você defina valores padrão no seu aplicativo, que podem ser substituídos para todos os segmentos ou segmentos específicos da sua base de usuários usando o Console do Firebase ou programaticamente a partir das APIs de back-end do Configuração remota.
Avaliar o ML para equilibrar o jogo
A pesquisa sobre o uso do ML para o equilíbrio de jogos gerou vários estudos de caso bem-sucedidos apresentados no GDC e outros eventos. Muitos desses estudos de caso vêm de soluções personalizadas criadas por cientistas de dados e engenheiros de ML e não podem ser facilmente replicados sem uma equipe experiente. Se você quiser avaliar o ML para o equilíbrio do jogo ou como oponente da IA, ferramentas como o AutoML Tables poderão ajudá-lo a testar modelos personalizados sem ter experiência com ML. Para prever comportamentos do jogador, como a seleção de itens ou os próximos movimentos, use abordagens semelhantes às descritas em Normalizar dados para treinamento de modelo do AutoML Tables anteriormente neste documento.
A seguir
- Google Cloud para jogos
- Visão geral da infraestrutura de jogos em nuvem
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.