Scriptable Objects

Bady Mebarki,
Développeur XR @Numix

Je vais aujourd’hui vous présenter un des ingrédients qui font la réussite technique de notre solution DeepTwin. Mais comme pour le Coca-Cola, nous ne vous dévoilerons pas le dosage exact, afin de garder notre recette secrète.

Pour vous présenter rapidement DeepTwin : il s’agit de notre moteur maison, avec lequel nous développons nos formations en réalité virtuelle.

DeepTwin est un peu comme une boîte à outils comprenant des briques technologiques correspondant à des besoins génériques.

Vous désirez récupérer le bilan pédagogique et suivre chacun de vos apprenants en s’interfaçant avec votre Learning Management System (LMS) ? Il suffit d’importer le module et de le configurer pour qu’il réponde à vos exigences !

Vous souhaitez un mode collaboratif pour se retrouver à plusieurs dans votre formation ? Nous avons à disposition une architecture réseau éprouvée (en local ou à distance) qui peut être déployée.

Notre solution est beaucoup moins contraignante et limitée qu’un outil auteur. Et comme il s’agit de notre mayonnaise maison (encore une métaphore culinaire), on peut aisément créer de nouveaux modules pour répondre à vos besoins spécifiques.

Vous avez donc là, le parfait équilibre entre une application sur étagère et une application sur mesure !

Si cette introduction vous a convaincu et que vous souhaitez digitaliser une formation avec nous, n’hésitez pas à nous contacter

LA PROBLÉMATIQUE

Tous les développeurs vous le diront, il est en général très difficile de réutiliser le code d’une fonctionnalité faite pour un projet afin de l’intégrer dans un autre projet, si ça n’a pas été pensé dès sa conception comme un module indépendant. Tout comme il est difficile de maintenir et tester une application complexe fonctionnalité par fonctionnalité car en général tout est relié et rien ne fonctionne réellement de manière indépendante.

C’est pour répondre à ces problèmes que DeepTwin a été créé. Nous cherchions à concevoir un moteur nourrit de divers modules répondant à un maximum de besoins clients.

Mais attention, notre but n’est pas de vous livrer une application préfabriquée car le temps que nous gagnons grâce à ces briques technologiques nous permet d’accorder plus de temps sur la qualité globale de l’application. Et ainsi nous pouvons nous attarder plus longuement sur la conception et le développement de vos exigences spécifiques.

THE GAME CHANGER

En 2017, la Unite à lieu à Austin au Texas, il s’agit d’un grand événement organisé par Unity afin de réunir la communauté internationale de créateurs qui utilise le moteur de jeu Unity (avec lequel nous développons nos solutions de serious game).

Nous n’avons pas pu aller aux USA mais heureusement une grande partie des conférences ont été publiées sur la chaîne youtube d’Unity. Et comme dans notre métier la veille technologique doit être constante, mes collaborateurs et moi même, avons commencé à visionner les vidéos proposées. On était loin de se douter qu’une conférence allait profondément changer notre façon de concevoir une application sur Unity !

Voici la vidéo en question, de Ryan Hipple (ingénieur principal chez Schell Games) :

ARCHITECTURE DE LA RENAISSANCE

Pour résumer rapidement la vidéo : avec quelques exemples, ce cher Ryan va nous présenter comment les Scriptable Objects sont devenus la base architecturale de ses projets.

Pour rapidement expliquer ce que sont les Scriptable Objects : Il s’agit de conteneurs de données que l’on doit préconfigurer. On peut par exemple utiliser ces conteneurs pour faire une base de données.

Mais Ryan ne va pas se contenter de décentraliser les données avec des Scriptables Objects, il va aussi permettre à ces données d’exécuter du code lorsqu’elles sont mises à jour.

