> Programação
Com a avaliação dos movimentos e o gerenciamento das combinações de ataque, o mapa de danos é um grande essencial em LeekWars. O principal objetivo é poder avaliar, em função do adversário, um nível de perigo de cada caixa de forma a poder recuar para uma caixa de menor perigo no final da jogada. A maneira mais fácil é criar um array associativo: dangerMap=[ cell1:danger1 , cell2:danger2 , ... ], possivelmente limitado às suas células acessíveis. Para isso, vários algoritmos são possíveis
Geralmente, essa é a primeira ideia que vem à mente ao criar um algoritmo de avaliação de perigo. A ideia é a seguinte:
/* -para cada uma das minhas células acessíveis -para cada oponente -para cada célula acessível do oponente -para cada arma do oponente -se ele pode atirar no meu celular de seu celular adicionar uma "pontuação de perigo" ao meu celular */
A escolha da pontuação é parte integrante do seu algoritmo: você pode colocar "+1" nela, ou calcular o dano potencialmente infligido, ... Existem tantas maneiras de refinar essa avaliação quanto jogadores 😉
O grande problema desse algoritmo é que ele é extremamente ganancioso nas operações! Portanto, geralmente é necessário otimizá-lo muito rapidamente.
A primeira coisa a fazer é evitar que seu alho-poró "trave"... Então você tem que, em algum lugar do código, fazer um teste em getOperations() e sair dos loops se o número de operações ficar muito próximo de o limite: você terá apenas uma avaliação parcial do perigo, mas seu alho-poró ainda poderá se mover um mínimo 😉
Para a otimização em si, um dos primeiros princípios que devem guiar sua abordagem é, acima de tudo, evitar repetir as mesmas operações várias vezes nos loops: é melhor neste caso preparar as coisas em tabelas do que lembrar. Então, por exemplo, no loop mais interno que calcula a "pontuação de perigo", se você ligar para getStrength(Enemy) nele, você chamará essa função de volta milhares de vezes. A ideia é então calcular a força do inimigo apenas uma vez e armazená-la em uma variável antes de fazer os loops internos. Você já começará a ganhar algumas centenas de milhares de negociações! Portanto, procure elementos de loops "internos" que não dependam da variável do loop, mas apenas de um loop "externo": você pode rastrear esses elementos de volta ao seu loop.
Se o seu algoritmo continuar caro, outro caminho bastante estético para otimização é diminuir a resolução dessa avaliação. Você pode, por exemplo, não testar todas as casas acessíveis (suas e/ou do adversário), mas, por exemplo, apenas aquelas que requerem um número par de pontos de movimento. "Basta" então preencher as lacunas obtidas pela interpolação dos valores nos quadrados vizinhos (média dos vizinhos, máximo dos vizinhos, máximo da média entre duas linhas, etc.). Essa abordagem é menos precisa, mas, com o exemplo dos PMs pares, consome cerca de 4x menos que o primeiro algoritmo.
Para continuar as otimizações, você terá que pensar em pré-computar as coisas, geralmente na primeira rodada, armazenar em grandes (ou muitos) arrays certas coisas que você deve recalcular e que nunca mudam, ou mesmo atualizar e atualizar certos valores cada turno (no nosso exemplo, a força do alho-poró inimigo).
Este algoritmo pré-calcula um mapa de perigo uma vez no início da luta. Barato, é muito menos preciso, mas permite que você tenha rapidamente a lista de áreas do mapa de combate que geralmente são perigosas. Consiste em avaliar, no início do turno, para cada célula do mapa de combate, todas as células que permitem atirar nela com as armas que o(s) inimigo(s) possuem: um quadrado que só pode ser alcançado a partir de 5 outros quadrados terão então uma pontuação muito menor do que um quadrado alcançável por 200 outros quadrados! Pode ser sensato tentar recuar para áreas de "baixo perigo" e fazer com que o inimigo permaneça em áreas de "alto perigo".
Impossible de charger les données du jeu.
Vérifiez votre connexion et réessayez.