Um layout de wave de chefe deve responder a uma pergunta: a base mantém pressão útil depois que o primeiro ponto de contato falha? Guias atuais da comunidade ligam chefes à progressão e às recompensas posteriores, mas não oferecem uma tabela oficial estável de ataques. Construa a partir do comportamento observado da lane e preserve uma linha de base de wave normal em vez de adivinhar um script específico.
Capture a linha de base da wave normal
Salve o layout da wave mais confiável antes de mover qualquer coisa. Registre o item em cada ponto de contato, onde o dano à distância começa e termina, qual lane vaza primeiro e como o core termina. Se houver slots, copie para um slot separado de chefe. Caso contrário, faça anotações suficientes para reconstruí-lo.
Execute a linha de base mais uma vez no servidor e update atuais. Um resultado de evento anterior não é uma comparação limpa. Use os mesmos recursos iniciais e evite comprar um upgrade permanente entre a linha de base e o primeiro teste de chefe.
O guia de Layouts de waves fornece o método de teste normal. A preparação de chefe começa somente depois que a configuração vence com consistência suficiente para revelar o que o alvo resistente muda.
Crie três camadas defensivas
A camada frontal estabelece contato e dá tempo para as armas agirem. Ela não deve conter todos os itens valiosos. A camada central mantém dano protegido e outro ponto de atraso ou controle. A camada final captura um vazamento e impede que uma única falha local exponha o core imediatamente.
Espalhe armas importantes por zonas de cobertura úteis. Um grupo concentrado pode parecer poderoso até que um chefe o alcance e remova todo o plano de dano de uma vez. Pressão distribuída também mostra qual trecho contribui mais. Mantenha um fallback capaz de agir mesmo depois que a frente cair.
Use armadilhas onde o caminho observado realmente passe por elas. Não coloque uma armadilha apenas porque uma captura copiada usa aquele tile; inventário, alcance, update ou comportamento da lane podem ser diferentes.
Meça o tempo ativo sustentado
Durante a tentativa, registre quando cada arma importante começa a atacar, quando para e por quê. Uma arma pode perder tempo ativo porque o alvo sai do alcance, a frente quebra cedo, outra lane fica descoberta ou a própria arma é removida. Cada causa exige uma correção diferente.
Compare a run do chefe com a linha de base normal. Se a mesma lane falha antes de o chefe importar, corrija o layout geral. Se a base controla grupos, mas trava no alvo resistente, aumente pressão sustentada ou duração de contato. Se o dano é suficiente até que um vazamento remova tudo, distribua as peças essenciais.
Não ranqueie por efeitos visuais. A medida útil é se uma mudança controlada atrasa a primeira falha, protege mais tempo ativo ou melhora o resultado final do core.
Mude uma variável por run
Escolha um ajuste: mover uma arma, trocar um bloco, reposicionar uma armadilha, adicionar um fallback ou comprar um upgrade justificado. Mantenha as outras posições e repita o mesmo encontro quando possível. Escreva o resultado observado antes da próxima mudança.
Se o encontro for marcado por evento, use uma wave normal comparável entre janelas para testar posicionamento. A descrição oficial de Tsunami diz que o evento ocorre a cada hora em 2026-08-05, mas a contagem regressiva ao vivo decide a disponibilidade. Não espere indefinidamente por uma run quando testes estáticos de layout podem continuar.
Um registro simples inclui data, servidor ou rótulo do update, nome do encontro, versão do layout inicial, uma mudança, primeira falha, resultado final e recompensa visível. Capturas ajudam como evidência, mas a mudança escrita é o que torna duas tentativas comparáveis.
Gaste upgrades depois de conferir a posição
Quando mover uma peça corrige a falha, guarde a moeda. Quando o mesmo item bem coberto ainda fica aquém, inspecione o painel permanente atual e escolha a menor compra que deve mudar o resultado. Teste imediatamente antes de comprar outra coisa.
Mais rolagens são justificadas quando falta uma função como contato resistente, pressão protegida ou fallback. Um upgrade de força é justificado quando a função certa já existe, mas o teste controlado mostra um limite numérico. Economia só é justificável quando o retorno chega antes do próximo investimento relevante em chefe.
Use o guia de Melhores upgrades para a ordem de decisão e Melhor base para um design mais amplo orientado pela falha.
Registre recompensas sem inventar taxas
Depois de uma vitória ou falha, capture a tela exata da recompensa. Registre nomes, quantidades, rótulos de raridade e se o item vai para inventário, Index, armazenamento de relics ou crafting. Uma recompensa não prova garantia, e várias ausências não provam impossibilidade.
Se aparecer uma relic ou material, preserve a primeira cópia até entender seu destino. Continue em Relics e Crafting em vez de depender de uma tabela de taxas sem data.
Erros em waves de chefe
- Sobrescrever o único layout de wave estável.
- Empilhar todas as armas valiosas atrás de um bloco frontal.
- Comprar vários upgrades antes de comparar uma run.
- Chamar uma arma de fraca quando ela estava fora de alcance ou parada.
- Publicar uma sequência de ataques a partir de uma tentativa sem controle.
- Tratar uma única recompensa como taxa de drop exata.
Devo usar meu layout normal para chefes?
Use-o como linha de base e adapte uma cópia para pressão sustentada e distribuída. Preserve o original para waves e progresso offline.
O que mudo primeiro depois de perder?
Mude o item ou posição responsável pela primeira falha repetível. Não redesenhe a partir apenas da tela final.
Ataques exatos de chefes estão listados aqui?
Não. A evidência auditada não apoiou um catálogo estável por chefe, então a observação ao vivo tem prioridade.