​

Consumo do PlayFab: práticas recomendadas

Com o modelo de preços baseado em consumo do PlayFab, você paga apenas pelo uso real do serviço pelos seus títulos. Mas isso levanta uma pergunta óbvia: qual é a melhor maneira de otimizar esses títulos para economizar dinheiro e, ao mesmo tempo, implementar todos os recursos de que você precisa? Neste documento, vamos nos aprofundar nesses detalhes e falar sobre práticas recomendadas que ajudarão você a planejar com antecedência. Antes de mover seus títulos do modo de desenvolvimento para o modo ao vivo, você pode revisar as informações dos medidores na guia Billing Summary do Game Manager. Há seis medidores de consumo: Events, Profile, Content and Configuration, CloudScript, Insights e Multiplayer Services. A melhor maneira de começar a otimizar um título é examinar cada um dos medidores que ele usa e ver como eles se acumulam ao longo do tempo. Isso permite identificar rapidamente algumas melhorias óbvias. Para obter mais informações sobre os medidores, consulte Medidores de preços.

​

Eventos

Há dois tipos de eventos no PlayFab: PlayStream e telemetria. O PlayFab processa os eventos do PlayStream para verificar se eles disparam as ações do PlayStream que você definiu e para atualizar a segmentação de usuários. Alguns eventos do PlayStream são gerados automaticamente como resultado de chamadas a recursos do serviço, como autenticação e atualizações de estatísticas. Os títulos podem gerar seus próprios eventos personalizados para estender essa funcionalidade. Os eventos de telemetria não são processados pelo PlayStream. Esses eventos são usados para análise e vão diretamente para o data warehouse. Os eventos de telemetria não são gerados automaticamente no PlayFab; eles são eventos personalizados gerados pelo título. Para ambos os tipos de evento, cargas de dados maiores aumentam a quantidade total de uso do medidor. Você pode reduzir esse uso geral garantindo que está enviando apenas os dados de que precisa. Uma orientação aproximada é que qualquer evento incrementa o medidor em questão em 1 para cada 1 KB de dados no corpo do evento. Para escolher qual caminho de eventos é mais adequado ao seu uso, você deve ter um plano claro de como pretende usar cada evento personalizado que gerar. Os eventos necessários apenas para a avaliação offline do título devem seguir o caminho da telemetria. Isso pode ajudar a reduzir significativamente os custos, pois as cobranças de excedente dos eventos de telemetria são menos da metade das do PlayStream. Se você estiver usando um dos SDKs predefinidos, é importante lembrar que alguns dados de análise sobre o comportamento dos usuários são gerados automaticamente, conforme descrito na referência do modelo de eventos do PlayStream. Para desativar os eventos opcionais, altere a configuração de análise na guia Settings/Data Collection do seu jogo no PlayFab Game Manager. Da mesma forma, embora seja uma boa ideia manter a opção “generate PlayStream event” ativada para as execuções do CloudScript durante a depuração, desative-a antes de colocar o jogo no ar. No caso de CloudScripts disparados por ações do PlayStream, você sempre pode ativá-la mais tarde, se precisar depurar algum comportamento em produção.

​

Perfil

O perfil é, na prática, “tudo sobre o jogador”, incluindo elementos comuns como inventário, dados salvos e estatísticas. Ele também contém as metainformações que você usa para oferecer experiências exclusivas por meio dos recursos de LiveOps do PlayStream, como a segmentação de usuários mencionada acima. Além disso, alguns recursos legados no nível do título, como dados de título, catálogos e lojas, estão incluídos neste medidor, pois sua implementação de dados é, na prática, igual à dos dados do usuário. Como esse conjunto de medidores é impulsionado por todas as ações dos jogadores e pelas ações executadas nos jogadores, ele é, de longe, o que mais precisa de planejamento de otimização. Os principais fatores que contribuem para o uso capturado pelos medidores de preços são a quantidade de dados lidos, armazenados e gravados e a frequência com que você chama as APIs que geram dados medidos. Para obter mais informações sobre as chamadas de API específicas que fazem esses medidores “girar”, consulte Medidores de preços. Começaremos pelos dados do usuário e pelas estatísticas, pois seus padrões de uso são semelhantes, e depois falaremos sobre o gerenciamento do inventário do jogador.

