Expandindo o Scritchy Scratchy para diversas plataformas

Trazer o Scritchy Scratchy para PC e dispositivos móveis, enquanto o preparávamos para o Nintendo Switch™ 2 e o Nintendo Switch, significou adaptar a interação tátil a dispositivos muito diferentes.

Para garantir a mesma capacidade de resposta com um controle, a equipe precisou repensar a entrada de dados, o comportamento da interface do usuário, a resposta tátil e como o jogo se adapta a diferentes tamanhos de tela e proporções.

O processo de portabilidade também envolveu o equilíbrio entre desempenho e facilidade de manutenção. Em vez de criar ramificações separadas para cada plataforma, a equipe manteve o jogo em um único projeto Unity , para que otimizações, correções de bugs e novos conteúdos pudessem ser implementados em todas as plataformas.

Desde o lançamento, o jogo vendeu mais de 1,25 milhão de unidades no Steam e 250.000 cópias para dispositivos móveis , além de ter alcançado uma classificação positiva de 94% no Steam, com base em mais de 14.000 avaliações .

Conversamos com Constantin Lervig, diretor criativo da Lunch Money Games; Hannibal Sigfusson, CEO da Lunch Money Games; Christian Biskopstø Thomsen, programador que trabalha com a Funday Games nas versões para dispositivos móveis e Nintendo Switch; e Emil Kjæhr, chefe de produto e parcerias da Funday Games, sobre os maiores desafios de adaptação de Scritchy Scratchy .

*Nintendo Switch é uma marca registrada da Nintendo.

Quais foram os maiores desafios técnicos que você enfrentou durante a portabilidade?

CBT: Os maiores desafios para dispositivos móveis foram as partes específicas de cada plataforma: fazer com que as compilações funcionassem corretamente na App Store e no Google Play, lidar com certificados, integrar SDKs da plataforma e gerenciar sistemas como o salvamento na nuvem.

A entrada de dados tornou-se um dos maiores desafios, pois projetamos o jogo em torno do mouse e da tela sensível ao toque. Precisávamos decidir como o recurso de arranhar deveria funcionar com um gamepad. Isso envolveu discussões sobre o design e várias iterações até chegarmos a algo que nos parecesse certo.

Emil Kjæhr: Mapeamos como a interação deve funcionar, incluindo o ajuste automático da entrada na área relevante quando você abre um tíquete e começa a raspar.

Especificamente para o Nintendo Switch 2, também queríamos oferecer suporte à funcionalidade de mouse.

Na versão para dispositivos móveis, adicionamos feedback tátil ao arranhar. A resposta tátil comporta-se de maneira diferente em uma ampla gama de dispositivos, particularmente no Android. Tivemos casos em que os usuários relataram que seus telefones estavam vibrando com muita intensidade, então isso exigiu algumas iterações.

Houve desafios específicos para tornar as interações principais mais táteis em todas as plataformas?

CBT: O gamepad foi, sem dúvida, a interação mais desafiadora de traduzir. Com o toque, o mecanismo de arranhão funcionou muito bem quase que imediatamente. Com um controlador, tivemos que repensar como essa mesma ação deveria ser sentida, em vez de simplesmente mapear um cursor diretamente para um.

EK: Nós quatro nos reunimos para uma oficina e analisamos diretamente a versão para PC . Basicamente, desmontamos a interação e a reconstruímos como um wireframe para as outras plataformas.

Depois disso, a abordagem intuitiva ficou bastante clara. Isso também demonstra o quão minuciosamente analisamos o projeto original sob uma perspectiva multiplataforma. Isso nos poupou muito tempo quando lançamos o jogo para dispositivos móveis e, posteriormente, começamos a adaptar a interação para controles.

Qual estratégia de portabilidade você utilizou: uma única versão adaptada para cada plataforma ou branches separadas específicas para cada plataforma? Por que?

CBT: Optamos por um único projeto Unity e código-fonte, em vez de manter ramificações separadas e de longa duração para cada plataforma.

As ramificações separadas da plataforma tendem a se distanciar. Você corrige um problema em uma ramificação e depois precisa integrá-lo às outras. Quando você precisa dar suporte a quatro ou mais alvos, isso se torna tedioso muito rapidamente.

Um projeto único tem suas desvantagens, pois você acaba com compilação condicional e verificações específicas da plataforma em todo o código. Mas, considerando o tamanho e a complexidade de Scritchy Scratchy , mantivemos o jogo em um nível gerenciável.

CL: Outra grande vantagem de um projeto único é que cada pequena otimização e correção de bugs se aplica a todas as versões.

