Projetar para desempenho significa seguir uma dúzia de melhores práticas ao construir sua experiência.Comparado com encontrar e corrigir problemas de desempenho mais tarde no processo de desenvolvimento, projetar para o desempenho pode economizar muito tempo e esforço.
Dispositivos de baixo nível
Dispositivos de baixo nível, particularmente dispositivos móveis, têm sérias limitações de memória e são suscetíveis a quedas devido a erros de memória insuficiente (OOM):
Se você quiser suportar dispositivos de baixo nível, escolha pelo menos um dispositivo "base" e teste sua experiência nele durante todo o processo de desenvolvimento, e preste muita atenção à taxa de quadros e ao uso de memória.À medida que você encontra áreas de problemas em sua experiência, use essas áreas para identificar os limites do seu dispositivo.
Por exemplo, você pode testar uma experiência com o Render ( ShiftF2 ) e Sumário ( ShiftF2 ) estatísticas de depuração habilitadas.Se a taxa de quadros começar a cair em uma área particularmente desordenada, você pode examinar os números de Desenhar (cena) e determinar que precisa permanecer abaixo de 1.000 chamadas de desenho e 1.000.000 triângulos para que a experiência funcione bem em seu dispositivo de base.
Ou você poderia examinar o Console do Desenvolvedor ( F9 ) e notar que o uso de memória é um pouco alto, a menos que você habilite streaming .Ter uma compreensão clara dos limites do dispositivo pode ajudá-lo a permanecer sob eles à medida que você continua a construir sua experiência.
O emulador de dispositivo no Roblox Studio é útil para verificar a proporção de aspecto e os controles, mas não é preciso para o uso de memória; quando você testa uma experiência no Studio, ela executa o servidor e o cliente, então o uso de memória é significativamente maior.
O Roblox não tem acesso a toda a memória de um dispositivo. Alguma quantia é necessária para o sistema operacional e outras aplicações.
De forma mais geral, testar em uma variedade de dispositivos pode ajudá-lo a verificar se a experiência corresponde às suas expectativas visuais e de desempenho em diferentes níveis de qualidade gráfica.Para um exemplo muito mais detalhado de como você pode pensar em otimizar sua experiência para dispositivos móveis de baixo nível, veja Real World Building and Scripting Optimization.
Streaming e teletransporte
Streaming de instância deixa o Roblox carregar e descarregar dinamicamente conteúdo 3D e é uma ótima opção para a maioria dos lugares, especialmente os maiores.A transmissão melhora os tempos de entrada, reduz a pegada de memória e aumenta a taxa de quadros.Para mais informações, veja Melhorar o desempenho.
Considere quebrar grandes locais em locais mais gerenciáveis e use teletransporte para mover os jogadores entre eles.Essa abordagem pode reduzir tempos iniciais de junção , mas impõe tempos de junção adicionais à medida que os jogadores se teletransportam de um lugar para outro.Os benefícios para o uso de memória variam dependendo do tamanho do local e se você habilitou o streaming.
Mesmo ignorando considerações de desempenho, você pode encontrar que ter vários locais simplifica o processo de desenvolvimento, especialmente se você adicionar regularmente novo conteúdo à sua experiência ou fazer parte de uma equipe maior.
Materiais e duplicação
Materiais integrados usam muito menos memória do que texturas personalizadas, mas podem não corresponder à sua visão artística.Tente usar materiais sempre que possível para conservar o orçamento de memória para as texturas que são centrais para sua experiência.
Ao criar recursos, converta-os em pacotes.Fazer pacotes parte do seu fluxo de trabalho ajuda a evitar o problema comum de recursos duplicados com diferentes IDs, que pode prejudicar o desempenho.
Ao adicionar malhas e texturas, use e reutilize-as em vez de importar cópias duplicadas.Ao redimensionar, girar e sobrepor, você pode criar ambientes ricos e variados que requerem poucas chamadas de desenho .Para mais informações, veja Remover texturas duplicadas.
Transparência
- Evite valores de transparência diferentes de 0 (visível) e 1 (invisível).Quando você usa transparência parcial, tenha especial cuidado para evitar sobrecarga de transparência alta.
Programação
Sempre que possível, escreva código baseado em eventos em vez de cálculos por quadro.A 60 FPS, o orçamento total para cada quadro é de 16,67 milisegundos (ms).Mesmo cálculos per-frame aparentemente menores podem usar uma porção significativa desse orçamento.
Encontre maneiras de quebrar código de longa execução em pedaços gerenciáveis.Se um pedaço de código leva 100 ms para executar e você o executa a cada quadro, sua experiência só pode funcionar a 10 FPS.Se você decidir executar apenas o código uma vez a cada segundo em uma experiência que, caso contrário, corre a 60 FPS, 59 de seus quadros chegam após 16,67 ms...e então um após 100 ms, o que causa um estalo violento.
Em vez disso, investigue como você pode quebrar o código.Talvez você possa realizar 5 ms de trabalho por quadro, use task.wait() , e tenha a conclusão da计算ação a cada 20 quadros, enquanto ainda mantém 60 FPS.Multithreading, às vezes chamado de Parallel Luau, também pode ajudar.
Use o método RBXScriptConnection:Disconnect() para interromper as funções de serem chamadas desnecessariamente na próxima vez que um evento dispara.
Não chame o mesmo método sempre que precisar de um valor. Chame o método uma vez, armazene o valor e depois substitua-o mais tarde, conforme necessário.
Não armazene tudo em ReplicatedStorage.O cliente carrega tudo o que está neste contêiner.Em vez disso, use ServerStorage para qualquer coisa que o cliente não precise acessar.