DeletedUser3372
Guest
Caros jogadores,
Como muitos de vocês devem ter vivenciado ou no mínimo notado, nosso tempo de paz não parece ter trazido uma atmosfera pacífica no jogo este ano. Infelizmente, essa não foi a primeira vez na história do Grepolis, então, utilizaremos este tópico para explicar o motivo do tempo de paz ser um problema constante no Grepolis, o que aconteceu de errado este ano e como o tornaremos melhor no futuro.
Tempo de paz com problema? Novamente?
Infelizmente, o Grepolis tem uma longa história com relação ao tempo de paz – mas neste ano, algo ocorreu diferente! Embora tenhamos vivenciado problemas com a lógica e ocasiões especiais num passado distante, o último tempo de paz encontrou muitos problemas na questão de configuração. De fato, o sistema para configurar a tal "paz" tava muito lento e, portanto, nossos Gestores de Comunidade não puderam planejar nada, tendo sido feito manualmente em cada mundo, então, esse método de configuração estava destinado a falhar em algum momento (esquecer de ativar a caixa para um dos mundos, esquecer de copiar um dos dígitos do timestamp, etc). Por isso retrabalhamos na mecânica de configuração dos tempos de paz, para usar as mesmas mecânicas que usamos para os nossos eventos de jogo (como a recente Roda da Fortuna).
Por que, ainda assim, tivemos problemas? Não testamos o suficiente?
Enquanto movemos o sistema, escrevemos diversos testes executados automaticamente (conhecidos como testes de Unidade e Integração) para garantir a funcionalidade da mecânica, especialmente para cobrir os cenários dentre os quais apresentaram problemas no passado, incluindo o deste ano, no qual falhamos. Claro que testamos o tempo de paz manualmente. Fizemos testes para simular o tempo de paz do Natal em nossos servidores internos e tudo estava funcionando apropriadamente.
Espere, o que? Então, o que deu errado?
Para explicar isto, precisamos explicar como o Grepolis funciona no plano de fundo. Grepolis é um jogo onde o nosso "Backend" (o "programa" que roda os nossos servidores, manuseando todas as ações e lutas em curso) está rodando sob PHP, então ele não está "rodando" o tempo todo, mas temos que construir o jogo com cada demanda do seu navegador, aplicativo ou até mesmo nosso próprio sistema (caso um comando chegue). Como pode imaginar, Grepolis é um jogo grande e complexo, então a construção disso pode levar muito tempo. Para melhorar isto (e, portanto, ter um menor tempo de resposta das suas demandas), usamos diversas técnicas distintas e, uma delas, é o "caching". Você deve conhecer o caching do seu navegador, onde o browser se lembra de images ou outros arquivos, para que você não precise carregá-los de novo e de novo caso eles não mudem. Basicamente é isso que nós fazemos em nosso Backend, especialmente com este "sistema de acontecimentos".
A ideia é: Por que devemos pedir à base de dados (o lugar onde guardamos todas as informações do jogo) algo que já sabemos? Uma vez que solicitar algo à base de dados é um tanto quanto "custoso" (em termos de tempo), tentamos lembrar a resposta que nós já temos, o que é mais prático.
Okay, o que isso tem a ver com os problemas que nós vivenciamos?
Apenas para lembrar o problema que nós tivemos: 24 horas antes do tempo de paz, não deveria ser possível enviar novos navios colonizadores à outras cidades. Basicamente, não deveria ser possível conquistar novas cidades se os navios não tivessem em curso.
Para garantir esta e muitas outras regras, temos uma lista de verificações quando um jogador tenta enviar um ataque – somente se nenhuma das regras são violadas, enviamos o ataque. E aqui está o problema: Ao enviar um ataque, primeiro verificamos se haveria paz no momento de chegada de um ataque (chamaremos esta de timestamp1) OU 24 após, somente se um colono estivesse a caminho junto com um ataque (timestamp2).
Aqui dá o problema com o nosso caching: Já carregamos os dados de paz para o timestamp1 e colocamos em cache. Ao efetuar a segunda verificação, nosso caching passa a compreender que já conhece tudo sobre os tempos de paz – o que quer dizer que caso haja um novo tempo de paz começando entre o timestamp 1 e 2, o nosso jogo simplesmente não conseguiria localizá-lo.
Okay, entendi – mas como os seus testes passaram?
Este é o motivo no qual a correção do erro levou tanto tempo. Começamos a tentar resolver o problema às 21:00 do dia 23 de dezembro (horário da Alemanha) e nos levou até às 01:00 do dia 24, quando finalmente conseguimos corrigir o problema. O problema é: Este caching está desativado em nosso sistema de testes, pois não precisamos dos impulsionadores de performance por lá. Em contrapartida, queremos simplificar o nosso processo de testes (não aprofundaremos mais neste tópico). Então, mesmo que tenhamos testado muito, não estávamos testando exatamente o que estava ocorrendo no jogo ao vivo e essa foi a nossa culpa, não temos argumentos para isto – e pedimos imensas desculpas por isso!
Yay, erro corrigido, mas cometemos outro erro
Para reduzir o impacto deste erro para todos vocês, criamos um script que verificaria todos os ataques em curso que incluíam um navio colonizador e, além disso, todas as conquistas em curso, para ver quando os ataques foram lançados.
Cancelando os ataques em curso: funcionou perfeitamente;
Cancelando as conquistas em curso: não funcionou tão bem – e novamente, pedimos desculpas por isso.
A lógica do nosso script de reparação era basicamente esta: Pegar todas as conquistas, verificar quando começaram, calcular o tempo de viagem da cidade de origem até a cidade sob conquista e, por fim, confirmar se este era um ataque legítimo. Até então estava tudo bem, se não fosse um problema: Ao calcular quando uma conquista começou (não guardamos isto em local algum), tivemos de calcular o momento em que terminaria (isto nós guardamos), e subtraímos as horas que uma conquista leva naquele mundo. O problema é que na maioria dos mundos este valor é 0.
Por que 0 se não há mundos com conquistas instantâneas?! 0 é apenas um valor padrão, o que significa que deveríamos calcular 24 horas dividido pela velocidade do mundo. Já eram 4 da manhã quando entregamos aquele script e, honestamente, não nos atentamos a este detalhe do valor 0 (a entrega leva algum tempo e obviamente tivemos que testar tudo: primeiro o teste ao vivo, verificar se o script funciona e então lançar!). Em contrapartida estávamos sob muita pressão com o tempo e queríamos minimizar o impacto deste erro o máximo possível. Nos nossos servidores de teste tudo estava funcionando, pois normalmente colocamos estes valores por lá (não queremos testar algo relacionado à conquista no qual tenhamos que aguardar por 8 horas ou mais), então, não conseguimos pegar o caso da padronização do valor nos testes.
Este é o motivo no qual a entrega de outro script para compensar todos os jogadores (afetados pelos nossos erros de cancelamento de conquista) só ocorreu no dia 25 de dezembro, desta vez não foi desenvolvido às 3 horas da manhã e com pressão devido ao armistício programado, tendo sido executado às 14:30.
Encerramento
Em primeiro lugar, devemos a todos vocês as mais sinceras desculpas pelo que aconteceu. Todos vocês merecem o melhor e nós prometemos que levaremos este problema técnico mais seriamente. Refletiremos sobre o que aconteceu e tomaremos medidas mais apropriadas para preveni-los no futuro (ainda mais importante, prevenir este problema de ocorrer agora, no Ano Novo).
Segundo, este erro revelou alguns problemas de desenvolvimento em nosso código existente – o que é absolutamente normal num jogo que tem tanto tempo como o Grepolis, mas é claro que temos de atacar o problema para não cometermos os mesmos erros em outras ocasiões.
Terceiro, agradecemos a todos que mantiveram o Fair Play ao não enviar mais navios colonizadores, mesmo que ainda tenha sido possível fazê-lo!
--
Atenciosamente,
Sua equipe do Grepolis.
Como muitos de vocês devem ter vivenciado ou no mínimo notado, nosso tempo de paz não parece ter trazido uma atmosfera pacífica no jogo este ano. Infelizmente, essa não foi a primeira vez na história do Grepolis, então, utilizaremos este tópico para explicar o motivo do tempo de paz ser um problema constante no Grepolis, o que aconteceu de errado este ano e como o tornaremos melhor no futuro.
Tempo de paz com problema? Novamente?
Infelizmente, o Grepolis tem uma longa história com relação ao tempo de paz – mas neste ano, algo ocorreu diferente! Embora tenhamos vivenciado problemas com a lógica e ocasiões especiais num passado distante, o último tempo de paz encontrou muitos problemas na questão de configuração. De fato, o sistema para configurar a tal "paz" tava muito lento e, portanto, nossos Gestores de Comunidade não puderam planejar nada, tendo sido feito manualmente em cada mundo, então, esse método de configuração estava destinado a falhar em algum momento (esquecer de ativar a caixa para um dos mundos, esquecer de copiar um dos dígitos do timestamp, etc). Por isso retrabalhamos na mecânica de configuração dos tempos de paz, para usar as mesmas mecânicas que usamos para os nossos eventos de jogo (como a recente Roda da Fortuna).
Por que, ainda assim, tivemos problemas? Não testamos o suficiente?
Enquanto movemos o sistema, escrevemos diversos testes executados automaticamente (conhecidos como testes de Unidade e Integração) para garantir a funcionalidade da mecânica, especialmente para cobrir os cenários dentre os quais apresentaram problemas no passado, incluindo o deste ano, no qual falhamos. Claro que testamos o tempo de paz manualmente. Fizemos testes para simular o tempo de paz do Natal em nossos servidores internos e tudo estava funcionando apropriadamente.
Espere, o que? Então, o que deu errado?
Para explicar isto, precisamos explicar como o Grepolis funciona no plano de fundo. Grepolis é um jogo onde o nosso "Backend" (o "programa" que roda os nossos servidores, manuseando todas as ações e lutas em curso) está rodando sob PHP, então ele não está "rodando" o tempo todo, mas temos que construir o jogo com cada demanda do seu navegador, aplicativo ou até mesmo nosso próprio sistema (caso um comando chegue). Como pode imaginar, Grepolis é um jogo grande e complexo, então a construção disso pode levar muito tempo. Para melhorar isto (e, portanto, ter um menor tempo de resposta das suas demandas), usamos diversas técnicas distintas e, uma delas, é o "caching". Você deve conhecer o caching do seu navegador, onde o browser se lembra de images ou outros arquivos, para que você não precise carregá-los de novo e de novo caso eles não mudem. Basicamente é isso que nós fazemos em nosso Backend, especialmente com este "sistema de acontecimentos".
A ideia é: Por que devemos pedir à base de dados (o lugar onde guardamos todas as informações do jogo) algo que já sabemos? Uma vez que solicitar algo à base de dados é um tanto quanto "custoso" (em termos de tempo), tentamos lembrar a resposta que nós já temos, o que é mais prático.
Okay, o que isso tem a ver com os problemas que nós vivenciamos?
Apenas para lembrar o problema que nós tivemos: 24 horas antes do tempo de paz, não deveria ser possível enviar novos navios colonizadores à outras cidades. Basicamente, não deveria ser possível conquistar novas cidades se os navios não tivessem em curso.
Para garantir esta e muitas outras regras, temos uma lista de verificações quando um jogador tenta enviar um ataque – somente se nenhuma das regras são violadas, enviamos o ataque. E aqui está o problema: Ao enviar um ataque, primeiro verificamos se haveria paz no momento de chegada de um ataque (chamaremos esta de timestamp1) OU 24 após, somente se um colono estivesse a caminho junto com um ataque (timestamp2).
Aqui dá o problema com o nosso caching: Já carregamos os dados de paz para o timestamp1 e colocamos em cache. Ao efetuar a segunda verificação, nosso caching passa a compreender que já conhece tudo sobre os tempos de paz – o que quer dizer que caso haja um novo tempo de paz começando entre o timestamp 1 e 2, o nosso jogo simplesmente não conseguiria localizá-lo.
Okay, entendi – mas como os seus testes passaram?
Este é o motivo no qual a correção do erro levou tanto tempo. Começamos a tentar resolver o problema às 21:00 do dia 23 de dezembro (horário da Alemanha) e nos levou até às 01:00 do dia 24, quando finalmente conseguimos corrigir o problema. O problema é: Este caching está desativado em nosso sistema de testes, pois não precisamos dos impulsionadores de performance por lá. Em contrapartida, queremos simplificar o nosso processo de testes (não aprofundaremos mais neste tópico). Então, mesmo que tenhamos testado muito, não estávamos testando exatamente o que estava ocorrendo no jogo ao vivo e essa foi a nossa culpa, não temos argumentos para isto – e pedimos imensas desculpas por isso!
Yay, erro corrigido, mas cometemos outro erro
Para reduzir o impacto deste erro para todos vocês, criamos um script que verificaria todos os ataques em curso que incluíam um navio colonizador e, além disso, todas as conquistas em curso, para ver quando os ataques foram lançados.
Cancelando os ataques em curso: funcionou perfeitamente;
Cancelando as conquistas em curso: não funcionou tão bem – e novamente, pedimos desculpas por isso.
A lógica do nosso script de reparação era basicamente esta: Pegar todas as conquistas, verificar quando começaram, calcular o tempo de viagem da cidade de origem até a cidade sob conquista e, por fim, confirmar se este era um ataque legítimo. Até então estava tudo bem, se não fosse um problema: Ao calcular quando uma conquista começou (não guardamos isto em local algum), tivemos de calcular o momento em que terminaria (isto nós guardamos), e subtraímos as horas que uma conquista leva naquele mundo. O problema é que na maioria dos mundos este valor é 0.
Por que 0 se não há mundos com conquistas instantâneas?! 0 é apenas um valor padrão, o que significa que deveríamos calcular 24 horas dividido pela velocidade do mundo. Já eram 4 da manhã quando entregamos aquele script e, honestamente, não nos atentamos a este detalhe do valor 0 (a entrega leva algum tempo e obviamente tivemos que testar tudo: primeiro o teste ao vivo, verificar se o script funciona e então lançar!). Em contrapartida estávamos sob muita pressão com o tempo e queríamos minimizar o impacto deste erro o máximo possível. Nos nossos servidores de teste tudo estava funcionando, pois normalmente colocamos estes valores por lá (não queremos testar algo relacionado à conquista no qual tenhamos que aguardar por 8 horas ou mais), então, não conseguimos pegar o caso da padronização do valor nos testes.
Este é o motivo no qual a entrega de outro script para compensar todos os jogadores (afetados pelos nossos erros de cancelamento de conquista) só ocorreu no dia 25 de dezembro, desta vez não foi desenvolvido às 3 horas da manhã e com pressão devido ao armistício programado, tendo sido executado às 14:30.
Encerramento
Em primeiro lugar, devemos a todos vocês as mais sinceras desculpas pelo que aconteceu. Todos vocês merecem o melhor e nós prometemos que levaremos este problema técnico mais seriamente. Refletiremos sobre o que aconteceu e tomaremos medidas mais apropriadas para preveni-los no futuro (ainda mais importante, prevenir este problema de ocorrer agora, no Ano Novo).
Segundo, este erro revelou alguns problemas de desenvolvimento em nosso código existente – o que é absolutamente normal num jogo que tem tanto tempo como o Grepolis, mas é claro que temos de atacar o problema para não cometermos os mesmos erros em outras ocasiões.
Terceiro, agradecemos a todos que mantiveram o Fair Play ao não enviar mais navios colonizadores, mesmo que ainda tenha sido possível fazê-lo!
--
Atenciosamente,
Sua equipe do Grepolis.