Como o Unity Profiler ajudou você a encontrar e corrigir gargalos específicos da plataforma?

CBT: Utilizei bastante o Unity Profiler enquanto trabalhava na otimização de desempenho. Meu fluxo de trabalho é basicamente: primeiro, crio um perfil, vejo o que realmente está lento e, em seguida, corrijo isso em vez de ficar tentando adivinhar.

O maior exemplo disso foram as partículas riscadas. Ao raspar um bilhete, coletamos informações da textura e geramos partículas que correspondem à cor do que você está raspando. Isso funcionou muito bem no PC, mas a abordagem original era muito pesada para dispositivos móveis.

A solução foi usar instanciamento de GPU para essas partículas. Após essa alteração, ela se tornou uma das otimizações de desempenho mais importantes do porto.

De que forma o Input System ajudou você a dar suporte a diferentes esquemas de controle?

CBT: O fato de o recurso de toque funcionar praticamente sem qualquer problema com o Input System foi extremamente útil e economizou muito tempo.

Posso conectar um controle ao meu PC, jogar e testar os controles diretamente no Editor e, em seguida, compilar o jogo para Nintendo Switch. Os mapeamentos do controlador são mantidos no Input System, o que torna a iteração muito mais rápida.

HS: Desde o início do projeto, criamos uma camada entre o Input System e o restante do nosso código. O código do jogo não precisa se preocupar diretamente com todos os tipos de entrada de hardware. Essa camada pode ser usada para determinar se a entrada ativou o ponteiro, onde o ponteiro está ou qual é a sua posição no mundo real.

Quais metas de desempenho você definiu para cada plataforma e quão perto você chegou delas?

EK: Estabelecemos os níveis mínimos OS e API suportados em dispositivos móveis e, em seguida, realizamos testes em dispositivos próximos ao limite inferior dessa faixa.

Após implementarmos a correção de instanciação de GPU para o sistema de partículas, não observamos mais problemas significativos de taxa de quadros nesses dispositivos.

No iOS, testamos especificamente dispositivos como o iPhone X e o iPhone XS para garantir que o jogo funcionasse bem no hardware que queríamos oferecer suporte. Seguimos a mesma filosofia no Android.

CL: Scratchy Scratchy precisa ter uma sensação suave, porque arranhar deixa de ser satisfatório imediatamente se o jogo estiver travando.

A exigência era que a sensação fosse a mesma de raspar um adesivo físico com o dedo. Na prática, isso significava buscar a fluidez que se obtém em torno de 60 fps.

CBT: A resolução foi outro desafio. Desenvolvemos o jogo original para um monitor de PC widescreen. A maioria das resoluções de tela de celulares na horizontal foram adaptadas de forma bastante natural, mas a proporção da tela do iPad foi mais difícil.

Tivemos tempo suficiente antes do lançamento para fazer com que a versão para iPad também funcionasse. Isso envolveu ajustar a apresentação e usar o zoom para que o layout se encaixasse naturalmente.

O objetivo era que, independentemente de alguém ter tido o primeiro contato com o Scritchy Scratchy em um PC, um telefone ou um iPad, a experiência fosse natural, como se o jogo pertencesse àquele dispositivo, e não como uma adaptação comprometida.

Quais decisões de implementação tiveram o maior impacto na qualidade da entrega em todas as plataformas?

EK: A decisão mais importante em relação à implementação foi manter tudo em um único projeto.

Isso é importante não apenas para a primeira porta, mas também para a manutenção posterior. Quando falamos sobre novos conteúdos que chegam ao jogo, não preciso me preocupar com quanto tempo levará para distribuir esse conteúdo por meio de várias plataformas independentes.

CL: Isso também facilitou a movimentação de pessoas entre tarefas. Tínhamos um desenvolvedor que nos ajudava a corrigir bugs na versão para PC e que, em seguida, podia passar diretamente a corrigir problemas na versão mobile, sem precisar aprender um código-fonte específico para dispositivos móveis.

Qual é a sua principal dica para desenvolvedores que planejam portar um jogo para várias plataformas?

CL: Do ponto de vista do design, defina desde o início em quais plataformas o jogo poderá ser lançado. Optamos desde o início por não nos concentrarmos muito no gamepad, e mais tarde percebemos como isso gerou trabalho adicional.

HS: Pense desde o início em relação aos parâmetros de entrada, resolução, proporções de tela e como o jogo deve ser percebido em diferentes plataformas. Essas coisas são muito mais difíceis de adicionar posteriormente.

Arranhando Arranhando Está disponível no Steam , na App Store e no Google Play . Confira mais histórias de desenvolvedores da Unity no Blog da Unity e na Central de Recursos .