É comum os jogadores de WAR reclamarem de um certo favorecimento "fora das regras" dos dados de defesa do jogo sobre os de ataque. A equipe do Gametrack realizou diversos testes para garantir a aleatoriedade de todos os dados.
Alguns jogadores naturalmente tem a tendência de culpar os dados por suas derrotas. Mas o fato de empate entre valores iguais de dados dar vitória para a defesa representa uma forte desvantagem para o ataque que não é óbvia à primeira vista.
Leia com atenção as perguntas e respostas abaixo para tirar todas as suas dúvidas e desconfianças de como funcionam os dados do WAR.

1. Por que vocês fizeram esta área de perguntas e respostas apenas para falar sobre os dados do WAR?

2. Como é definido o sorteio de cada dado no War?

3. Se todos os processos aleatórios de uma partida de WAR são determinados pela chave inicial adotada e o algoritmo é público, isso não permite um jogador antever os resultados de seus lances de dados e com isso se beneficiar por saber os resultados antes de realizar seus ataques?

4. E como eu posso ter certeza que o servidor de jogos do Gametrack não "escolheu" uma chave inicial para beneficiar um determinado jogador? Ou até mesmo me prejudicar?

5. Quais são os eventos aleatórios do jogo que não são definidos pela semente inicial do algoritmo?

6. Por que vocês adotaram o algoritmo pseudoaleatório Mersenne Twister 32 bits em seus jogos? Ouvi falar que há outros melhores!

7. A velocidade do ataque altera em alguma coisa nos resultados dos dados?

8. Por que o primeiro dado que cai sempre é maior ou igual aos seguintes? Isso não acontece no jogo de tabuleiro real!

9. O que é a janela de Log de Dados e como ela funciona?

10. Mas para que serve o Log de Dados?

11. Como faço para auditar o sorteio de dados na janela de Log de Dados?

12. O que são os índices SA, SD e ST que aparecem no quadro resumo da sorte nos dados?

13. O Log de Dados é gravado junto com o resultado da partida?

14. Não entendo nada de programação Java e não entendi como funcionam os códigos-fontes de sorteios exibidos no Log de Dados, de que adianta então?

15. Se o Log de Dados prova a honestidade do sorteio de dados, porque ele demorou tanto para ser feito na versão do jogo WAR em Shockwave?

16. E o que vocês NÃO fizeram para diminuir as reclamações sobre o sorteio dos dados?

17. Se os dados são aleatórios, por que eu perco mais exércitos quando ataco do que elimino do adversário?

18. Usei a calculadora e verifiquei que no jogo aconteceu comigo um fracasso de conquista que estava estimado como bastante raro! Por que comigo?

19. Estou realmente revoltado com os dados. Eles sempre me roubam! O que devo fazer?

20. Estou realmente revoltado com os dados. Eles sempre me roubam! O que NÃO devo fazer?

21. Vocês têm que fazer alguma coisa. Vejo muitos reclamando que os dados roubam. Comecei a acreditar!

22. Ok. Estou convencido: não faz sentido culpar os dados pelas derrotas! O que vocês sugerem fazer então quando vir alguém reclamando dos dados no chat?

Calculadora dos Dados do WAR

A calculadora abaixo calcula a probabilidades de não haver uma conquista do território atacado, sempre se atacando com o máximo de exércitos possíveis a cada turno.

Tabela de probabilidades de vitórias a cada tipo de ataque no WAR

O sorteio de dados do WAR representa um ponto polêmico para muitos jogadores do Gametrack. É relativamente comum recebermos mensagens questionando a validade dos resultados dos dados de ataque contra os de defesa. Algumas pessoas chegam a cogitar "conspirações" propositais feitas pela nossa equipe de desenvolvimento. O Gametrack tem profundo respeito a seus jogadores e, para ajudar a elucidar essas dúvidas, resolvemos explicar tudo em detalhes neste FAQ.