​

Dados e estatísticas

Ao avaliar seu uso dos dados do usuário, a mesma lógica de aproximação dos eventos se aplica (cada 1 KB aumenta a contagem do medidor em 1), mas lembre-se de que cada “elemento” de uma chamada deve ser considerado distinto para fins desse cálculo. Cada par de chave-valor em uma chamada para atualizar os dados do usuário é contado separadamente. Para leituras, esse cálculo de 1 KB se aplica ao total de dados retornados, independentemente do número de pares de chave-valor. Isso significa que gravar 10 chaves de 100 bytes cada equivale a 10 “tiques” do medidor de gravação de perfil, pois cada gravação de par de chave-valor tem no mínimo 1 KB, enquanto uma leitura dessas 10 chaves equivale a 1 “tique”, pois o total é de 1 KB. Para obter detalhes mais específicos sobre os usos, consulte Medidores de preços. As estatísticas são um pouco mais complexas, pois atualizam o perfil e também podem afetar os placares. Como regra geral, você pode considerar cada estatística atualizada como uma atualização completa do perfil, enquanto as leituras se baseiam no tamanho total dos dados lidos em cada chamada. E, como o armazenamento é cobrado por gigabyte (GB) e as estatísticas normalmente consomem apenas alguns bytes cada, vamos nos concentrar nas leituras e gravações. Como o tamanho total dos dados é importante, otimizá-lo é a primeira etapa. Felizmente, há uma ampla variedade de técnicas conhecidas para isso: usar enumerações ou IDs no lugar de texto por extenso para itens, empacotar dados grandes em formato binário ou até usar campos de bits para compactar dados em espaços menores. Depois disso, a próxima etapa é avaliar cuidadosamente quando você precisa fazer essas chamadas de leitura e gravação. Se você vem do desenvolvimento para PC ou console, especialmente de jogos para um jogador, esse pode ser um padrão novo. Mas, nesses ambientes, você precisa ter cuidado com o consumo de recursos e a coleta de lixo no dispositivo cliente, pois eles podem causar degradação de desempenho em momentos críticos. Quando seu título usa recursos que estão na nuvem, é necessário estender essa lógica para considerar que cada uso de recurso tem um custo real, além de um custo de desempenho. Como determinar a frequência ideal de leituras e gravações? Duas das preocupações mais comuns dos desenvolvedores que desejam atualizar dados e estatísticas com mais frequência são a proteção contra trapaças e o armazenamento oportuno de informações no lado do servidor, seja para interações entre jogadores ou para evitar a perda de dados se o jogo for encerrado inesperadamente.

​

Proteção contra trapaças

Embora possa parecer que você precisa atualizar constantemente os dados de back-end para garantir a segurança essencial, atualizações frequentes raramente são necessárias se o seu jogo não exigir um controle totalmente autoritativo da sessão no servidor. Para começar, a pergunta fundamental é quanta segurança você realmente precisa. Para alguns jogos, especialmente aqueles que monetizam principalmente por meio de anúncios no jogo e não têm placares, trapaças não são uma grande preocupação. Nesse caso, confiar nos dados enviados pelo cliente costuma ser uma abordagem viável, pois a segurança desses dados não é realmente uma preocupação. Para identificar comportamentos de trapaça e decidir como tratá-los, recomendamos implementar processos para revisar os eventos, os dados e as estatísticas dos seus jogadores. Para outros jogos, nos quais você precisa preservar a integridade da competição ou proteger a experiência geral dos jogadores, uma segurança mais forte é mais importante. Dependendo dos seus requisitos específicos, determinadas abordagens podem reduzir a frequência de leituras e gravações de dados nessas situações. Se o seu jogo não for em tempo real, uma abordagem que recomendamos é agregar as informações sobre o jogo do jogador durante um período (geralmente uma “rodada” do jogo, que leva vários minutos) e, em seguida, enviar esses dados a um script que determina se eles são válidos. Os elementos principais a serem avaliados podem depender do jogo, mas alguns exemplos de conceitos comuns a considerar são:

