Ajuste da jogabilidade digital por idade: Como a StoryToys desenvolveu o aplicativo LEGO® Bluey

StoryToys foi fundada em 2008 com a missão de trazer aplicativos educacionais para crianças de todas as idades. Durante os últimos 17 anos, eles lançaram aplicativos, incluindo Hungry Caterpillar Play School, LEGO® DUPLO® World, Disney Coloring World e LEGO® DUPLO® Peppa.

Seu título mais recente, LEGO® Bluey, foi lançado em 14 de agosto de 2025. Desenvolvido em colaboração com o Grupo LEGO e o BBC Studios, visa crianças de dois a quatro anos e combina diversão com aprendizado antecipado.

Falei com Devon Wolfgang, engenheiro chefe na StoryToys, e Ryan Dykes, desenvolvedor chefe do aplicativo, sobre as dificuldades e marcos da projetar um aplicativo para crianças de diferentes idades e níveis de habilidades motoras, inteligência emocional, resolução de problemas e humor.

Qual foi o maior desafio técnico ao desenvolver o aplicativo?

Ryan Dykes: O design para crianças de dois e quatro anos foi um desafio único. Crianças pequenas se envolvem de maneira muito diferente com aplicativos: crianças de dois anos geralmente exploram por meio de toque sem entender totalmente a mecânica, enquanto crianças de quatro anos buscam dominá-los.

Por exemplo, na atividade de surf, os jogadores mais jovens podem clicar para ver o Bluey se mover e reagir, enquanto os mais antigos tentarão coletar todas as camadas e evitar obstáculos.

Devon Wolfgang: Nós projetamos o aplicativo para oferecer suporte a essa gama de desenvolvimento. Na experiência 2+ LEGO DUPLO, a criação de tijolos é limitada a 2D. Nos mais de 4 pacotes de jogos de LEGO, apresentamos a criação 3D completa – as crianças podem girar e posicionar os blocos livremente, adicionando mais dificuldade enquanto mantém a diversão para todos.

Ryan: A progressão é importante. O modo LEGO DUPLO 2+ usa um avião 2.5D, enquanto o LEGO Play Pack 4+ se move para um espaço 3D isométrico. Queríamos desenvolver habilidades naturalmente. O que as crianças aprendem no modo mais simples leva para o avançado, sem contradições.

Esta foi a nossa primeira vez em implementar a criação completa de tijolos 3D usando os testes de penetração baseados em física do Unity. Antes, usávamos uma matriz 2D com colliders de polígonos. Agora, os blocos podem ser girados, empilhados ou até mesmo pendurados. Isso é especialmente importante para crianças maiores.

Um grande desafio foi mudar do posicionamento fixo de tijolos para um sistema flexível. Isso introduziu interações complexas, como minifigs segurando tijolos enquanto estavam em outros minifigs, ou pilhas dinâmicas sendo jogadas ao redor. Forneceu liberdade aos jogadores, mas exigiu controle rigoroso de pinos, buracos e mecânica de recorte para evitar o caos.

Como você lidou com a comunicação para informações entre grupos de idade?

Ryan: Nós evitamos instruções diretas, como prompts brilhantes ou orientação completa. Em vez disso, contamos com dicas visuais sutis, como vibrações ou animações, para convidar a interação. O objetivo é que as crianças descubram as coisas por conta própria.

Por exemplo, ao empilar tijolos em um carro, apertar um tijolo faz com que uma minifig a pegue e apertar o carro a coloca. Com o tempo, as crianças percebem que podem arrastar o tijolo diretamente. Isso cria compreensão por meio da experimentação, e é aí que a comunicação visual se torna essencial.

Devon: Tivemos também uma regra firme: sem texto. Nossos usuários ainda não conseguem ler, então toda interação precisa ser comunicada visualmente ou por meio de animação. As instruções não destacam a resposta correta, elas apenas mostram o que é interativo.

Ryan: E para tornar a experiência consistente, nós criamos uma envoltura de entrada de toque personalizada em torno dos eventos de arrastar, tocar e clicar do Unity. Isso padronizou o tratamento de entradas em toda a equipe e tornou a prototipagem mais rápida e confiável. Se ensinarmos a explorar em uma atividade, ela precisa funcionar do mesmo jeito em qualquer outra.