Ao iniciar uma nova partida, o servidor de jogos gera um número inteiro aleatório positivo de 32 bits, de 0 a 2.147.483.648, chamado de chave inicial ou semente, associado à partida. Esta semente é utilizada para inicializar o algoritmo pseudoaleatório Mersenne Twister, de conhecimento público, que será chamado diversas vezes durante a partida sempre que esta necessitar gerar um novo número pseudoaleatório. Essa chave inicial junto com o algoritmo pseudoaleatório Mersenne Twister, geram uma sequência determinística de números de 32 bits, com boas características estatísticas, onde cada número será usado em ordem para fazer um sorteio na partida.

Já no começo da partida são realizados cerca de 90 sorteios aleatórios para:

• Embaralhar as cartas de distribuição de territórios iniciais;
• Embaralhar as cartas de trocas que ficam na mesa e são recebidas no final de cada rodada;
• Embaralhar as cartas de objetivos do jogo; e
• Definir qual o jogador será o primeiro a receber carta de território inicial.

Após isso, novos sorteios com o algoritmo pseudoaleatório Mersenne Twister são realizados a medida que combates são efetuados entre os jogadores, de acordo com a quantidade de dados envolvidos. Para cada lance de dado é gerado um novo valor da sequência do algoritmo, deste modo, um ataque de três exércitos contra três na defesa exige a geração de seis números da sequência. A sequência é totalmente determinística, fazendo com que a sorte ou azar de cada jogador no próximo ataque dependa apenas da semente inicial adotada no início da partida e das quantidades de ataques realizados anteriormente.

Mais detalhes de como cada valor da sequência do algoritmo é usado para definir uma ação da partida podem ser vistos na janela de Log de Dados associada à partida.

A chave inicial adotada em uma partida é aleatória e diferente da utilizada em outra, sem haver qualquer relação entre elas. Ela também é mantida em segredo dos jogadores ao longo de toda a partida, guardada apenas no nosso servidor de jogos. Ao fim da partida, ela é divulgada a todos os participantes que estão com a janela de Log de Dados aberta, para que estes possam entender como os resultados de sorteio da partida foram calculados, se assim desejarem.

A segurança do sigilo da semente ao longo de uma partida em andamento é garantida por ser computacionalmente caro (difícil) um jogador descobrir a semente adotada apenas com os resultados de sorteio obtidos até o momento. Ele teria que varrer em testes bilhões de possibilidades de chaves, com o agravante de não saber exatamente a sequência de resultados de sorteio. Há complicadores como o fato dos resultados de dados nos combates serem enviados pelo servidor fora de ordem de sorteio pelo algoritmo, mas já ordenados do maior para o menor nos dados do ataque e nos dados de defesa. Acrescenta-se a isso o fato de que alguns sorteios preliminares da partida não serem comunicados à aplicação cliente, ficando inicialmente registrados apenas no servidor, como por exemplo, o embaralhar das cartas de troca.

Isso dá uma ideia da complexidade da tarefa de se descobrir a semente adotada em uma partida apenas a partir da sequência incompleta de resultados de sorteios desta. Em poucas palavras, no algoritmo Mersenne Twister é computacionalmente barato realizar sorteios a partir de uma chave inicial de 32 bits, mas é extremamente caro fazer o inverso, a partir dos resultados de sorteios descobrir qual foi a semente utilizada.

Pelo mesmo motivo da resposta anterior. Assim como é praticamente impossível descobrir a semente que gera uma sequência de resultados de sorteio, também é praticamente impossível gerar com agilidade uma semente que favoreça intencionalmente um determinado jogador em todos os eventos de sorteio futuros da partida.

A semente teria que, por exemplo, gerar uma sequência de sorteios benéficas para dar a um determinado jogador bons territórios iniciais, um bom objetivo, boas cartas de troca e ainda, favorecê-lo para iniciar primeiro na partida. Isso tudo, sem beneficiar igualmente os demais jogadores. Fazer isso é computacionalmente muito caro, o que deixaria nosso servidor de jogos lento. O Gametrack só teria desvantagens, perdendo tempo com o que não interessa a ninguém.