• Quanto tempo se passou desde o último relatório de sessão e quanto tempo o cliente diz ter jogado na sessão mais recente?
• Quais pontuações o jogador registrou e elas são razoáveis para esse jogador, considerando seu nível, equipamento etc.?

Para jogos com requisitos mais próximos do tempo real, como a necessidade de atualizar com frequência o estado do jogador autoritativo no servidor, uma solução melhor do que atualizações frequentes dos dados armazenados no PlayFab é usar servidores de jogo hospedados. Nesse modelo, você conecta o jogador a um servidor no início da sessão. O servidor lê todos os dados necessários do serviço para o jogador e, em seguida, hospeda o estado da simulação desse jogador ao longo do tempo, com o cliente trocando dados com o servidor na taxa de que você precisar. Depois, o servidor atualiza o “armazenamento de longo prazo” no PlayFab com os dados mais recentes do jogador, seja no final de uma sessão ou a cada poucos minutos, se suas sessões forem particularmente longas. Esse é o modelo usado por jogos multijogador em tempo real. Também é uma técnica válida para títulos de um jogador que exigem verificações autoritativas no servidor, embora, se essa frequência for de apenas algumas vezes por minuto por jogador, o CloudScript com o Azure Functions possa ser a melhor opção. O custo total do CloudScript é fácil de calcular. É o total de gigabytes-segundos que você consome, com um mínimo de 128 MB e 100 ms por execução, mais os cálculos normais de quaisquer outras chamadas de API do serviço usadas pelo script. Por exemplo, se você tiver uma ocupação total de memória de 250 MB, somando o código do script e o uso de variáveis no script, precisaria executar esse script por 4 segundos (provavelmente entre vários usuários) para chegar a 1 GB/s. E, dentro desse código de script, se você ler ou gravar objetos de entidade, dados de título, dados do usuário etc., precisará calcular o efeito de cada uma dessas chamadas nos medidores de perfil. Como os custos dos servidores de jogo hospedados dependem de quantos servidores você está executando, e isso, por sua vez, depende de quantos jogadores podem ser hospedados em um servidor por vez, não é necessariamente trivial determinar onde está o ponto de equilíbrio entre os dois. Mas, se você perceber que precisa chamar seus scripts com alta frequência e precisa ler e gravar dados do serviço a cada vez, é muito provável que uma solução de servidor de jogo seja o melhor caminho.

​

Atualidade dos dados

Um tema comum que ouvimos entre desenvolvedores com altas taxas de gravação de perfil é a preocupação com a perda de progresso do jogador. Se o jogador sair do jogo antes que ele possa salvar e o estado local não puder ser usado na próxima vez que o jogo for jogado, ou se esse estado precisar ser transferido entre dispositivos, você vai querer que as informações de estado do jogador armazenadas no PlayFab estejam o mais atualizadas possível. Para muitos jogos, você pode resolver esse problema com uma pulsação regular e pouco frequente de atualizações para o serviço (a cada 15 minutos, por exemplo). Mas incluir uma lógica extra para aumentar ou diminuir essa frequência também pode ajudar. Por exemplo:

• Inclua uma substituição de “atualização importante” que cause uma gravação imediata e redefina o temporizador se o jogador fizer ativamente algo significativo, para que isso não seja perdido.
• Se o seu jogo continuar progredindo sem a interação do jogador, considere aumentar o período de pulsação se não houver interação por muito tempo. Isso é especialmente importante em jogos idle, que os jogadores costumam deixar em execução durante a noite.
• Dê aos jogadores uma forma de forçar uma atualização diretamente, como um botão em um menu do usuário. Nesse caso, porém, limite a taxa com que as chamadas são realmente feitas do dispositivo cliente para o PlayFab, para que um jogador que pressione esse botão repetidamente não gere uma chamada a cada vez.

