Adapter le jeu numérique par âge : Comment StoryToys a construit l'application LEGO® Bluey

StoryToys a été fondée en 2008 avec la mission d'apporter des applications éducatives aux enfants de tous âges. Au cours des 17 dernières années, ils ont publié des applications, y compris Hungry Caterpillar Play School, LEGO® DUPLO® World, Disney Coloring World et LEGO® DUPLO® Peppa.
Leur dernier titre, LEGO® Bluey, a été lancé le 14 août 2025. Développé en collaboration avec le groupe LEGO et BBC Studios, il cible les enfants de deux à quatre ans et allie amusement et apprentissage précoce.
Nous avons parlé avec Devon Wolfgang, l'ingénieur principal de StoryToys, et Ryan Dykes, le développeur principal de l'application, des défis et des jalons de la conception d'une application pour des enfants de différents âges et niveaux de compétences motrices, d'intelligence émotionnelle, de résolution de problèmes et d'humour.
Quel a été le plus grand défi technique lors de la création de l'application ?
Ryan Dykes : Concevoir pour des enfants de deux et quatre ans était un défi unique. Les enfants si jeunes interagissent très différemment avec les applications – les enfants de deux ans explorent souvent en tapotant sans comprendre pleinement les mécanismes, tandis que les enfants de quatre ans visent à les maîtriser.
Par exemple, dans l'activité de surf, les jeunes joueurs pourraient taper pour voir Bluey bouger et réagir, tandis que les plus âgés essaieront de collecter toutes les coquillages et d'éviter les obstacles.
Devon Wolfgang : Nous avons conçu l'application pour soutenir cette gamme de développement. Dans l'expérience LEGO DUPLO 2+, la construction de briques est limitée au 2D. Dans les packs de jeu LEGO 4+, nous introduisons la construction complète en 3D – les enfants peuvent faire pivoter et positionner les briques librement, ajoutant plus de difficulté tout en gardant le plaisir pour tout le monde.

Ryan : La progression est clé. Le mode LEGO DUPLO 2+ utilise un plan 2.5D, tandis que le pack de jeu LEGO 4+ passe à un espace 3D isométrique. Nous voulions que les compétences se développent naturellement. Ce que les enfants apprennent dans le mode plus simple se transpose dans le mode avancé, sans contradictions.
C'était notre première fois à mettre en œuvre la construction de briques 3D complète en utilisant les tests de pénétration basés sur la physique de Unity. Auparavant, nous utilisions une matrice 2D avec des colliders polygonaux. Maintenant, les briques peuvent être tournées, empilées ou même pendre sur les bords. C'est particulièrement important pour les enfants plus âgés.
Un défi majeur était de passer d'un placement fixe des briques à un système flexible. Cela a introduit des interactions complexes comme des minifigs tenant des briques tout en se tenant sur d'autres minifigs, ou des piles dynamiques étant lancées. Cela a donné aux joueurs la liberté, mais nécessitait un contrôle strict des chevilles, des trous et des mécanismes d'enclenchement pour éviter le chaos.

Comment avez-vous géré la communication pour les entrées à travers les groupes d'âge?
Ryan: Nous évitons les instructions directes comme des invites lumineuses ou des conseils complets. Au lieu de cela, nous comptons sur des indices visuels subtils comme des oscillations ou des animations pour inviter à l'interaction. L'objectif est que les enfants découvrent les choses par eux-mêmes.
Par exemple, lorsqu'ils empilent des briques sur une voiture, taper sur une brique fait qu'une minifig la ramasse, et taper sur la voiture la place. Avec le temps, les enfants réalisent qu'ils peuvent faire glisser la brique directement. Cela construit la compréhension par l'expérimentation – et c'est là que la communication visuelle devient essentielle.
Devon: Nous avons également établi une règle stricte : pas de texte. Nos utilisateurs ne savent pas encore lire, donc chaque interaction doit être communiquée visuellement ou par animation. Les indices ne mettent pas en évidence la bonne réponse – ils montrent simplement ce qui est interactif.
Ryan: Et pour rendre l'expérience cohérente, nous avons créé un wrapper d'entrée tactile personnalisé autour des événements de glissement, de tapotement et de clic de Unity. Cela a standardisé la gestion des entrées au sein de l'équipe et a rendu le prototypage plus rapide et plus fiable. Si nous enseignons le tapotement dans une activité, cela doit fonctionner de la même manière partout ailleurs.