Mas mesmo se nossa equipe de desenvolvimento quisesse fazer isso, a sorte e azar de cada jogador em uma partida nos lances de dados também depende do volume de combates realizados anteriormente. Sendo mais preciso, os resultados dos dados de um ataque específico dependem muito de quantos ataques foram realizados antes, e isso é impossível para o Gametrack antever, já que depende da vontade de realizar ataques de cada jogador na sua vez de jogar.

Por exemplo, se em uma partida de três jogadores (A, B e C) onde houve 1.000 combates ao todo, o jogador A foi o que teve mais sorte nos dados, talvez ele passasse a ser o jogador com mais azar caso o primeiro ataque não tivesse sido realizado ou fosse realizado com quantidades de dados de ataque e defesa diferentes. Esse comportamento caótico e imprevisível da evolução dos sorteios a partir apenas da definição da chave inicial torna impossível qualquer poder de influência do Gametrack nos sorteios. E claro, o mesmo acima se aplica se a intenção do Gametrack fosse prejudicar algum jogador em uma partida.

Acredite: o Gametrack não tem motivos e nem meios para te perseguir nos sorteios da partida!

Alguns elementos aleatórios utilizados no jogo são sorteados usando outros algoritmos aleatórios que não são auditáveis, já que são irrelevantes para a sorte e destino da partida. Fizemos deste modo para simplificar a auditoria da aleatoriedade dos sorteios, já que sem isso, teríamos que explicar e registrar cada evento aleatório do jogo, por mais irrelevante que fosse. Com isso, apenas os eventos aleatórios mais importantes para definir o destino da partida é que utilizam os números gerados pelo algoritmo pseudoaleatório Mersenne Twister e sua chave inicial pré-estabelecida.

Os seguintes eventos aleatórios de partida são definidos por outros algoritmos não auditáveis:

• Todas as ações que o servidor executa no lugar de um jogador ausente na partida ou que tenha estourado o tempo, como por exemplo, os territórios em que se distribui novos exércitos;
• O embaralhar das cartas de trocas, quando o carteado na mesa se esgota;
• Os sons como metralhadora, explosões, vitória ou derrota e imagens de animação transitórias como os dados girando enquanto caem; e
• As variadas dicas de uso de jogo na tela de cada jogador.

Há mais de uma década o algoritmo Mersenne Twister é amplamente adotado em sistemas computacionais que precisam simular processos aleatórios. Isso se deve a suas vantagens, entre as quais, passar em vários testes estatísticos de aleatoriedade, como por exemplo, não ser enviesado, o que significa dizer que a chance do resultado de um sorteio de dado ser 1, é exatamente a mesma de ser 2, 3, 4, 5 ou 6.

É certo que desde o seu desenvolvimento, outros algoritmos pseudoaleatórios foram propostos, com algumas qualidades superiores, mas essas são limitadas a aplicações bastante específicas, como por exemplo, segurança criptográfica. Para o caso de sorteio de dados e cartas do jogo WAR, o algoritmo Mersenne Twister apresenta resultados suficientemente fortes para garantir a qualidade, a imparcialidade e a imprevisibilidade dos eventos durante uma partida.

Finalmente, a disponibilidade de implementações do algoritmo em linguagem Java e JavaScript foram fundamentais para a equipe de desenvolvimento do Gametrack decidir por adotá-lo. Utilizamos a linguagem Java no desenvolvimento de nosso servidor de jogos multiplayer e o JavaScript na página de Log da Dados para gerar nela a mesma sequência de números do servidor para a sua auditoria.

Os lançamentos dos dados podem ser simulados em duas velocidades diferentes:

• Normal: Esta é a velocidade usada em ataques com a opção de menu "Dados normais".
• Turbo: 8x mais rápido que a velocidade normal, selecionado em ataques com a opção de menu "Dados Turbo" ou com o uso da tecla "CONTROL" pressionada durante os ataques de território com mais de 10 unidades contra um com mais de 5.

Independentemente da velocidade dos ataques, os resultados serão exatamente os mesmos. A velocidade só altera o tempo utilizado para simular o lançamento, deixando-o mais rápido. Pode ser útil para economizar tempo em ataques múltiplos entre territórios com várias dezenas ou centenas de unidades, mas perceba que fica mais difícil para o jogador assimilar o que está acontecendo.

Guarde isso: os resultados não mudam com a velocidade dos ataques.

Outro detalhe importante é que a velocidade de ataque (normal ou turbo) é definida pelo jogador da vez, aquele que faz o ataque. Todos os outros jogadores e espectadores verão o ataque de acordo com a configuração que o atacante está usando. Isso evita que a reprodução de um jogo fique mais lenta que a de outro jogador, o que geraria atrasos nas passagens de turno. Além disso, dá liberdade para cada um configurar seus ataques da forma que preferir, sem depender dos outros. O jogador atacado não altera em nada os parâmetros do sorteio dos dados.

Na verdade, cada dado é sorteado de forma independente dos resultados dos outros dados. O que o jogo faz é, ao colocá-los no tabuleiro, já ordená-los de forma decrescente, isto é, do maior resultado de dado a esquerda para o menor a direita.

A animação faz isso tanto para os dados de ataque como para os de defesa, apenas para facilitar a comparação dos pares de dados ataque/defesa para saber quantas vitórias ocorreram. É apenas uma facilidade para agilizar a compreensão dos resultados para os jogadores e de forma alguma muda a aleatoriedade de cada dado.

O Log de Dados é uma janela paralela à janela do jogo, que registra cada lançamento de dados que é realizada ao longo da partida, em tempo real. Para abri-la, basta acessar durante a partida o menu Log de Dados no botão de menu de informações .

Nela é possível saber, para cada combate realizado, em ordem cronológica:

• O jogador atacante,
• O jogador que está na defesa,
• O território de origem do ataque,
• O território que foi atacado,
• A quantidade de dados de ataque e de defesa usados,
• O resultado de sorteio de cada dado,
• Quantidade de exércitos atacantes vitoriosos e quantidade derrotados,
• A evolução do índice de sorte no ataque (SA) do jogador atacante com o combate,
• A evolução do índice de sorte na defesa (SD) do jogador atacado com o combate e
• A evolução dos índices de sorte total (ST) dos dois jogadores com o resultado do combate.

Por limitações técnicas, o Log de Dados exibe apenas os combates realizados desde o momento em que o jogador entrou na partida, ficando ausentes as informações dos combates realizados antes de sua entrada.

Acima da tabela de registro de lances de dados, o Log de Dados apresenta um quadro resumo atualizado da sorte nos dados de cada jogador na partida, considerando todos os ataques realizados até o momento. Essa é uma forma rápida e precisa para todos saberem quem está tendo sorte ou azar no jogo.

Finalmente, ao término da partida, o Log de Dados divulga qual foi a chave semente do algoritmo Mersenne Twister adotada no princípio desta. Junto, é apresentada uma explicação detalhada da evolução da chave desde o início da partida, dos primeiros eventos de sorteio, como o embaralhar das cartas de territórios iniciais, das cartas de objetivo, das cartas de troca e a definição de quem começa a jogar. Os resultados de sorteio de dados do log também passam a apresentar detalhes da evolução da chave do algoritmo a cada sorteio, explicando como o resultado de cada dado foi obtido.

Basicamente o Log de Dados é útil para nossos jogadores em três propósitos:

• Indicar a sorte e azar de cada jogador ao longo da partida, lance a lance de dados;
• Registrar detalhadamente o resultado de cada dado de ataque e defesa em cada combate realizado;
• Explicar como cada sorteio efetuado na partida foi calculado pelo servidor;
• Auditar se os resultados nos sorteios seguiram o descrito pelo Gametrack neste FAQ.