Se o cliente tiver as informações de estado na próxima vez que o jogo for jogado, você poderá comparar o carimbo de data/hora local com o dos dados do serviço e decidir qual usar, ou até mesmo dar ao jogador a opção de escolher. As informações de perfil de um jogador podem ser relevantes não apenas para ele mesmo. Em alguns jogos, talvez você precise consultá-las entre jogadores, seja para estimular a competição ou para influenciar diretamente a experiência do jogador por meio de interações assíncronas com amigos, desafios e assim por diante. Para a competição, os placares são uma forma ideal de gerar essa tensão, compartilhando um subconjunto de informações sobre outros jogadores (geralmente aqueles próximos à pontuação do jogador atual) por meio de uma única chamada ao serviço. Como é possível retornar outros elementos do perfil, como estatísticas e marcas, usando as restrições de exibição de perfil, você pode apresentar um conjunto rico de informações sobre esses outros jogadores. Mas é importante não iterar pela lista de todos os jogadores do placar tentando ler informações adicionais de cada um, pois isso multiplicaria rapidamente o número total de leituras de perfil, aumentando seus custos. Para jogos que usam dados entre jogadores diretamente na sessão, a otimização mais comum é ler apenas as informações dos poucos jogadores específicos com os quais o jogador local está interagindo. Em jogos de ação em tempo real, isso geralmente é feito no servidor que hospeda a sessão. Em outros, como jogos em que os jogadores podem atacar as bases uns dos outros, as abordagens mais comuns são ler todos esses dados no dispositivo local ou enviar ao jogador local apenas o subconjunto dos dados do outro jogador que o jogador local deve conhecer. Os jogos que adotam a primeira abordagem usam lógica no lado do servidor para avaliar os resultados finais enviados pelo cliente. Os jogos que adotam a segunda atualizam os dados de forma iterativa ao longo da sessão com mais dados, quando o jogador local deve ter acesso a eles. Mas, mesmo assim, também usam lógica no lado do servidor para avaliar os resultados finais. Novamente, o fator decisivo para definir se isso deve ser feito por script ou em um servidor hospedado é a frequência. Se for mais do que algumas vezes por minuto, é melhor usar um servidor hospedado para a parte da sessão que exige esses dados.

​

Economia e inventário

O inventário, e a economia em geral, exige uma abordagem diferente. É inevitável que, se um jogador está abrindo mão de algo de valor real (dinheiro) ou percebido (moeda virtual ou contêineres consumíveis), ele tem a expectativa implícita de que a transação será honrada. Para qualquer jogo com compras no aplicativo, um incremento no medidor de perfil por uma compra feita pelo jogador com moeda do mundo real é um custo trivial. Em muitos tipos de jogos, as atualizações de inventário são pouco frequentes o suficiente para não representar grande preocupação de aumento do uso geral. Mas, para aqueles com atualizações de inventário mais frequentes, mesmo que você não tenha monetização no jogo, há truques de otimização para ajudar a reduzir seus custos. Uma prática recomendada é pensar no inventário apenas no sentido literal, como um inventário razoavelmente finito. Por exemplo, em um jogo incremental (ou “idle”), pode ser tentador pensar em cada recurso que o jogador adquire como um item, incrementando o número total sempre que o jogador compra mais um. Mas esse modelo deixa de funcionar rapidamente quando você calcula a frequência com que os jogadores executam essas ações. Logo de cara, você teria que lidar com cada jogador acionando o medidor centenas ou até milhares de vezes em uma sessão. Para situações como essa, é melhor pensar nesses elementos como dados do usuário e atualizá-los no serviço usando as recomendações da seção Perfil acima. Quando se trata de jogos com taxas mais altas de atualização do inventário, voltamos à questão da atualidade dos dados. Por exemplo, um jogo de ação pode acompanhar o número de balas que um jogador tem, mas os dados de back-end dessa “pilha” de balas não precisam ser atualizados a cada puxada do gatilho, especialmente se o estado do jogo for gerenciado em um servidor hospedado. Os itens empilháveis oferecem uma vantagem de desempenho e de custo, pois você pode representar muitas instâncias virtuais de um item como uma única instância real com uma contagem. Muitas vezes, você pode agregar as alterações em pilhas de itens ao longo do tempo e atualizá-las no final de uma sessão ou periodicamente durante a sessão. Ao atualizar uma pilha, é uma boa ideia chamar Player Item Management - Modify Item Uses para verificar se você pode simplesmente alterar a contagem da pilha, em vez de adicionar N instâncias do item, que precisam ser processadas uma a uma para inclusão na pilha e depois limpas. Por sua natureza, determinados gêneros de jogos, como os jogos de cartas colecionáveis, precisam atualizar o inventário do jogador com uma frequência um pouco maior. Mas, mesmo aqui, ainda há oportunidades de agregar as alterações de inventário e reduzir o uso total dos medidores de perfil. Por exemplo, em jogos que usam tabelas de drop, o design frequentemente emprega um contêiner que tem uma ou mais “extrações” de cada uma de várias tabelas de drop diferentes. Normalmente, se essas extrações forem apenas uma ação ocasional, o custo incremental será pequeno o suficiente para não causar preocupação. Mas, se os jogadores puderem colecionar muitos desses contêineres e abrir vários em um curto período, você poderá oferecer uma opção “abrir N” ou até “abrir todos”. Nesse caso, você usa o CloudScript do PlayFab com o Azure Functions ou seu servidor de jogo personalizado para consultar Player Item Management - Get Random Result Tables para o conjunto de tabelas de drop ou chamar Player Item Management - Evaluate Random Result Table sem gerar os itens de inventário. Em seguida, você pode atualizar o inventário do jogador de forma muito mais eficiente, adicionando instâncias somente quando necessário e atualizando a contagem das pilhas de itens para o restante.

