Projetar para desempenho significa seguir uma dúzia de melhores práticas enquanto você cria sua experiência. Em comparação com encontrar e corrigir problemas de desempenho mais tarde no processo de desenvolvimento, projetar para desempenho cedo pode poupar muito tempo e esforço.
Dispositivos de Baixo Fim
Dispositivos de baixo nível, especialmente dispositivos móveis, têm limitações de memória graves e são suscetíveis a quedros devido a erros de memória (OOM):
Se você quiser apoiar dispositivos de nível inferior, escolha um conjunto de dispositivos de base com certas características de desempenho, teste sua experiência em seus dispositivos ao longo do processo de desenvolvimento e preste muita atenção à taxa de quadros e ao uso de memória. À medida que você encontrar problemas na sua experiência, use essas áreas para identificar os limites de seus dispositivos.
Por exemplo, você pode testar uma experiência com o Render (
O emulador de dispositivos no Roblox Studio é útil para verificar o aspecto do ratio e controles, mas não é preciso para o uso de memória; quando você testa uma experiência no Roblox, ele 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 quantidade é necessária para o sistema operacional e outros aplicativos.
Mais geralmente, 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, see Construção e Scripting de Mundo Real .
Streaming e Teletransporte
streaming de instância permite que o Roblox carregue e descarregue dinamicamente conteúdo 3D e é uma ótima opção para a maioria das experiências, especialmente as maiores. O streaming melhora os tempos de entrada e reduz o footprint da memória e aumenta as taxas de quadro. Para mais informações, see Desempenho de Melhoria .
Quebre grandes locais em mais locais gerenciáveis e use teletransporte para mover os jogadores entre eles.
Materiais e Duplicação
Materiais incorporados 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, convertê-los em pacotes . Ao fazer pacotes parte do seu fluxo de trabalho, você ajuda a evitar o problema comum de recursos duplicados com diferentes IDs, o que pode afetar o performance.
Ao adicionar malhas e texturas, use e reutilize-as ao invés de importar cópias duplicadas. Ao redimensionar, girar e sobrepor, você pode criar ambientes ricos e variados que exigem chamadas de desenho muito raras. Para mais informações, see Remover texturas duplicadas .
Transparência
- Evite valores de transparência, exceto 0 (visível) e 1 (invisível). Ao usar parcial transparência, tenha cuidado para evitar alto transparência sobreposição.
Programação
Quando possível, escreva código baseado em eventos ao invés de cálculos por quadro. Em 60 FPS, o orçamento total para cada quadro é de 16.67 milissegundos (ms). Mesmo pequenos cálculos por quadro podem usar uma grande parte desse orçamento.
Encontre maneiras de quebrar código em tempo longo em pedaços manejáveis. Se um pedaço de código leva 100 ms para ser executado e você o executa em todos os quadros, sua experiência só pode ser executada em 10 FPS. Se você decidir executar apenas o código uma vez por segundo em uma experiência que normalmente é executada em 60 FPS, 59 de seus quadros chegam após 16.6
Em vez disso, investigue como você pode quebrar o código. Talvez você possa executar 5 ms de trabalho por quadro, usar task.wait() e ter o cálculo concluído a cada 20 quadros, ainda mantendo 60 FPS. Multithreading, às vezes chamado Parallel Luau, também pode ajudar.
Use o método RBXScriptConnection:Disconnect() para impedir que funções sejam chamadas desnecessariamente a próxima vez que um evento for disparado.
Não chame o mesmo método sempre que precisar de um valor. Chame o método uma vez, armazenar o valor e depois sobrescreva-o quando 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 precisa de acesso.