.
Reynolds:
Para garantir que nossas balas ainda tivessem um bom desempenho com tantos ao redor, tínhamos que mirar em duas áreas principais. A primeira coisa que precisávamos abordar eram as próprias balas. Com tantos spawns e movimentos ao mesmo tempo, a CPU leva uma carga significativa. Além disso, dividimos isso em duas partes: garantir que poderíamos gerar dezenas ou até centenas de balas em um quadro sem qualquer queda de quadro perceptível e garantir que poderíamos mover centenas de balas a cada quadro.
Percebemos que os ataques que geravam muitos marcadores de uma só vez causavam uma queda de quadro, já que a geração de atores é um processo bastante caro. Quando pedimos muitos deles ao mesmo tempo, é muito para a CPU lidar. Portanto, optamos por fazer pools de balas, para criar todas as balas necessárias para o combate no início do jogo e simplesmente teletransportá-las e ativá-las sempre que um ataque precisasse delas. Assim que colidem com qualquer coisa, podemos simplesmente desligá-los e devolvê-los à piscina, prontos para serem teletransportados novamente quando necessário.
Garantimos que tínhamos uma manipulação de matriz de alto desempenho para decidir quais balas pegar e, em seguida, tivemos uma desova eficiente. Isso teve um benefício enorme para o desempenho, pois não precisávamos mais criar ou destruir balas, elas estavam sempre prontas para uso sempre que precisávamos delas. Esse método significava que precisávamos garantir que o custo de memória fosse o menor possível, já que eles sempre existiram, então ficamos de olho nisso e mantivemos os marcadores o mais simples possível.
Com a desova abordada, focamos no movimento. Isso também é uma grande carga para a CPU, pois os marcadores precisam verificar as colisões a cada quadro. Portanto, mantivemos o movimento da bala o mais simples possível. Quando um comportamento mais complexo é necessário, nós o desativamos nos marcadores assim que esses comportamentos não estiverem mais afetando o voo. Também garantimos que toda a lógica de marcadores fosse executada nativamente em C++, pois isso oferece algum ganho de desempenho em relação ao script do Blueprints.
Agora que nossos marcadores eram tão eficientes quanto podíamos, precisávamos minimizar o uso da CPU em outros lugares para que esses marcadores não causassem quedas de quadro em níveis com muitas partes móveis. Para isso, usamos as Profiling Tools da Unreal para monitorar os tempos de CPU dentro e fora do combate: percorrendo os níveis para ver o que está tomando tempo e reduzindo esse tempo o máximo possível sem afetar a jogabilidade em outros lugares. Faríamos isso fora do combate primeiro para reduzir o uso da CPU em segundo plano e, em seguida, focar no combate especificamente para garantir que os sistemas de combate não estivessem lutando devido a algo específico desse nível, como espaços maiores fazendo com que as balas sobrevivessem por mais tempo, o que significa que tínhamos mais deles se movendo do que o pretendido. Poderíamos então resolver esses problemas caso a caso, geralmente modificando os sistemas de combate para garantir que fossem eficientes, independentemente de como nossos ambientes foram projetados.
A equipe usou Niagara para gerar suas balas?
Reynolds: Inicialmente, usamos partículas de Niágara para nossas balas, mas depois de algumas iterações, acabamos mudando para malhas estáticas. Com tantas balas na tela ao mesmo tempo, seus visuais foram mantidos simples e, portanto, eles não estavam usando muito do poder que Niagara oferece. Tanto como resultado disso quanto pelo fato de que alguns aspectos das partículas do Niágara são calculados na CPU que queríamos liberar para lidar com o comportamento dos marcadores, decidimos que as malhas nos dariam melhor desempenho sem uma queda na qualidade visual.
Correção: Nos primeiros dias do projeto, usávamos exclusivamente o Cascade para lidar com todas as nossas partículas, pois ninguém na equipe conhecia o Niagara. À medida que o projeto avançava, começamos a explorar o Niágara e rapidamente aprendemos o quanto ele é mais poderoso e flexível do que o Cascade e agora usamos exclusivamente o Niágara para todas as nossas partículas. Existem muitos benefícios em usar o Niagara para repassar todos eles, mas a facilidade com que os sistemas podem ser modificados por meio de Blueprints é facilmente uma das minhas coisas favoritas.
.