​

Conteúdo e configuração

Enquanto o perfil se refere principalmente ao jogador, o medidor Content and Configuration se refere principalmente ao título. Vários componentes no nível do título, como notificações por push, serviços de email e Title News, estão incluídos neste medidor. Além disso, este é o medidor usado para acompanhar o uso de arquivos de entidade. Da mesma forma, as solicitações das URLs para upload e download de arquivos da CDN são acompanhadas neste medidor, embora seja importante esclarecer que os custos da CDN são separados e cobrados com base no total de gigabytes baixados, conforme descrito em Rede de distribuição de conteúdo (CDN). O cálculo dos medidores de leitura e armazenamento de Content and Configuration é semelhante ao dos medidores de perfil, pois se baseia no tamanho dos dados, embora, obviamente, as unidades sejam significativamente maiores que 1 KB. O medidor de gravação de Content and Configuration se baseia apenas no número total de operações de gravação, com cada uma incrementando o medidor em 1. Como observação, o sistema de arquivos de entidade é o serviço recomendado para dados grandes, sejam eles associados ao título, a um grupo ou a um jogador individual. Para jogos com grandes salvamentos de dados por jogador, o sistema de arquivos de entidade geralmente é mais econômico; mas lembre-se de que a frequência dessas atualizações afeta o uso acompanhado. É melhor otimizar o número de arquivos de que você precisa em relação à frequência com que eles precisam ser atualizados. Em termos de otimização dos custos no medidor Content and Configuration, o mais importante a acompanhar é a frequência com que seu título precisa solicitar seus próprios dados de configuração que mudam raramente. Esses são principalmente os dados de título, comumente usados para gerenciar aspectos dos seus jogos que são iguais para todos os usuários, como dados de balanceamento/ajuste do jogo, definições de conquistas, dados de localização e assim por diante. Para jogos que usam o CloudScript, se você perceber que há uma dependência desses dados no nível do título em cada chamada a um script, talvez queira considerar “incorporar” esses dados diretamente ao script. Você pode fazer isso simplesmente definindo-os como dados codificados no próprio script ou usando variáveis estáticas, como forma de cache, para ler as informações do serviço uma vez por instância de máquina virtual (VM). Dessa forma, os dados no nível do título são carregados na primeira vez que uma determinada VM executa seu script e são reutilizados por essa VM nas execuções subsequentes. Três pontos a considerar aqui: primeiro, o script é usado por muitos usuários diferentes, portanto, nada deve ser considerado consistente para um usuário individual entre execuções. Segundo, o processamento dos dados deve ser considerado sem estado, pois um único jogador pode atingir máquinas diferentes em cada chamada. E, por fim, você precisa acompanhar a idade desses dados e recarregá-los periodicamente, para garantir que tenha a versão mais recente.

