Digitales Spielen nach Alter anpassen: Wie StoryToys die LEGO® Bluey App entwickelt hat

StoryToys wurde 2008 mit der Mission gegründet, Bildungs-Apps für Kinder jeden Alters bereitzustellen. In den letzten 17 Jahren hat das Unternehmen Apps veröffentlicht, darunter Hungry Caterpillar Play School, LEGO® DUPLO® World, Disney Coloring World und LEGO® DUPLO® Peppa.

Ihr aktuellster Titel, LEGO® Bluey, wurde am 14. August 2025 veröffentlicht. Es wurde in Zusammenarbeit mit der LEGO Group und BBC Studios entwickelt und richtet sich an Kinder im Alter von zwei bis vier Jahren und verbindet Spaß mit frühem Lernen.

Wir sprachen mit Devon Wolfgang, dem leitenden Techniker bei StoryToys, und Ryan Dykes, dem leitenden Entwickler der App, über die Schwierigkeiten und Meilensteine bei der Entwicklung einer App für Kinder unterschiedlichen Alters und unterschiedlichen Niveaus der motorischen Fähigkeiten, emotionalen Intelligenz, Problemlösung und des Humors.

Was war die größte technische Herausforderung bei der Entwicklung der App?

Ryan Dykes: Das Design für Zwei- und Vierjährige war eine einzigartige Herausforderung. Kinder, die jung sind, beschäftigen sich sehr unterschiedlich mit Apps – Zweijährige erkunden oft durch Antippen, ohne die Mechanik vollständig zu verstehen, während Vierjährige darauf abzielen, sie zu beherrschen.

Beim Surfen können beispielsweise jüngere Spieler darauf tippen, wie sich Bluey bewegt und reagiert, während ältere versuchen, alle Muscheln einzusammeln und Hindernissen auszuweichen.

Devon Wolfgang: Wir haben die App so konzipiert, dass sie diese Entwicklungspalette unterstützt. In der LEGO DUPLO-Erfahrung mit mehr als 2D ist das Ziegelbauen auf 2D beschränkt. In den über 4 LEGO-Spielepaketen führen wir ein komplettes 3D-Building ein – Kinder können Steine frei drehen und positionieren, was den Schwierigkeitsgrad erhöht und gleichzeitig allen Spaß macht.

Ryan: Der Fortschritt ist entscheidend. Der 2+ LEGO DUPLO-Modus nutzt eine 2,5D-Ebene, während sich das 4+ LEGO-Spielpaket in einen isometrischen 3D-Raum bewegt. Wir wollten, dass Fähigkeiten natürlich aufgebaut werden. Was Kinder im einfacheren Modus lernen, wird ohne Widersprüche in den fortgeschrittenen Modus übertragen.

Dies war unsere erste Implementierung eines kompletten 3D Brick Building mit dem Physics-basierten Penetrationstest von Unity. Früher haben wir eine 2D Matrix mit Polygon Collidern verwendet. Jetzt können Steine gedreht, gestapelt oder sogar von Kanten herabgehängt werden. Dies ist besonders für ältere Kinder wichtig.

Eine große Herausforderung war die Umstellung von der festen Ziegelplatzierung auf ein flexibles System. Dadurch wurden komplexe Interaktionen eingeführt, wie z. B. Minifeigen, die Steine halten, während sie auf anderen Minifeigen stehen, oder dynamische Stacks, die herumgeworfen werden. Es gab den Spielern Freiheit, erforderte aber eine genaue Kontrolle von Heringen, Löchern und Schnappmechaniken, um Chaos zu vermeiden.

Wie haben Sie die Kommunikation für den Input über alle Altersgruppen hinweg gehandhabt?

Ryan: Wir vermeiden direkte Anweisungen wie glühende Eingabeaufforderungen oder vollständige Anleitungen. Stattdessen laden subtile visuelle Hinweise wie Wobbeln oder Animationen zur Interaktion ein. Das Ziel ist es, dass Kinder Dinge selbst entdecken.

Wenn Sie beispielsweise Steine auf ein Auto stapeln, hebt ein Minifig durch Tippen auf einen Stein diesen auf, und das Tippen auf das Auto platziert ihn. Mit der Zeit merken die Kinder, dass sie den Stein direkt ziehen können. Das schafft Verständnis durch Experimentieren – und da wird visuelle Kommunikation unerlässlich.

Devon: Wir haben auch eine feste Regel aufgestellt: kein Text. Unsere Benutzer können noch nicht lesen, daher muss jede Interaktion visuell oder durch Animation kommuniziert werden. Hinweise heben nicht die richtige Antwort hervor – sie zeigen nur, was interaktiv ist.

Ryan: Und um das Erlebnis konsistent zu gestalten, haben wir einen benutzerdefinierten Touch-Eingabe-Wrapper für die Drag-, Tipp- und Klick-Ereignisse von Unity erstellt. Diese standardisierte Eingabeverarbeitung im gesamten Team und machte das Prototyping schneller und zuverlässiger. Wenn wir das Anzapfen in einer Aktivität lehren, muss das überall genauso funktionieren.

