Scritchy Scratchy em Unity: como um único projeto levou o jogo ao PC, mobile e Switch 2

O jogo Scritchy Scratchy foi levado a PC, mobile, Nintendo Switch e Nintendo Switch 2 a partir de um único projeto Unity, sem branches separadas por plataforma. Segundo o Unity Blog, a decisão ajudou a propagar otimizações, correções de bugs e conteúdo novo para todas as versões. Já o maior desafio técnico não foi gráfico: foi manter a sensação tátil de raspar o bilhete quando o jogador usa um controle.

O relato da Unity vem de conversas com integrantes da Lunch Money Games e da Funday Games, que trabalhou nas versões mobile e Switch. O texto cita mais de 1,25 milhão de unidades vendidas no Steam, 250 mil cópias no mobile e 94% de avaliações positivas em mais de 14 mil reviews. O material é de natureza oficial e conta com a visão dos próprios desenvolvedores, portanto os números e as conclusões não passam por verificação independente.

Um projeto só, com o custo assumido

O programador Christian Biskopstø Thomsen explica a lógica: branches de longa duração por plataforma tendem a divergir, e cada correção precisa ser integrada manualmente nas demais. Com quatro ou mais alvos, isso vira trabalho repetitivo.

Há contrapartida, e a equipe a reconhece: um projeto único exige compilação condicional e checagens específicas de plataforma espalhadas pelo código. Para o tamanho e a complexidade de Scritchy Scratchy, o nível de ramificação ficou administrável. Isso é um ponto importante para quem avalia a abordagem, pois a conclusão vale para o escopo de um jogo relativamente enxuto, não necessariamente para projetos maiores.

Os entrevistados citam ainda um benefício operacional: um desenvolvedor que corrigia bugs de PC pôde passar para problemas do mobile sem aprender uma base de código separada.

O scratch no gamepad deu mais trabalho que o toque

O jogo foi desenhado em torno de mouse e toque. No toque, a mecânica funcionou quase de imediato. No controle, não bastava mapear um cursor um para um. A equipe fez um workshop com quatro pessoas, desmontou a interação da versão PC e a refez como um wireframe para as outras plataformas. Houve várias iterações até chegar a algo satisfatório.

Um dos ajustes citados é o direcionamento automático do input para a área relevante quando o jogador abre um bilhete e começa a raspar. No Nintendo Switch 2, a equipe também quis aproveitar a funcionalidade de mouse do console.

A arquitetura de input ajudou. Segundo Hannibal Sigfusson, o projeto tinha desde o início uma camada entre o Input System e o restante do código, de modo que a lógica do jogo só precisa saber se o ponteiro foi ativado, onde ele está e qual sua posição no mundo. Thomsen acrescenta que o toque funcionou quase sem esforço com o Input System e que é possível testar o controle no Editor no PC antes de gerar o build para Switch, com os mapeamentos mantidos.

Profiler antes de otimizar: partículas no mobile

O fluxo descrito é profilar primeiro, identificar o que realmente está lento e só então corrigir. O principal exemplo foram as partículas geradas ao raspar: o jogo lê informações da textura para criar partículas com a cor da área raspada. Isso funcionava bem no PC, mas a abordagem original pesava demais no mobile. A solução foi usar GPU instancing, que a equipe considera uma das otimizações mais importantes do port.

O alvo era algo próximo de 60 fps, porque o jogo perde a graça se a raspagem travar. A Funday Games definiu níveis mínimos de sistema operacional e de API no mobile e testou aparelhos próximos desse limite, incluindo iPhone X e iPhone XS no iOS, com filosofia semelhante no Android. Depois do ajuste das partículas, a equipe diz não ter visto problemas relevantes de taxa de quadros nesses dispositivos.

Háptico, resolução e etapas específicas de loja

No mobile, foi adicionado feedback háptico durante a raspagem. O comportamento varia muito entre aparelhos, sobretudo no Android, e houve relatos de celulares vibrando forte demais, o que exigiu novas iterações.

A resolução também pesou. O jogo foi concebido para tela widescreen de PC; a maioria das resoluções de celular em paisagem se adaptou com facilidade, mas a proporção do iPad foi mais difícil. A solução envolveu ajustar a apresentação e usar zoom para o layout se encaixar de forma natural. Já a parte específica de plataforma incluiu builds para App Store e Google Play, certificados, SDKs e cloud saves.

O conselho para quem pretende portar

A recomendação dos desenvolvedores é decidir cedo em quais plataformas o jogo pode aparecer. Constantin Lervig admite que a escolha inicial de não priorizar o gamepad gerou trabalho adicional depois. Sigfusson reforça que input, resolução, proporções de tela e a sensação em cada dispositivo são difíceis de acrescentar tarde.

O que a fonte não informa

O texto não detalha requisitos de hardware por plataforma, nem diferenças de desempenho entre Switch e Switch 2. Também não traz tamanho da equipe, tempo gasto em cada etapa, receita por plataforma ou plugins além do Unity Profiler e do Input System. Esses dados seriam úteis para medir o custo real de um lançamento multiplataforma.

Para quem desenvolve em Unity, o caso funciona como checklist prático: planejar input desde o início, medir antes de otimizar e aceitar a complexidade de um projeto único quando o escopo permite. Para continuar explorando o tema, vale navegar pelos conteúdos de engines e desenvolvimento da Rplay Games.