De forma alguma o Log de Dados é indispensável para o andamento da partida. Ele existe apenas para fornecer aos nossos jogadores mais recursos para entender e confiar na honestidade do elemento "sorte" presente em toda partida de WAR.

Ao fim da partida, abaixo do quadro resumo da sorte nos dados de cada jogador, aparece um relato da evolução da chave do algoritmo Mersenne Twister a cada nova geração de valor pseudoaleatório, para cada sorteio necessário desde o início da partida. Nesta descrição há diversos links sublinhados que podem ser acessados com o mouse ou clique, nos quais são apresentados mais detalhes de como o número pseudoaleatório gerado foi usado para definir um resultado específico de sorteio do jogo. É possível inclusive ver o código-fonte em Java do servidor multiplayer utilizado para converter os números pseudoaleatórios em ações do jogo.

Além disso, na tabela de registro de lances de dados, após o fim da partida, ao se clicar ou passar o mouse sobre a imagem dos dados sorteados, é possível ver quais foram os números pseudoaleatórios gerados pelo algoritmo Mersenne Twister que definiram os resultados. Neste caso específico, a conversão do número de 32 bits para um valor de face de dados, de 1 a 6, é bem simples: é utilizado o resto da divisão do módulo número por 6, somado a 1 ( valorDoDado = 1 + mod(abs(número32bits), 6) ). Alguns cuidados são tomados para a conversão não ser enviesada, isto é, ter a mesma probabilidade de sortear qualquer uma das faces.

Com tudo isso, clicando-se em cada um dos links da descrição da inicialização da partida e depois em cada um dos dados desenhados na tabela de registro de lances de dados, é possível entender toda a evolução do valor da chave do algoritmo Mersenne Twister ao longo de toda a partida e como ele foi utilizado para definir a sorte caso a caso.

Os indicadores de sorte SA (sorte no ataque), SD (sorte na defesa) e ST (sorte total) são calculados para cada jogador após todo ataque realizado. Eles comparam cumulativamente a quantidade de exércitos vitoriosos em relação às médias referencias estatísticas esperadas para cada tipo de ataque, tanto para o jogador atacante como para o atacado. Valor positivo indica sorte do jogador, se negativo, indica azar.

Com o privilégio do empate entre valores de dados representa vitória da defesa, as probabilidades de quantidades de vitórias variam significativamente se o jogador está na posição de atacante ou de atacado. Por esse motivo, é interessante separar a sorte de cada jogador entre esses dois momentos, de quando se está atacando (SA) de quando se está defendendo (SD).

Por exemplo, se um jogador tem um SA positivo de 10% e SD negativo de 5%, isso significa que ele tem vencido 10% mais exércitos em seus ataques do que a média de referência, mas quando é atacado, ele tem perdido 5% a mais de exércitos do que o normal. Ele está com sorte nos seus ataques (SA positivo), mas azar nos combates em que se defende (SD negativo).

O ST é uma medida de sorte geral do jogador, que pondera o SA e o SD do jogador. Assim, se o jogador ataca bem mais do que é atacado, o valor de ST será mais próximo do valor de SA do que do valor de SD. Um ST positivo indica o quanto a mais percentualmente de exércitos o jogador tem vencido quando ataca e tem deixado de perder quando é atacado, comparado com as médias de referência, significando assim sorte. Já um ST negativo, por outro lado, significa azar, já que indica o quanto a mais percentualmente de exércitos ele tem deixado de vencer quando ataca e tem perdido a mais quando é atacado.