Welche Herausforderungen traten bei der Kombination von System- und DUPLO-Steinen in derselben App auf?

Devon: Die gestalterischen Herausforderungen waren schwieriger als die technischen. Wir mussten beispielsweise den Ladebildschirm neu gestalten, weil die Verwendung eines LEGO DUPLO-Charakters nicht zu den Systembausteinen passte. Die Unterscheidung der visuellen Sprache bei der Verwendung gemeinsam genutzter Systeme erforderte viel Iteration.

Ryan: Wir haben LEGO DUPLO und Minifeigensysteme unter derselben Kerncodebasis vereint – nur die Grafik unterscheidet sich. Dadurch konnten wir Systeme wiederverwenden, ohne separate Apps zu erstellen, was für die Nachhaltigkeit von entscheidender Bedeutung war.

Wie hat Unity Ihnen geholfen, Ihr Zeitfenster von acht Wochen einzuhalten?

Ryan: Prefabs waren entscheidend. Für LEGO DUPLO-Steine arbeitete jeder Entwickler in separaten Szenen, die zur Laufzeit geladen wurden. Für die über 4 LEGO-Spielepakete ermöglichen Prefabs es mehreren Teammitgliedern, an verschiedenen Teilen wie Autos oder Animationen ohne Szenenkonflikte zusammenzuarbeiten.

Wie waren Addressables während der Entwicklung instrumentell?

Devon: Wir haben uns stark auf Addressables verlassen. Jedes Play-Paket besteht aus einer Gruppe Addressable Bundles, von denen die meisten remote geladen werden.

Ryan: Wir haben bisher alle Assets pro Spielpaket gebündelt, was große, redundante Downloads bedeutete. Mit Addressables werden freigegebene Assets wie das Bluey-Modell einmal gespeichert und wiederverwendet, wodurch die Downloadgröße von 200 MB auf 60 MB reduziert wird. Updates sind auch schneller, da nur geänderte Dateien erneut heruntergeladen werden.

Devon: Builds dauerten früher acht Stunden. Mit Addressables dauert es jetzt für die kleinere App bis zu 20 Minuten und für die größere etwa eine Stunde.

Wie wurde Unity Navigation in diesem Projekt verwendet?

Ryan: Das alte 2D Navigationssystem hat gut funktioniert, aber das neue ermöglicht mehr Komplexität. Jetzt können sich Minifeigen von flachen Ebenen wegbewegen – wie auf einer schmalen Brücke –, was Tiefe und Flexibilität erhöht.

Auf welche leistungsbezogenen Probleme sind Sie gestoßen?

Ryan: Eine unserer größten Herausforderungen waren Draw Calls. Eine Shader-Änderung hat das Batching zum Scheitern gebracht und uns über 500 Draw Calls gebracht. Mithilfe von Unity Profiler und Frame Debugger konnten wir das Problem schnell zurückverfolgen und den Shader auf ordnungsgemäß stapelbare Materialien beheben. Wir haben auch unsere Hintergründe optimiert, indem wir sie statisch markiert haben.

Wir bemerkten auch, dass Hintergrundelemente wie Bushes nicht atlasiert wurden, was zu unnötigen Draw Calls führte. Mithilfe des Sprite Atlas-Systems von Unity haben wir sie ohne Photoshop gruppiert und die Draw Calls auf etwa 200 reduziert.

Was raten Sie einem Entwickler, der Apps für Kinder unterschiedlichen Alters und unterschiedlicher Entwicklungsstufen entwickeln möchte?

Devon: Spielen Sie früh und oft. Bringen Sie Kinder im Zielalter so schnell wie möglich zur Interaktion mit Ihrer Arbeit. Verlassen Sie sich nicht auf Annahmen und genießen Sie ihre Reaktionen – sie sind wertvoll und machen Spaß.

Ryan: Legen Sie Leistungen frühzeitig fest. Wir verwenden ein P1/P2/P3-System: P1 ist unerlässlich (Core Loop), P2 fügt Glanz hinzu (z. B. Feiern, sekundäre Animationen) und P3 ist angenehm (z. B. wie ein Fischspringen). Dies behält den Fokus, wenn Einschnitte erforderlich sind.

Genauso wichtig ist eine klare Projektstruktur. Für LEGO DUPLO sind es vier Szenen und eine Meisterszene. Für die über 4 LEGO-Spielepakete ist es isometrisch in einem verpackten Bereich. Diese Beschränkungen helfen, die Kreativität zu fokussieren und Kriechen des Umfangs zu vermeiden.

Schließlich ist Wiederverwendbarkeit der Schlüssel. Mit unseren geteilten Systemen wie Touch-Eingabe und vereinheitlichtem Code für DUPLO und Systembausteine verwenden wir Assets und Verhaltensweisen in allen Spielpaketen wieder. Das spart Zeit und macht die Benutzererfahrung konsistenter.

Weitere Informationen zu Projekten Made with Unity finden Sie auf der Seite Ressourcen.