Conception pour la performance

Concevoir pour la performance signifie suivre quelques 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 dès le début peut vous faire gagner beaucoup de temps et d'efforts.

Appareils d'entrée de gamme

Les appareils d'entrée 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 insuffisante (OOM) :

• Si vous souhaitez prendre en charge des appareils d'entrée de gamme, choisissez au moins un appareil "de référence", testez votre jeu dessus tout au long du processus de développement et portez une attention particulière au taux de rafraîchissement et à l'utilisation de la mémoire. À mesure que vous identifiez des zones problématiques dans votre jeu, utilisez ces zones pour identifier les limites de votre appareil.

  Par exemple, vous pourriez tester un jeu avec les statistiques de débogage Rendu (ShiftF2) et Résumé (ShiftF2) activées. Si le taux de rafraîchissement commence à diminuer dans une zone particulièrement encombrée, vous pourriez examiner les chiffres Dessiner (scène) 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 référence.

  Ou vous pourriez examiner la Console de Développement (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 à rester en dessous alors que vous continuez à construire votre jeu.

  

• L'émulateur de périphérique dans Roblox Studio est utile pour vérifier le rapport d'aspect et les contrôles, mais n'est pas précis pour l'utilisation de la mémoire ; lorsque vous testez un jeu dans 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 manière dont vous pourriez penser à optimiser votre jeu pour les appareils mobiles d'entrée de gamme, voir Optimisation de la Construction et du Scripting dans le Monde Réel.

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 le taux de rafraîchissement.

  Par exemple, lorsque vous activez Workspace.EnableSLIMAvatars et que vous définissez la propriété LevelOfDetail des modèles de votre monde 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'appareils. Pour plus d'informations, voir SLIM et Améliorer les performances.

• Envisagez de diviser de grands lieux en lieux plus gérables 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 se téléportent d'un lieu à l'autre. Les bénéfices sur l'utilisation de la mémoire varient en fonction de la taille du lieu et de la manière dont 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 du nouveau contenu à 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 pour conserver le budget mémoire pour les textures qui sont centrales à votre jeu.

• Au fur et à mesure que vous créez des actifs, convertissez-les en paquets. Faire des paquets une partie de votre flux de travail aide à éviter le problème courant des actifs dupliqués avec des ID différents, 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 nécessitant très peu d'appels de dessin. Pour plus d'informations, voir Supprimer les textures dupliquées.

Translucidité

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

Script

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

• Trouvez des moyens de casser le code longue durée en morceaux gérables. Si une partie du code met 100 ms à s'exécuter et que vous l'exécutez chaque image, votre jeu ne peut tourner qu'à 10 FPS. Si vous décidez de n'exécuter le code qu'une fois par seconde dans un jeu qui fonctionne autrement à 60 FPS, 59 de vos images arrivent après 16,67 ms... et puis une après 100 ms, ce qui cause un tremblement déconcertant.

  Au lieu de cela, enquêtez sur la façon dont vous pouvez découper le code. Peut-être pouvez-vous effectuer 5 ms de travail par image, utiliser task.wait(), et avoir le calcul terminé 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 empêcher les fonctions d'être appelées inutilement la prochaine fois qu'un événement est déclenché.

• 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 écrasez-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ès.