No quadro resumo da sorte nos dados dos jogadores é possível ver uma explicação detalhada da evolução destes indicadores a cada combate realizado na partida. Basta clicar ou passar o mouse sobre os valores tabelados de SA, SD e ST que surge uma explicação da variação destes indicadores. Quando ainda há poucos eventos de combate (menos de 10 exércitos atacados ou atacantes) para um jogador, seus indicadores não são calculados e apresentam o valor "NA". Isso é feito para evitar a exibição de eventuais valores bastante distantes da média de referência devido à baixa amostragem da medida, que torna o resultado impreciso e pouco significativo.

Não, devido ao grande volume de dados gerados ao longo de uma única partida que pode ter milhares de combates por horas, o Gametrack não grava essas informações em sua base de dados.

Essas informações ficam armazenadas apenas no navegador do jogador, enquanto ele estiver com a janela de Log de Dados aberta. Caso você deseje tornar permanente o registro de dados sorteados em uma partida, você tem a opção de usar a ação de "Salvar página" de seu navegador, gravando todo o conteúdo visto em uma pasta local de sua máquina.

Para entender exatamente como os sorteios de números de 32 bits pseudoaleatórios do algoritmo definem cada resultado no jogo, é preciso entender o código-fonte em Java disponível aqui.

Você pode pedir ajuda a um amigo de confiança que entenda de programação. Ele pode te garantir, como é nossa intenção, que o processo de sorteios explicado pelo Gametrack é realmente o aplicado em uma partida específica, conforme auditado por meio de sua janela de Log de Dados. Ele também pode te confirmar que em nossos exemplos de código não há nenhuma manipulação de lógica diferente da explicada neste FAQ.

Este sempre foi o grande "drama" do nosso jogo WAR em Shockwave, conforme pode ser visto neste outro FAQ. No passado fizemos várias tentativas diferentes para melhorar a confiança de nossos jogadores na imparcialidade do Gametrack nos processos aleatórios de nossos jogos. Até Março de 2017 foi impossível criar uma solução definitiva em razão do modelo de sorteios adotado na versão do jogo em Shockwave.

Na versão do WAR em Shockwave, o sorteio de dados sempre foi realizado pela aplicação cliente do jogador atacante. O código do aplicativo (jogo) dele sorteia tanto os resultados dos dados de ataque como os de defesa, para um determinado combate. Esses resultados são passados para o servidor, que finalmente o repassa para todos os demais jogadores. Até março de 2017, cada jogador aplicava uma sequência de sorteios aleatórios distinta dos demais para seus próprios ataques, tornando impossível criar um processo único para auditoria de todos os resultados de uma partida.

Esse modelo de sorteios independente entre jogadores é conveniente na lógica de jogo distribuída existente na solução adotada na versão do jogo WAR em Shockwave. Nela, o servidor de jogos não comanda a aleatoriedade da partida, apenas cumpre o papel de distribuidor dos eventos da partida entre todos os jogadores.

Em Março de 2017 foi lançada a versão 1.21 do War em Shockwave, a primeira em que foi alterada a lógica distribuída de sorteio de dados. Isso permitiu aplicar a mesma funcionalidade de auditoria de Log de Dados que foi inicialmente desenvolvida em 2016 para a versão do jogo WAR em HTML5. Infelizmente esta solução no Shockwave só foi vislumbrada depois que o modelo de sorteios foi repensado à luz da experiência que tivemos com o WAR em HTML5. Esta foi a verdadeira razão desta demora.

Já a versão do jogo WAR em HTML5 adota um modelo de lógica de partida centralizada em nossos servidores de jogos. Nela, as aplicações clientes passam a ser apenas interface dos jogadores para a lógica centralizada do jogo. Não só os sorteios pseudoaleatórios são realizados pelo servidor, como toda a lógica de evolução da partida é controlada por ele. Esse modelo é computacionalmente mais pesado, mas tem uma segurança maior contra fraudes e ataques maliciosos de jogadores mal-intencionados. Além disso, permitiu-nos desenvolver uma solução pública e definitiva que demonstrasse de forma transparente a imparcialidade da equipe do Gametrack em todos os sorteios de cada partida do WAR.

