Concevoir pour la performance

Concevoir pour la performance signifie suivre un certain nombre de meilleures pratiques lorsque vous construisez votre jeu. Comparé à la détection et à la correction des problèmes de performance plus tard dans le processus de développement, concevoir pour la performance tôt peut vous faire gagner beaucoup de temps et d'efforts.

Appareils bas de gamme

Les appareils bas de gamme, en particulier les appareils mobiles, ont de sévères limitations de mémoire et sont susceptibles de planter en raison d'erreurs de mémoire insufisante (OOM) :

• Si vous voulez prendre en charge les appareils bas de gamme, choisissez au moins un appareil de "base", testez votre jeu sur celui-ci tout au long du processus de développement, et faites attention à la fréquence d'images et à l'utilisation de la mémoire. En identifiant les zones problématiques dans votre jeu, utilisez ces zones pour déterminer les limites de votre appareil.

  Par exemple, vous pourriez tester un jeu avec les statistiques de débogage Render (ShiftF2) et Summary (ShiftF2) activées. Si la fréquence d'images commence à chuter dans une zone particulièrement encombrée, vous pourriez examiner les chiffres Draw (scene) et déterminer que vous devez rester en dessous de 1 000 appels de dessin et 1 000 000 triangles pour que le jeu fonctionne bien sur votre appareil de base.

  Ou bien vous pourriez examiner la Console Développeur (F9) et noter que l'utilisation de la mémoire est un peu élevée à moins que vous n'activiez le streaming. Avoir une compréhension claire des limites de l'appareil peut vous aider à les respecter pendant que vous continuez à construire votre jeu.

  

• L'émulateur d'appareil dans Roblox Studio est utile pour vérifier le rapport d'aspect et les contrôles, mais il n'est pas précis pour l'utilisation de la mémoire ; lorsque vous testez un jeu dans le Studio, il exécute le serveur et le client, donc l'utilisation de la mémoire est significativement plus élevée.

Plus généralement, tester sur une variété d'appareils peut vous aider à vérifier que le jeu correspond à vos attentes visuelles et de performance à différents niveaux de qualité graphique. Pour un exemple beaucoup plus détaillé de la façon dont vous pourriez penser à optimiser votre jeu pour les appareils mobiles bas de gamme, consultez Optimisation réaliste de la construction et du scripting.

Streaming et téléportation

• Le streaming d'instances permet à Roblox de charger et de décharger dynamiquement du contenu 3D et est une excellente option pour la plupart des lieux, en particulier les plus grands. Le streaming améliore les temps de connexion, réduit l'empreinte mémoire et augmente la fréquence d'images.

  Par exemple, lorsque vous activez Workspace.EnableSLIMAvatars et définissez la propriété LevelOfDetail de vos modèles mondiaux sur SLIM, vous pouvez créer des mondes avec des espaces sociaux et des événements bondés qui restent visuellement peuplés tout en s'adaptant à une large gamme de capacités d'appareil. Pour plus d'informations, consultez Améliorer les performances.

• Envisagez de diviser les grands lieux en plus petits et d'utiliser la téléportation pour déplacer les joueurs entre eux. Cette approche peut réduire les temps de connexion initiaux, mais impose des temps de connexion supplémentaires lorsque les joueurs téléportent d'un lieu à un autre. Les bénéfices en matière d'utilisation de la mémoire varient en fonction de la taille du lieu et de si vous avez activé le streaming.

  Même en ignorant les considérations de performance, vous pourriez constater que le fait d'avoir plusieurs lieux simplifie le processus de développement, surtout si vous ajoutez régulièrement de nouveaux contenus à votre jeu ou si vous faites partie d'une plus grande équipe.

Matériaux et duplication

• Les matériaux intégrés utilisent beaucoup moins de mémoire que les textures personnalisées, mais peuvent ne pas correspondre à votre vision artistique. Essayez d'utiliser des matériaux chaque fois que possible afin de conserver votre budget mémoire pour les textures qui sont centrales à votre jeu.

• Lorsque vous créez des actifs, convertissez-les en packages. Faire de l'ajout de packages une partie de votre flux de travail aide à éviter le problème courant des actifs en double avec différents ID, ce qui peut nuire à la performance.

• Lorsque vous ajoutez des maillages et des textures, utilisez-les et réutilisez-les plutôt que d'importer des copies dupliquées. En redimensionnant, en faisant pivoter et en superposant, vous pouvez créer des environnements riches et variés qui nécessitent très peu de demandes de dessin. Pour plus d'informations, consultez Supprimer les textures en double.

Transparence

• Évitez les valeurs de transparence autres que 0 (visible) et 1 (invisible). Lorsque vous utilisez une transparence partielle, faites particulièrement attention à éviter le sur-dessin de haute transparence.

Scripting

• Chaque fois que possible, écrivez du code basé sur des événements plutôt que des calculs par trame. À 60 FPS, le budget total pour chaque trame est de 16,67 millisecondes (ms). Même des calculs par trame apparemment mineurs peuvent utiliser une partie significative de ce budget.

• Trouvez des moyens de diviser le code à long terme en morceaux gérables. Si un morceau de code prend 100 ms à s'exécuter et que vous l'exécutez à chaque image, votre jeu ne peut fonctionner qu'à 10 FPS. Si vous décidez d'exécuter le code une fois par seconde dans un jeu qui fonctionne autrement à 60 FPS, 59 de vos images arrivent après 16,67 ms... et ensuite une après 100 ms, ce qui provoque un décalage désagréable.

  Au lieu de cela, examinez la manière dont vous pouvez diviser le code. Peut-être pouvez-vous effectuer 5 ms de travail par trame, utiliser task.wait(), et avoir le calcul complet toutes les 20 images tout en maintenant 60 FPS. Le multithreading, parfois appelé Luau parallèle, peut également aider.

• Utilisez la méthode RBXScriptConnection:Disconnect() pour arrêter les fonctions d'être appelées inutilement la prochaine fois qu'un événement se déclenche.

• Ne pas appeler la même méthode chaque fois que vous avez besoin d'une valeur. Appelez la méthode une fois, stockez la valeur, puis réécrivez-la plus tard si nécessaire.

• Ne stockez pas tout dans ReplicatedStorage. Le client charge tout ce qui se trouve dans ce conteneur. Au lieu de cela, utilisez ServerStorage pour tout ce à quoi le client n'a pas besoin d'accéder.