Quais foram os desafios da combinação de peças do sistema e peças DUPLO no mesmo aplicativo?

Devon: Os desafios de design foram mais difíceis do que os técnicos. Por exemplo, tivemos que reformular a tela de carregamento pois o uso de um personagem de LEGO DUPLO não se encaixava nos elementos do sistema. Manter a linguagem visual diferente enquanto usa sistemas compartilhados exigia muita iteração.

Ryan: Unificamos os sistemas LEGO DUPLO e minifig sob a mesma base de código principal — somente os visuais diferem. Isso nos permitiu reutilizar sistemas sem desenvolver aplicativos separados, o que era essencial para a sustentabilidade.

Como o Unity ajudou você a alcançar sua janela de oito semanas?

Ryan: Os Prefabs foram cruciais. Para peças do LEGO DUPLO, cada desenvolvedor trabalhou em cenas separadas que carregavam no tempo de execução. Para os 4 ou mais pacotes de jogo da LEGO, os prefabs permitem que vários membros da equipe colaborem em diferentes partes, como carros ou animações, sem conflitos de cena.

Como os Addressables foram fundamentais durante o desenvolvimento?

Devon: Contamos muito com os Addressables. Cada pacote de jogo é um grupo de pacotes Addressables, com a maioria carregada remotamente.

Ryan: Costumávamos agrupar todos os assets por play pack, o que significava downloads grandes e redundantes. Com o Addressables, assets compartilhados, como o modelo Bluey, são armazenados uma vez e reutilizados, reduzindo o tamanho de download de 200 MB para 60 MB. As atualizações também são mais rápidas, já que somente arquivos alterados são novamente baixados.

Devon: As builds costumavam levar oito horas. Agora, com o Addressables, isso leva até 20 minutos para o aplicativo menor e cerca de uma hora para o maior.

Como o Unity Navigation foi usado neste projeto?

Ryan: O antigo sistema de navegação 2D funcionou bem, mas o novo permite mais complexidade. Agora, minifigs podem sair dos planos planos, como subir em uma ponte estreita, o que adiciona profundidade e flexibilidade.

Quais problemas relacionados ao desempenho você teve?

Ryan: Um dos nossos principais desafios foi draw calls. Uma alteração no shader quebrou o batching, resultando em mais de 500 draw calls. Usando o Profiler e o Frame Debugger do Unity, rastreamos rapidamente o problema e corrigimos o shader para batching adequado dos materiais. Também otimizamos nossos fundos marcando-os estáticos.

Também notamos elementos de fundo, como arbustos, não eram adequados, causando draw calls desnecessários. Usando o sistema de sprite atlas do Unity, agrupamos eles sem a necessidade de Photoshop e reduzimos draw calls para cerca de 200.

Que conselho você daria a um desenvolvedor que queira criar aplicativos para crianças de diversas idades e estágios de desenvolvimento?

Devon: Teste a jogabilidade cedo e com frequência. Faça com que crianças da faixa etária de destino interajam com o seu trabalho o quanto antes. Não confie em pressupostos e aproveite suas reações: elas são valiosas e divertidas.

Ryan: Defina os deliverables com antecedência. Usamos um sistema P1/P2/P3: P1 é essencial (laço central), P2 adiciona refinamento (por exemplo, celebrações, animações secundárias) e P3 é agradável (por exemplo, como um peixe saltando). Isso mantém o foco quando as cortes precisam acontecer.

Estrutura clara do projeto também é importante. Para o LEGO DUPLO, sabemos que são quatro cenas e uma cena principal. Para os mais de 4 pacotes de jogos da LEGO, é isométrico em uma área em uma caixa. Essas restrições ajudam a concentrar a criatividade e evitar medo de escopo.

Por fim, a reutilização é essencial. Com nossos sistemas compartilhados, como entrada de toque e código unificado para DUPLO e chips do sistema, reutilizamos assets e comportamentos em todos os pacotes de jogo. Isso economiza tempo e torna a experiência do usuário mais consistente.

Para ler mais sobre projetos Made with Unity, acesse a página Recursos.