Não fizemos e nunca faremos:

• Favorecer resultados dos dados programaticamente para algumas espécies de jogadores. Assim, assinante não tem nenhuma vantagem sobre não-assinante (nos dados é claro, afinal, no resto do Gametrack assinante só tem vantagens!). A programação dos dados independe de qualquer informação pessoal, como sexo, origem, quantidade de jogos, ranking, apelido, idade, cidade ou qualquer dado cadastral.
• Aumentar as chances dos dados de ataques em relação aos de defesa (é tentador para resolver as reclamações, mas não resolveria e está fora da regra!).
• Criar peças especiais, tipo "RAMBO", que sozinhas aguentam o ataque de dezenas de outras. Se isto acontece, faz parte da estatística.
• Escolher a cada partida um jogador para ser o sortudo da vez (isso não está na regra!).
• Favorecer o resultado daqueles que mais reclamam sobre o assunto.

Isso acontece por causa de regra da vantagem do empate de valores de dados ser da defesa. Isto é, na comparação de par de dados ataque/defesa, se os valores são iguais dá vitória da defesa. Esta vantagem na regra dá um favorecimento à defesa bastante sensível quando se pensa por exemplo, em cenários do tipo 1 dado de ataque contra 3 de defesa.

Use nossa calculadora do War para ver suas chances de fracassar na conquista em um ataque.

Por mais raro que seja, às vezes vai acontecer em algum jogo com alguém. Por exemplo: vencer na Mega-Sena é muito mais difícil do que acontecer a derrota que você passou, mas mesmo assim é comum alguém vencer na Mega-Sena, afinal, são muitos apostando.
Do mesmo modo, numa partida de WAR acontecem centenas de ataques e conquistas. São milhares de partidas por dia, centenas de milhares de ataques. Assim, o resultado "absurdo" que você passou acaba tendo uma chance muito alta de acontecer pelo menos uma vez ao dia.
Por um pouco de azar, aconteceu com você. Mas pense pelo outro lado: vitórias pouco prováveis podem acontecer com você também!

Sugerimos 2 coisas:

• Que você passe um tempo entendendo as estatísticas de resultados nos dados de ataques e defesa para ver se você não tem uma expectativa errada de como funciona a regra.
• Que você passe a jogar com a janela de Log de Dados aberta, em paralelo com a partida. Nela, você pode acompanhar o quadro resumo da sorte e azar de cada jogador ao longo da partida, o que te dará uma medida real de quem está sendo beneficiado ou prejudicado pela sorte. Existe um elemento psicológico muito forte nestes momentos de combate entre exércitos, por isso, uma medida estatística pode desmistificar esta impressão.

Você não deve:

• Ficar reclamando no chat com os outros jogadores, culpando o jogo e os dados. Além de ser chato, estraga o clima de divertimento dos outros jogadores. Muitos não gostam de ficar ouvindo reclamações dos outros. Se xingar então, você pode até ser denunciado e punido.
• Mandar e-mail para nosso suporte reclamando que os dados roubam. Esse é o ponto já pacificado e a resposta do seu e-mail está aqui neste FAQ. Mas se por acaso você um dia vir resultado 7 nos dados ou algo do tipo, aí sim, pode entrar em contato conosco e nos avisar, já que isso só pode ser um bug mesmo!

Reclamações no chat se espalham como vírus. Muitos acabam reclamando para serem solidários com outros ou porque também querem culpar alguém pela sua derrota, desmerecendo a vitória dos outros. Tente ignorá-las, já que neste caso o que realmente te importa são os resultados de seus dados e não os dos outros.

Colabore para um ambiente amistoso no Gametrack. Sugerimos:

• Ignorar as reclamações OU
• Desmotivar esta atitude de quem reclama, pedindo para ele parar de reclamar e ler este FAQ. Afinal, quem gosta de jogar WAR quer conquistar o mundo, sem ficar ouvindo reclamações dos outros.