Auteurs : Kavita Chodavarapu @CKnew234 et Chris Gagnon
En mars dernier, nous vous avions présenté nos plans pour améliorer concrètement deux aspects qui influencent directement votre façon de créer dans l’UEFN : la stabilité et les temps d’itération.
En matière de stabilité, cela signifiait davantage de tests d’îles créées par les développeurs, une meilleure couverture des régressions et une remontée plus précoce des défauts à haut risque dans le cycle de publication.
En matière de temps d’itération, nous nous étions engagés à réduire significativement le temps nécessaire pour intégrer vos changements dans une session en direct.
Nous nous étions également engagés à vous tenir informés régulièrement, en indiquant à la fois les points d’avancée et ceux sur lesquels il reste du travail à accomplir.
Voici les dernières nouvelles.
Nos progrès
Temps d’itération
Dans notre précédent article, nous nous étions engagés à réduire les temps d’itération, et nous avons accompli de réels progrès, en réduisant le temps nécessaire pour envoyer les changements de 40 % en moyenne à ce jour. La baisse est encore plus marquée sur les projets volumineux, où nous avons constaté des réductions allant jusqu’à 70 %.
Cette amélioration résulte d’un certain nombre de changements qui réduisent les temps d’envoi :
* Préparation incrémentielle : le préparateur identifie et traite désormais uniquement les ressources qui ont changé depuis votre dernier envoi, au lieu de retraiter l’ensemble de votre projet.
* Zen DDC : une nouvelle infrastructure de cache de données dérivées qui réduit le temps passé à récupérer et à valider les ressources préparées, raccourcissant ainsi la boucle d’itération “play on client”.
* Autres améliorations du pipeline de préparation et de mise en ligne/téléchargement : vitesses de transfert de fichiers plus rapides, temps d’attente dans la file d’attente réduits, validation des ressources améliorée et améliorations de la compilation Verse.
* Et plus encore : amélioration des temps de chargement côté serveur et côté client, parallélisation des étapes de préparation et de validation, ainsi que de nombreuses optimisations sur l’ensemble du processus d’itération.
Nous avons également apporté des améliorations significatives à la modification en direct :
* Les fonctionnalités de modification en direct sont disponibles pendant que votre jeu est en cours d’exécution.
* Vous pouvez mettre le jeu en pause, quitter votre pion et examiner l’état du jeu à des fins de débogage.
* La prise en charge des séquences de niveau et des bus audio a été étendue.
* Une nouvelle IU pour consulter la liste de modifications des transactions qui ont lieu en direct ou qui nécessitent un envoi, avec des améliorations de l’expérience utilisateur pour l’itération et de nombreux correctifs de bogues pour les fonctionnalités de modification en direct existantes.
Notre travail n’est pas terminé. L’expansion de la modification en direct restera une priorité pour améliorer l’expérience d’itération, la compilation distribuée des shaders est toujours en cours et nous avons prévu plusieurs autres améliorations cette année pour continuer à réduire les temps d’itération.
Stabilité
Depuis la version 39.50, nous avons considérablement réduit le nombre de régressions de gravité élevée atteignant les développeurs. Nous avons étendu les tests d’îles créées par des développeurs, renforcé notre processus d’escalade des régressions et amélioré l’analyse des causes profondes. Résultat : des améliorations significatives sur les versions 40.00 et 41.00, mesurables à travers deux indicateurs clés, qui sont le taux d’échappement des défauts (DER) et le nombre de défauts majeurs échappés.
Cela signifie que nous réussissons de plus en plus à détecter les régressions les plus perturbatrices et les plus impactantes pour les développeurs avant la publication.
Nous avons également déployé dans la version 41.00 des mises à jour des outils de gestion de l’intégrité des ressources ainsi que du profileur spatial, afin de vous offrir davantage de visibilité sur les problèmes liés aux ressources avant qu’ils ne provoquent des plantages ou des blocages. Nous continuons à travailler à l’amélioration de ces outils dans les futures versions.
Ce sur quoi nous travaillons
La stabilité s’est considérablement améliorée sur nos indicateurs les plus critiques, mais certains domaines restent encore irréguliers, notamment Scene Graph, Join-in-Progress (JIP), l’IU/UMG personnalisée, la validation, la publication et le matchmaking. Beaucoup de ces régressions impliquent des interactions entre plusieurs systèmes, proviennent de modifications effectuées plusieurs semaines ou mois auparavant ou n’apparaissent qu’à grande échelle lors de tests développeurs tardifs dans le cycle de publication.
Nos priorités actuelles :
* Étendre la couverture de l’automatisation pour les flux de travail Scene Graph et JIP
* Renforcer les tests à l’échelle des développeurs plus tôt dans les cycles de publication
* Durcir les critères de validation pour les changements à haut risque
* Améliorer la visibilité sur les régressions connues et les correctifs prévus
Nous avons également commencé à publier des listes de problèmes connus avant les publications chaque fois que possible, ce qui donne aux développeurs une visibilité plus précoce sur les régressions confirmées et les correctifs prévus.
Et après ?
Nous continuerons à parler ouvertement des défis qui restent à relever : les développeurs méritent une communication honnête sur la complexité de ces outils. Notre engagement est clair, nous devons continuer à mieux détecter les régressions à fort impact, à communiquer avec plus de transparence et à partager les données concrètes derrière ce travail.
Merci de continuer à créer avec l’UEFN et merci pour vos retours, vos signalements de bogues et vos réponses aux enquêtes sur la stabilité, qui contribuent à définir ces priorités.