Diseñar para el rendimiento significa seguir un puñado de mejores prácticas a medida que construyes tu experiencia. En comparación con encontrar y corregir problemas de rendimiento más tarde en el proceso de desarrollo, diseñar para el rendimiento temprano puede ahorrarte mucho tiempo y esfuerzo.
Dispositivos de gama baja
Los dispositivos de gama baja, en particular los dispositivos móviles, tienen limitaciones de memoria severas y están propensos a los errores de memoria (OOM) debido a los errores de memoria (OOM):
Si desea apoyar dispositivos más antiguos, elige un conjunto de dispositivos de nivel inferior con ciertas características de rendimiento, prueba tu experiencia en ellos durante todo el proceso de desarrollo y presta mucha atención a la tasa de marco y el uso de memoria. Cuando encuentras áreas de problema en tu experiencia, usa esas áreas para identificar los límites de tus dispositivos.
Por ejemplo, puede probar una experiencia con el renderizado (esc
El emulador de dispositivos en Roblox Studio es útil para verificar el rendimiento y los controles, pero no es exacto para el uso de memoria; cuando prueba una experiencia en Studio, ejecuta el servidor y el cliente, por lo que el uso de memoria es significativamente más alto.
Roblox no tiene acceso a toda la memoria de un dispositivo. Se requiere una cantidad para el sistema operativo y otras aplicaciones.
Más generalmente, probar en una variedad de dispositivos puede ayudarlo a verificar que la experiencia coincida con sus expectativas visuales y de rendimiento en diferentes niveles de calidad gráfica. Para un ejemplo mucho más detallado de cómo pensar en optimizar su experiencia para dispositivos móviles de gama baja, consulte Construcción y optimización del mundo real .
Transmisión y Teletransportación
La transmisión de instancia deja que Roblox cargue y descargue dinámicamente 3D y es una gran opción para la mayoría de las experiencias, especialmente las más grandes. La transmisión mejora los tiempos de unión, reduce el rendimiento de memoria y aumenta las tasas de fotogramas. Para obtener más información, see Mejorando el rendimiento .
Rompe grandes lugares en espacios más manejables y usa teletransportación para mover a los jugadores entre ellos.
Materiales y duplicación
Los materiales integrados usan mucho menos memoria que las texturas personalizadas, pero puede que no coinciden con su visión artística. Intenta usar los materiales siempre que sea posible para conservar el presupuesto de memoria para las texturas que son centrales para su experiencia.
Al crear recursos, conviértelos en paquetes . Hacer que los paquetes sean parte de su flujo de trabajo ayuda a evitar el problema común de recursos duplicados con diferentes ID, lo que puede dañar el ejecución.
Cuando agrega mallas y texturas, úsalas y reutilícelas en lugar de importar copias duplicadas. Al cambiar el tamaño, girar y superponerlas, puede crear ambientes ricos y variados que requieren muy pocas llamadas de dibujo . Para obtener más información, consulte Eliminar texturas duplicadas .
Transparencia
- Evite los valores de transparencia que no son 0 (visibles) y 1 (invisibles). Cuando use parcialmente la transparencia, tenga especial cuidado para evitar sobrecargar transparencia.
Programación
Siempre que sea posible, escriba código de eventos en lugar de cálculos por marco. En 60 FPS, el presupuesto total para cada marco es 16.67 milisegundos (ms). incluso los pequeños cálculos por marco pueden usar una gran parte de ese presupuesto.
Encuentra formas de romper el código de larga duración en pedazos manejables. Si un pedazo de código toma 100 milisegundos para ejecutarse y los ejecutas todos en cada marco, tu experiencia solo puede ejecutarse a 10 FPS. Si decides ejecutar el código una vez por segundo en una experiencia que normalmente se ejecuta en 60 FPS, 59 de tus marcos llegan después de 16.67 ms
En cambio, investiga cómo puedes descompilar el código. Tal vez puedas realizar 5ms de trabajo por marco, usar task.wait() y tener el cálculo completado cada 20 marcos mientras se mantiene 60 FPS. Multithreading , a veces llamado Parallel Luau, también puede ayudar.
Usa el método RBXScriptConnection:Disconnect() para evitar que se llamen las funciones no necesariamente la próxima vez que se activa un evento.
No llame el mismo método cada vez que necesite un valor. Llamar el método una vez, almacenar el valor y luego sobrescribirlo según sea necesario.
No almacene todo en ReplicatedStorage . El cliente carga todo lo que está en este contenedor. En cambio, use ServerStorage para cualquier cosa que el cliente no necesite.