Por que você deve se preocupar em otimizar a UI de jogos mobile?
Lições que aprendi trabalhando com desenvolvimento de jogos.
--
🇬🇧 Read this article in English (EN-US).
Por mais inofensivo que o .png do nosso componente pareça, quando somado aos diversos arquivos de UI, ele vai impactar o tamanho final do jogo. Dos últimos anos trabalhando com mobile game, aprendi que esse número influência muito nas métricas de downloads. Isso se ocorre porque quando o aplicativo ultrapassa o tamanho de 200MB, a AppStore e a Google Play sugere ao usuário que ele faça download utilizando a Wi-fi, pois pode haver consumo excessivo de dados. Pode parecer que não, mas um simples popup que sugere que você ligue a Wi-Fi pode gerar desistências no momento de download.
E por mais que 200MB pareça uma margem super saudável, jogos são operados como serviços hoje em dia, e isso implica em produção continua de conteúdo, o que significa que ele vai ficar mais pesado a cada release. Então, para amenizar os problemas que podem surgir lá na frente, adotar práticas de otimização desde o início podem te livrar de dores de cabeça.
Um grande exemplo para validar essa informação e tangibilizar a importancia dessa estratégia no mercado mobile está no famigerado Free Fire. Em uma entrevista publicada pela GamesIndustry, Harold Teo, producer na Garena citou:
“Se o nosso jogo for de 4 GB, 8 GB ou algo assim, as pessoas terão que pensar duas vezes antes de instalar. Elas precisam excluir alguns aplicativos do telefone e, às vezes, até a capacidade total do telefone pode não ser suficiente. Ainda hoje, uma das prioridades da equipe é tornar o aplicativo o mais leve possível.”
São diversas as características que podem influenciar o seu jogo. O tamanho da build final, o tamanho e resolução dos assets, a quantidade de arquivos repetidos sem uso e várias outras sitações como estas precisam do seu carinho.
Ferramentas e técnicas para otimizar sua UI
Sabendo disso, preparei um grande compilado de técnicas para otimização que considero relevante e podem beneficiar jogos produzidos em diferentes game engines. No entanto, sendo específico, foracarei nas ferramentas as quais tive mais experiência: Unity e Figma.
Antes de começar, por mais que as sugestões deste artigo resultem da soma de conversas com Graphic Engineers, Diretores de Arte, Engenheiros e Game Devs em geral, peço que não trate como regra. Cada jogo se encontra em um contexto com variáveis completamente diferentes, portanto sempre converse com seu time antes de tomar qualquer decisão que pode impactar o pipeline.
Então, realmente preciso pensar em otimização?
Para contextualizar, um número reduzido de cenários mais comuns que me deparei são:
- A UI fica muito mais bonita e consistente no Figma do que a implementada no jogo.
- A resolução dos assets está inferior ao planejado.
- Os arquivos de UI ficam desorganizados na estrutura do projeto.
- A manutenção se torna um trabalho extremamente complexo com o passar do tempo e a integração de novos componentes prejudicam o tamanho da build.
Ao transitar entre diferentes jogos e times, notei que muitos padrões se repetiam e talvez você também se identifique com isso. Através desses padrões é possível enxergar algumas saídas para melhorar tanto a vida do Designer quanto a dos Engenheiros. É importante falar que não existe formula mágica, mas um conjunto de soluções elaboradas em conjunto com o time e stakeholders através da maturação do jogo e da comunicação ativa.
Entendendo as soluções
Diante de todos os processos, não tenho a intenção de ranquear do mais importante ao menos importante. Acredito que todos contribuem para o resultado de uma maneira diferente. Pode ser que alguns façam sentido para você e outros não, faça uma análise para decidir o que vale o esforço. São eles:
- 9-Slicing
- Tint
- Tamanho, resolução e compressão
- Sprite Atlas
- Taxonomia
- Color space & Rendering pipeline
- Design review
9-slicing
Por muito tempo trabalhei com essa técnica, mas através de outros nomes. É algo bem difundido desde os primórdios da internet, onde o maior uso estava em criar divs personalizadas redimensionáveis que tinham os quatro cantos com border radius ou outro tipo de ornamento.
Esse conceito nada mais é que uma técnica 2D que permite reutilizar uma imagem em vários tamanhos sem a necessidade de preparar vários assets. Você divide sua imagem em 9 slices, onde determina que os cantos sejam fixos e o miolo seja redimensionável.
Felizmente, a Unity oferece um package que faz com que essa prática seja trivial: o Sprite Editor! Não vou entrar em detalhes de como executar, pois existe muito material de qualidade na internet. Segue um exemplo, caso queira conferir:
No entanto, mesmo sendo trivial, o 9-slicing pode ser super impactante quando incorporado no workflow. Imagine a situação em que você precisaria exportar cerca de 6 assets diferentes para produzir algo legal, mas agora é possível ter o mesmo resultado com apenas 1.
Além de ser uma excelente prática de desenvolvimento, depois que você aprende como funciona vira uma requisito técnico para os seus assets de Design e uma nova forma de pensar. Entender este conceito é um dos primeiros passos para trabalhar com UI em games.
Tint
Assim como o 9-slicing, esta técnica também é revolucionária quando o assunto é reutilização e escalibidade de assets. E por incrível que pareça é muito fácil de entender, aplicar e ver o resultado.
Imagine o HUD — heads-up display, ou tela utilizada para detalhar as principais informações e acontecimentos durante uma partida — de um jogo de batalha aérea como o Sky Warriors, onde existem diversos ícones semelhantes que são exibidos em cores diferentes a depender do time escolhido.
Nesse cenário, caso exista dez ícones diferentes que precisam aparecer em três cores, teríamos no total 30 arquivos. No entanto, usando o tint, vamos exportar somente 10, porém em cor branca, daí aplicaremos o tint dentro da Unity com a cor necessária através do inspetor ou via código.
Quando aplicado, além de facilitar muito a manutenção para todos do time, o tint pode reduzir drasticamente a quantidade de arquivos de UI no projeto em longo prazo.
Tamanho, resolução e compressão
Este tópico, em particular, foi o que me motivou a escrever este artigo e a começar iniciativas de melhoria de pipeline com meu time. Além dele afetar diretamente o tamanho da build final, como disse na introdução, ele tem papel fundamental para sinergia das outras otimizações.
Por exemplo: para que a Unity comprima bem o seu arquivo, e consequentemente diminuía o tamanho dele através de um algoritmo, a resolução precisa estar em potência de 2 (16, 32, 64, 128…). A priori, parece ser uma regra que não afeta a sua rotina de trabalho, mas acredite em mim, chegará o momento em que esse detalhe irá exigir sua atenção com tanta frequência que você vai se perguntar o que pode ser feito para otimizar o processo.
Isso foi exatamente o que aconteceu comigo. Por mais que eu valorize a importância de usar a potência de 2, se tornou inviável sempre revisar e exportar assets com uma região considerável em transparente somente para bater a resolução certa. Daí, em conversa com diversas pessoas, percebemos algo que poderia amenizar o problema, cuja técnica aprofundarei melhor a seguir.
No entanto, apesar de ter outras alternativas para resolver este problema, trabalhar com grid de 8 pontos no seu Design já é um grande passo para evoluir nesta direção.
Sprite Atlas
Ah, o maravilhoso Sprite Atlas! Porque me preocupar individualmente com tantos assets se eu posso empilhar todos eles de forma automatizada em um big asset com resolução na potência de 2 e resolver todos meus problemas?
Antes de seguir, permita-me ressaltar: a preocupação individual com os assets ainda é necessária, mas de uma forma muito mais saudável.
O Sprite Atlas, é uma excelente prática de desenvolvimento porque além de aliviar o micro-gerenciamento e organizar o projeto ele também diminui de forma assustadora a quantidade de draw calls (nome do processo responsável por renderizar os assets na sua tela), o que por sua vez melhora a performance.
Em outras palavras, se sua Main Screen exige 25 arquivos diferentes no estado normal, isso pode significar no mínimo 25 draw calls, considerando que todos apareçam somente uma vez. Com o Atlas em funcionamento isso diminui para 1. Em termos técnicos, a quantidade de memória alocada que isso pode salvar é diretamente relacionada a quantidade de vezes que seu asset aparece na tela dentro de uma mesma sessão de jogatina. Sendo objetivo: menos draw calls, mais Frames por Segundo (FPS). E caso você não saiba, performance é ouro em game development.
Indo além, o Atlas amarra muito bem todos os tópicos deste artigo. Ele trás mais autonomia para os designers e oferece a possibilidade de tangibilizar qual o budget para UI. Suponhamos que você pode ter um Atlas por feature e além disso tem a liberdade de ter outro que mantém os assets de uso comum pelo jogo sem compressão alguma, sendo renderizado apenas uma vez. Não prejudicam a performance e mantém a qualidade visual alta, sem aquela sensação ruim de baixa resolução.
Voltando ao budget, agora você tem um artboard muito claro de quantos assets você ainda pode inserir. Caso não caiba mais nada, você precisa revisitar os antigos e entender se o 9-slicing ou tint podem te salvar de possíveis redundâncias.
Leia mais sobre como integrar o Sprite Atlas no seu projeto:
Taxonomia
Para quem não está familiarizado, Taxonomia é a etapa de agrupamento dos conteúdos e ações de acordo com o significado. É um termo advindo da Biologia, onde o objetivo é organizar e classificar as estruturas.
No Design, é utilizado como uma forma de estruturar, nomear, organizar e distribuir o que foi produzido. Pode ser simples e ao mesmo tempo muito complexo. O contexto influencia muito e na maioria das vezes suas definições surgem de um consentimento coletivo, onde o time define as boas práticas frisando o que deve ser feito e o que deve ser evitado.
Sendo bem objetivo, quando o Designer produz um layout, é extremamente importante que o handoff seja transparente e de fácil acesso. Em certos casos o próprio Designer faz a implementação na engine, em outros o Tech Artist ou o Engenheiro responsável pela feature. De qualquer forma, quando os assets são exportados do Figma, Photoshop ou outro software, ao importar no projeto, se não houver o mínimo de organização, o débito técnico só aumenta.
Sabemos que em cenários de urgência, sejamos francos, pode não ser possível ter todo cuidado desejado com os nomes das layers, componentes e afins. Entretanto, o ideal é que o Designer sempre organize minimamente seus entregáveis e tenha conhecimento do que já foi importado ou não para o projeto.
Assim, quando os assets forem exportados, você evita a duplicidade de arquivos e facilita o acesso posterior. Sabemos que é um processo doloroso de integrar, pois exige muita responsábilidade e disciplina de ambas as partes, mas sem dúvidas é de valor inimaginável para quem está no time no momento e futuras gerações.
Existem algumas sugestões de como começar, mas como este não é o foco principal do artigo, espero que a breve introdução ao assunto te motive a pesquisar mais. Lembre-se… independente do que for aplicar, o seu time precisa estar de acordo e ciente das adaptações para que a otimização tenha resultado.
Color space & Rendering pipeline
De todas as sugestões desta publicação, esta é a que mais me intriga. Talvez por ter sido um assunto completamente novo na minha rotina. No momento em que aprendi sobre este tópico minha visão de game development mudou bastante.
Artistas do mundo digital já estão familiarizados com o termo Color Space, mas dentro do universo dos jogos isso pode ser bem diferente. Esse assunto pode ser extremamente complexo, então vou me ater somente aos detalhes que impactam o resultado do trabalho do Designer.
Basicamente, Linear e Gamma são os Color space mais relevantes na produção digital. Já o rendering pipeline é um processo a parte que determina como a engine gráfica irá trabalhar com as cores, materiais, shaders e informações gráficas do jogo. Para conectar os dois termos, o Rendering Pipeline influencia diretamente qual Color Space será utilizado.
A decisão de usar uma forma ou outra está relacionada com a direção de arte do jogo, limitações técnicas, conhecimento da equipe e requisitos do studio. Enquanto o linear possibilita gráficos mais realistas, por exemplo, o gamma pode apresentar maior performance. Os motivos são muitos.
E o que isso tem a ver com UI?
Provavelmente o software que o Designer trabalha está exportando os assets no padrão de Gamma. Daí, quando importados em um projeto utilizando Linear, a fidelidade gráfica pode cair muito.
Existem diversos contornos para resolver este problema. Por exemplo, é possível:
- Criar uma camera que renderiza a UI em gamma e depois soma ao render do jogo em formato de overlay.
- Utilizar um shader personalizado em elementos de UI para corrigir a variação matemática calculada automaticamente pela engine.
- Se você estiver produzindo seus layouts no Photoshop, é possível exportar diretamente no color space da engine (com exceção do Figma que se limita ao Gamma).
Como trabalho com Figma, notei essas diferença assustadora de fidelidade e com o auxílio do meu time percebemos que as maiores anomalias surgem da dificuldade de conversão da Unity em situações que ocorrem mescla de assets. Por exemplo, você tem uma imagem para background de um card e acima dele você tem outra imagem com o degradê de uma cor de destaque. Este degradê vai de 100% de Alpha (transparência) a 0%. A anomalia ocorre a partir do momento em que ele está em 99% e precisa mesclar a sua cor com o fundo em tempo real.
Portanto uma forma de amenizar o impacto é evitar ter degradês com fade para o transparente. Ao invés disso, faça o degradê com o fade para a cor que você realmente utilizará no fundo. Assim o blend já estará rasterizado na imagem e a Unity não precisará calcular o resultado da mescla.
Sei que é um tópico complexo de entender e delicado de explicar, mas achei importante compartilhar, pois, ao menos na Unity, não existe uma solução definitiva. E caso você passe por essa situação, lembre das sugestões acima e não se desespere.
Caso queira ler um pouco mais sobre, confira o link abaixo:
Design review
Finalizando em harmonia com todos os tópicos anteriores, este será bem direto ao ponto. Se você, sendo Designer, quer que sua UI esteja com a qualidade alta durante a implementação, você precisa se envolver no processo inteiro. Quando digo isso, faço referência a todas as etapas de produção.
Não se prenda somente ao Figma. Participe da definição e da implementação! Veja como os engenheiros entendem seus entregáveis, como eles exportam, como importam no projeto e, principalmente, tente entender como fazer para você mesmo implementar sua UI na engine que trabalha. Dessa forma, sempre que necessário, você pode fazer um segundo passe para refinar o que somente os olhos treinados de um Designer podem enxergar.
Em determinados studios o UI Designer não precisa implementar nada, em outros ele cuida de todas as etapas. Independente de como funciona onde você trabalha, tenha em mente que aprender novas habilidades que tangem sua área de domínio sempre vão te engrandecer como profissional.
Conclusão
Por que você deve se preocupar em otimizar a UI de jogos mobile?
- Ser um designer/artista que entende o básico de otimização, pode te poupar de inúmeros infortúnios da rotina.
- Incluir algumas das etapas citadas acima no seu workflow vão te ajudar a ser um profissional mais maduro, completo e preocupado com o impacto do seu trabalho.
- Otimizar desde o início é a melhor forma de evitar problemas.
- Entender sobre estas questões é fundamental para atingir um nível alto de qualidade visual no seu jogo.
- Práticas de otimização, de modo geral, melhoram a vida de desenvolvedores de jogos e players. Trás escalabilidade e performance.
Apesar de tudo, otimizar é um eterno processo de aprendizado. Mesmo compartilhando com vocês todos estes temas, estou constantemente conversando com meu time para entender como podemos nos aperfeiçoar.
E mais importante que otimizar, é ter consciência do que você pretende melhorar. Para que você consiga vender essas ideias para o seu time é necessário deixar bem claro quais problemas vão se resolver, quais serão os ganhos no curto e longo prazo e qual o tamanho do impacto no roadmap. Tendo isso mapeado, a tendência é só melhorar!
As soluções sempre vão variar de acordo com o contexto em que seu jogo está inserido. Todas as sugestões citadas aqui são baseadas nas vivências que tive, por isso é importante analisar qual é a maior fonte de problema na sua pipeline de UI hoje.
Se você chegou até aqui, espero que este material tenha contribuído no seu crescimento de alguma forma. E caso tenha gostado, fique a vontade para conferir minhas outras publicações ou se conectar para sugerir novos temas, bater um papo, acompanhar meu trabalho ou até mesmo me contar se conseguiu aplicar alguma das técnicas que eu citei.
Antes de partir, um abraço aos mentores e amigos de profissão que contribuíram de forma direta ou indireta para a publicação deste material: Ingrid Bugarin, Om Tandom, Allan Camargo, Patrick Sava, Musa Sayyed, Huila Gomes e Vitor Canuto.
Forte abraço e até breve!
– Stéfano B. Girardelli.