​

CloudScript

Esta é uma das principais “juntas de expansão” do serviço PlayFab, permitindo executar lógica autoritativa no servidor a partir de um dispositivo cliente ou de um servidor, ou até dispará-la por meio de regras do PlayStream (por exemplo, quando um jogador entra em um segmento). Ao contrário da hospedagem de servidores de jogo personalizados, você paga apenas pelos gigabytes-segundos (GB/s) em que o script é executado, com mínimos por execução de 128 MB e 100 ms. Portanto, se o seu script usar um total de 250 MB de espaço (somando o código e os dados do script), ele precisaria ser executado por um total de 4 segundos (provavelmente em várias execuções) para chegar a um GB/s. Como os casos de uso do CloudScript geralmente envolvem executar ações em nome dos seus jogadores, já abordamos a maior parte do que você deve considerar para otimizações nas duas últimas seções, sobre os medidores de perfil e de conteúdo/configuração. No entanto, o número total de execuções de um título também é acompanhado como parte da medição do uso do CloudScript, portanto, é útil revisar com que frequência você precisa fazer chamadas ao CloudScript por jogador. Para alguns jogos, pode ser significativamente mais econômico usar um servidor de jogo hospedado para ter um armazenamento de dados “quente” para os jogadores ativos, em vez de tentar gerenciar um armazenamento de dados com chamadas iterativas ao CloudScript.

​

Insights

Este medidor está associado a todos os recursos de análise do serviço PlayFab, desde a ingestão e exportação de eventos até a pesquisa no Event History e as consultas do Data Explorer. Seu uso aqui é influenciado pela rapidez com que você precisa que os eventos sejam processados, pela quantidade de dados de eventos que você deseja manter hospedados de forma “quente” (para consultas no Game Manager) e por quanto você usa o serviço para avaliar seus dados, seja por meio de consultas do Data Explorer ou de software de visualização conectado diretamente aos seus dados. Este medidor é afetado tanto pela atividade no jogo (eventos) quanto pela atividade fora do jogo (análise). Em última análise, isso significa que os custos do Insights são determinados pela quantidade de dados de eventos que você recebe dos jogadores e pela quantidade de processamento analítico que você faz nesses dados. Em termos de práticas recomendadas, os conselhos sobre eventos acima se aplicam ao primeiro aspecto, enquanto, para o segundo, você pode controlar os custos de duas maneiras. Primeiro, e mais simples, você pode definir o armazenamento total na guia Insights Management do Game Manager do seu título para controlar a quantidade total de dados de eventos retidos no PlayFab. Em seguida, na mesma guia, você pode definir o nível de desempenho do seu título. Isso determina a quantidade total de recursos de CPU alocados ao seu título, bem como a quantidade de dados armazenados de forma “quente” para consultas no Event History. Quanto você precisa de cada um depende das necessidades dos membros da sua equipe de análise de dados, portanto, é melhor revisar isso com eles para entender quais devem ser suas configurações. Para obter informações sobre o Insights e como usá-lo, consulte O que é o PlayFab Insights. Para obter informações sobre as práticas recomendadas do Insights, consulte Práticas recomendadas e perguntas frequentes.

​

Serviços multijogador

Este é o mais simples de todos, pois os preços não mudaram em nada. Em resumo, os Multiplayer Servers hospedados e o serviço Party sempre foram cobrados com base no uso. Especificamente para servidores de jogo hospedados, você pode minimizar seus custos otimizando o número de núcleos de servidor que precisa manter em execução a qualquer momento para atender ao maior número possível de jogadores. Se tempos de ping baixos forem importantes nesses servidores, você poderá escolher em quais regiões executar os servidores. Para a maioria dos jogos, as maiores concentrações de jogadores se limitam a determinadas regiões principais, mas, se você tiver uma população de jogadores amplamente dispersa, especialmente quando estiver na cauda longa do seu jogo, precisará ponderar o custo de executar servidores em todas as regiões próximas aos seus jogadores em relação ao impacto de tempos de ping mais longos no subconjunto de jogadores em áreas com poucos jogadores. Algo que pode ajudar nisso é usar nosso serviço de QoS para escolher em quais regiões colocar os jogadores e, em seguida, determinar qual é o seu limite mínimo de jogadores jogando em uma região para que ela seja viável.