Quels défis sont survenus lors de la combinaison des briques système et des briques DUPLO dans la même application ?
Devon: Lesdéfis de conception étaient plus difficiles que les défis techniques. Par exemple, nous avons dû repenser l'écran de chargement car l'utilisation d'un personnage LEGO DUPLO ne s'accordait pas avec les briques système. Maintenir un langage visuel distinct tout en utilisant des systèmes partagés a nécessité beaucoup d'itérations.
Ryan : Nous avons unifié les systèmes LEGO DUPLO et minifig sous la même base de code principale – seules les visuels diffèrent. Cela nous a permis de réutiliser des systèmes sans construire d'applications séparées, ce qui était essentiel pour la durabilité.
Comment Unity vous a-t-il aidé à respecter votre délai de huit semaines ?
Ryan : Les prefabs étaient cruciaux. Pour les briques LEGO DUPLO, chaque développeur travaillait dans des scènes séparées qui se chargeaient à l'exécution. Pour les packs de jeu LEGO 4+, les prefabs ont permis à plusieurs membres de l'équipe de collaborer sur différentes parties, comme des voitures ou des animations, sans conflits de scène.

Comment les Addressables ont-ils été instrumentaux pendant le développement ?
Devon : Nous avons beaucoup compté surles Addressables. Chaque pack de jeu est un groupe de bundles adressables, la plupart étant chargés à distance.
Ryan: Nous avions l'habitude de regrouper tous les actifs par pack de jeu, ce qui signifiait des téléchargements lourds et redondants. Avec les adressables, les actifs partagés comme le modèle Bluey sont stockés une fois et réutilisés, réduisant la taille de téléchargement de 200 Mo à 60 Mo. Les mises à jour sont également plus rapides, car seuls les fichiers modifiés sont redéveloppés.
Devon : Les builds prenaient autrefois huit heures. Maintenant, avec les adressables, cela prend 20 minutes pour la petite application et environ une heure pour la plus grande.

Comment la navigation Unity a-t-elle été utilisée dans ce projet ?
Ryan: L'ancien système de navigation 2D fonctionnait bien, mais le nouveau permet plus de complexité. Maintenant, les minifigs peuvent se déplacer hors des plans plats – comme marcher sur un pont étroit – ce qui ajoute de la profondeur et de la flexibilité.
Quels problèmes de performance avez-vous rencontrés ?
Ryan: Un de nos principaux défis était les appels de dessin. Un changement de shader a cassé le regroupement, nous poussant à plus de 500 appels de dessin. En utilisant le profileur et le débogueur de trames de Unity, nous avons rapidement retracé le problème et corrigé le shader pour regrouper correctement les matériaux. Nous avons également optimisé nos arrière-plans en les marquant comme statiques.
Nous avons également remarqué que des éléments d'arrière-plan comme les buissons n'étaient pas atlasés, ce qui causait des appels de dessin inutiles. En utilisant le système d'atlas de sprites de Unity, nous les avons regroupés sans avoir besoin de Photoshop, et avons réduit les appels de dessin à environ 200.

Quels conseils donneriez-vous à un développeur cherchant à créer des applications pour des enfants d'âges et de stades de développement divers ?
Devon : Testez le jeu tôt et souvent. Faites interagir les enfants de la tranche d'âge cible avec votre travail dès que possible. Ne comptez pas sur des hypothèses, et appréciez leurs réactions – elles sont à la fois précieuses et amusantes.
Ryan: Définissez les livrables tôt. Nous utilisons un système P1/P2/P3 : P1 est essentiel (boucle principale), P2 ajoute du polissage (par exemple, célébrations, animations secondaires), et P3 est un plus (par exemple, comme un poisson qui saute). Cela maintient le focus lorsque des coupes doivent être effectuées.
Une structure de projet claire est tout aussi importante. Pour LEGO DUPLO, nous savons qu'il y a quatre scènes et une scène maîtresse. Pour les packs de jeu LEGO 4+, c'est isométrique dans une zone encadrée. Ces contraintes aident à concentrer la créativité et à éviter l'élargissement du périmètre.
Enfin, la réutilisabilité est essentielle. Avec nos systèmes partagés comme l'entrée tactile et le code unifié pour DUPLO et les briques système, nous réutilisons des actifs et des comportements dans tous les packs de jeu. Cela fait gagner du temps et rend l'expérience utilisateur plus cohérente.
Pour en savoir plus sur les projets réalisés avec Unity, visitez la page des ressources.