Dans la vidéo, Ryan illustre ce système avec la gestion des points de vie. Quand le joueur perd des points de vie, la barre de vie se met à jour automatiquement alors que les composants “Joueur” et “Barre de vie” ne sont pas liés et ne se connaissent pas. La seule chose qu’ils ont en commun c’est la référence vers le Scriptable Object “Points de vie”. Et c’est donc lui, qui lorsqu’il est mis à jour par le “Joueur” va exécuter du code côté “Barre de vie” pour se mettre à jour visuellement.

C’est à ce moment-là que votre visage devrait afficher un mélange subtil entre la perplexité et l’euphorie car oui, on va avoir des éléments décentralisés auxquels on va pouvoir abonner des fonctions !

D’après Ryan, cette façon d’organiser son code permet de rendre son projet :

  • Modulaire, car les systèmes ne seront plus fortement interdépendants,  
  • Editable, car configuration possible facilement même par des non-développeurs et temps de test plus rapides
  • Debuggable, car les comportement sont isolés

UNE IMAGE VAUT MILLE LIGNES DE CODE

Je vais maintenant vous illustrer ça, et sans montrer la moindre ligne de code, afin de ne pas faire fuir les plus sensibles d’entre vous.

Pour accéder à certaines valeurs, comme par exemple, la durée de la session, il nous fallait avoir en référence le script « ScenarioManager ».

Et à chaque fois que cette valeur était mise à jour, c’est le le script « ScenarioManager » qui s’occupait de mettre à jour la valeur chez les autres scripts. Sur le schéma, vous pouvez voir les aller / retour qu’entraîne cette interdépendance.

En gros c’est comme si un chef en cuisine devait aller prévenir chacun de ses assistants à chaque fois qu’un plat était prêt à sortir du four.

Dans la capture d’écran ci-dessus vous pouvez voir des Scriptable Objects de type « NumixEvent ». Il s’agit d’un équivalent des scripts que Ryan avait nommé « GameEvent » mais avec un zeste de Numix. Et si vous avez suivi, il s’agit tout simplement de conteneurs de données.

Voici maintenant une capture d’écran du « Menu InGame » que l’utilisateur peut ouvrir en cours de partie. Le contenu dynamique de cette interface, c’est-à-dire, le titre, la durée, le taux de complétion et le nombre d’étapes effectuées, est géré via les Scriptable Objects.

Comme illustré sur ce schéma, la durée de la session est utilisée par différents composants.

De ce fait, ceux-ci sont reliés seulement au Scriptable Object au lieu d’être reliés à un script. Cela réduit la dépendance entre composants et permet, par exemple, d’ajouter ou supprimer des éléments de l’UI facilement. On peut aussi grâce à cette architecture tester rapidement l’UI en modifiant le Scriptable Object lui-même.

Pour en revenir à notre comparaison avec la cuisine, avec cette façon de faire, le four déclenche une alarme lorsque le plat est prêt et tout le personnel est donc au courant et traitera cette information comme bon lui semble.

CONCLUSION

Vous l’avez donc compris, notre moteur DeepTwin a lui aussi, comme base, les Scriptable Objects. Et c’est notamment grâce à ce système que notre boîte à outils est aussi modulaire.

Nous pouvons ainsi ajouter et retirer facilement des fonctionnalités dans nos projets car nous avons pris soin de ne pas les rendre interdépendantes.
Donc comme pour le Coca-Cola si vous ne voulez pas de sucre c’est possible par contre si vous voulez y mettre de la vanille on sera là pour vous accompagner et vous orienter vers une meilleure idée.

Fondée en 2014 par Jeff Sebrechts et son associée Amélie Raffenaud, Numix se spécialise dans la création de parcours de formation immersifs et digital Learning pour ses clients grands comptes. Véritables jumeaux numériques, ces simulateurs immersifs pour l’industrie sont reconnus pour leur qualité technique et pédagogique. En recherche constante de nouveaux défis, notre équipe de 15 collaborateurs développe les outils de demain pour révolutionner le monde de la formation.

Partagez cet article

Twitter
Facebook
LinkedIn