​

Gerenciando seu jogo ao vivo

Isso abrange os fundamentos dos medidores, mas o que você deve considerar depois que seu título estiver no ar? Gerenciar sua comunidade de jogadores envolve principalmente análise (Insights, na seção acima) e atualizações de conteúdo e configuração. Além disso, a maioria dos jogos precisa interagir com os jogadores fora de suas interações normais com o próprio jogo. Desde campanhas de reengajamento (para atrair os jogadores de volta) até recompensas da comunidade por atividades de metajogo e até agradecimentos aos jogadores por seu próprio trabalho com a comunidade fora do jogo, uma prática comum hoje em dia é usar técnicas de LiveOps para manter os jogadores altamente engajados. Um ponto-chave para isso é garantir que você direcione sua segmentação de forma eficaz para grupos bem definidos, não apenas para manter os custos baixos, mas também para garantir que sua lógica seja processada rapidamente. Considere, por exemplo, o reengajamento de jogadores: fazer com que os jogadores voltem depois de terem parado de jogar por algum tempo. Uma boa maneira de abordar isso é definir vários períodos de usuários inativos, talvez jogadores que não jogam há 3, 7 e 21 dias. Para cada um, você pode adotar uma abordagem diferente de reengajamento, começando com uma simples mensagem de “sentimos sua falta” e culminando em uma mensagem de “aqui está um pouco de ouro/energia etc. grátis” (acompanhada, é claro, da adição automática desses itens à conta do jogador). Para cada um deles, a abordagem recomendada é definir uma janela de uma hora com base na última vez em que o jogador entrou para jogar. Dessa forma, você não apenas direciona com base na última vez em que ele jogou, mas também mantém o conjunto de jogadores no segmento minimizado, para tornar a operação o mais eficiente possível. Usando uma tarefa agendada que é disparada uma vez por hora em cada um desses segmentos, você envia as mensagens e adiciona quaisquer itens ou moedas virtuais (VC) aos inventários dos jogadores.

​

Resumo

Em última análise, são os recursos de que seu jogo precisa que determinam o uso de um serviço de back-end como o PlayFab. Na verdade, tudo se resume a uma pergunta abrangente: quais são os requisitos desses recursos? Seja priorizando a segurança, a atualidade dos dados, o nível de interação/competição entre jogadores ou qualquer outra coisa, há inúmeros fatores que podem levar você a um nível mais alto de interação com os dados de back-end. Ser capaz de examinar esses requisitos com olhar crítico e discernir quais são necessidades reais e quais não são é muito parecido com a otimização de qualquer outro código do seu jogo. É uma questão de examinar com cuidado onde a utilização de recursos é alta e decidir se ela realmente precisa ser assim ou se há maneiras de reformular essa lógica para reduzir o uso. Se a interação for em tempo real, entre jogadores, tudo depende da complexidade dessa interação. Para a maioria dos jogos desse tipo, servidores hospedados que gerenciam o estado da simulação e só atualizam os dados de back-end no final de uma sessão (ou a cada poucos minutos, se as sessões forem longas) costumam ser a melhor solução. Mas há muitos casos em que a interação é totalmente confiável, como em jogos cooperativos ou jogados apenas com (ou contra) amigos, minimizando o incentivo para trapacear. Outros ainda têm requisitos mínimos sobre como os dados de uma sessão devem ser verificados, permitindo que ambos os jogadores simplesmente enviem seus relatórios após cada sessão, para que as verificações no lado do servidor possam comparar os dois. Para qualquer jogo sem requisito de tempo real, considere se o jogador realmente precisa de precisão ao segundo. Em jogos altamente competitivos com forte interação da comunidade, esse pode muito bem ser o caso. Mas, para muitos jogos, informações com alguns minutos de atraso não afetam a experiência do jogador.