Você pode perceber que essa abordagem causaria um curto-circuito em algumas das leituras da Tabela 4.

Você pode pensar que deveríamos armazenar apenas os dados recém-calculados depois de armazenar uma nova entrada na contabilidade. Em teoria, isso pode parecer bom, mas resultaria em dados inconsistentes e desempenho reduzido. Um exemplo de desempenho reduzido é que o sistema estaria ocupado recalculando e armazenando dados, geralmente devido à necessidade de ler e então gravar. Precisamos equilibrar o cálculo aqui enquanto executamos o jogo com um desempenho adequado para todos os jogadores.

Um exemplo de dados inconsistentes é lidar com os cálculos de fim de partida. Nossa infraestrutura de servidor e plataforma suportam mensagens atrasadas. Um exemplo é um problema temporal em duas centrais de processamentos de dados (A e B), e a mensagem para dar a um jogador a experiência da mini é enviada de A, mas ainda não chegou a B. Imagine este cenário: você está jogando uma partida pouco antes da meia-noite. Você joga e vence, são 23h59 de uma quarta-feira. O processador de pacote cumulativo foi configurado para executar diariamente todos os dados de cada dia. Então, ele começaria à meia-noite e calcularia seus valores totais de experiência até a meia-noite de quinta-feira. Esses dados seriam armazenados na segunda tabela e novas leituras da experiência procurariam o último valor armazenado e somariam tudo após a meia-noite de quinta-feira. O que acontece com uma mensagem que chega atrasada é que nós a recebemos, mas notamos que a partida foi concluída na quarta-feira às  23h59 e escrevemos a entrada da experiência com esse horário. A tabela de pacotes cumulativos não teria essa entrada incluída, e a consulta de dados posteriores também não mostraria essa entrada. Esses dados incompletos seriam um problema. E as mensagens que chegam com alguns dias de atraso? Bem, temos monitoramento e alertas em vigor que quase sempre garantem que essas novas informações serão processadas a tempo para o próximo pacote cumulativo.

Calculando níveis das minis

Olhando novamente a tabela de experiência total, você notará que não há níveis calculados lá. Temos apenas um total da quantidade de experiência já adquirida. Separadamente, há uma tabela estática que os designers de jogo definiram e que é mais ou menos assim: uma mini começa no nível 1 e, uma vez que ela ganha 1 ponto de experiência, será nível 2 e, então, precisará ganhar 3 pontos para chegar ao nível 3.

Combinando as duas, podemos calcular no tempo de execução qual é o nível real de uma mini por meio de um total acumulado, obtendo, assim, o seguinte conjunto de dados:

Os designers do jogo têm flexibilidade para alterar quanta experiência é necessária para ganhar um nível. Eles podem decidir que está muito difícil subir de nível nos níveis mais baixos e diminuir a quantidade de experiência necessária para chegar ao próximo nível. Isso significaria que, sem fazer nenhuma alteração nos dados do jogador salvos no banco de dados, todas as minis teriam um leve aumento em seu nível atual e precisariam de menos para chegar ao próximo nível. Isso também vale na outra ponta: se for decidido que os níveis estão sendo alcançados muito rapidamente e os valores forem aumentados, não iremos simplesmente gerar uma experiência a fim de restaurar os níveis das minis anteriores à mudança. Isso não quer dizer que não podemos dar aos designers a opção de conceder alguma experiência às minis para ajudar a amenizar a situação.

Abordagens alternativas que foram consideradas

Antes de usar a solução que temos atualmente, nós analisamos várias abordagens sobre como armazenar os ganhos de experiência e calcular o nível resultante para as minis. Algumas envolviam um tempo extra fora do ar que nos permitiria alterar a experiência de um jogador, enquanto outras ofereciam uma boa experiência simultaneamente à progressão de um jogador.

"Sempre armazenar o nível, a experiência e a quantidade necessária ao próximo nível da mini"

Que tal usarmos apenas um modelo SQL padrão e atualizações transacionais? Elas permitem que você atualize um conjunto de dados em sua totalidade, tipo tudo ou nada. Se uma parte não for gravada, todas serão revertidas ao valor original. Elas fornecem as propriedades A.C.I.D.: atomicidade, consistência, isolamento e durabilidade.

Isso usaria uma única linha para manter a experiência e o nível total de cada mini, tornando as leituras realmente leves.

À medida que cada mini ganha experiência, atualize esta mini em 2 pontos de experiência, faltando 8 pontos para o próximo nível, sendo o atual igual a 3. Esse tipo de alteração força uma leitura dos dados, um novo cálculo e, em seguida, uma gravação no banco de dados. Esse padrão não casa bem com Cassandra e seus pontos fortes. Outro problema com essa abordagem é que alterar as quantidades necessárias para o próximo nível exigiria colocar o jogo offline para modificarmos os dados de todas as minis de todos os jogadores.

"Armazene em forma percentual"

Nós também cogitamos armazenar em forma de porcentagem o necessário para o próximo nível. Por exemplo:

E, então, após uma partida, faríamos alguns cálculos rápidos. Por exemplo: o Brutamontes Gnoll recebe +3 de exp., a porcentagem é +3 / 10; vamos dar ao Brutamontes Gnoll 30% de um nível, resultando em:

Isso nos daria flexibilidade se alterássemos a curva de nível da mini, mas não resultaria em nenhuma alteração de nível para a mini. Isso também nos proporcionaria algumas visualizações mais simples na interface do usuário do jogo, pois diríamos apenas para preencher 30% da barra, sem necessidade de matemática adicional. No entanto, esse tipo de padrão resultaria em porcentagens muito pequenas nos níveis mais altos. Quando uma mini recebe 10 pontos de experiência por jogo e precisa de 100.000 para subir de nível, esse valor seria representado em 0,01%. As unidades centrais de processamento (CPUs) podem lidar com flutuações, mas precisão e exatidão podem causar bugs se não levarmos em conta a natureza da matemática de vírgula flutuante.

Até mais...

Muitas opções foram consideradas no âmbito da tecnologia de banco de dados, quais ferramentas poderiam ser fornecidas e, finalmente, como armazenar e calcular as coisas. Como acontece com qualquer coisa ainda em desenvolvimento, podemos mudar tudo isso mais tarde se encontrarmos algo que funcione ainda melhor, mas esse pareceu um bom ponto de partida para este jogo.

Obrigado por se juntar a nós nesta atualização da engenharia!

~ Andy Lim