Arte para Jogo Mobile: Tamanhos, Toque e Legibilidade

Arte para jogo mobile segue quatro regras que a arte de PC não precisa seguir: alvo de toque com pelo menos 44x44 pontos no iOS e 48x48 dp no Android, sprites e textos legíveis numa tela de cerca de 6 polegadas a um palmo do rosto, elementos importantes dentro da área segura (longe do notch e das barras do sistema) e contraste que aguenta a luz do sol. E a regra que junta todas: o teste é no celular real, não no monitor.

Este guia passa por cada regra com números de referência, mostra como montar um mockup de tela no Krita para conferir tamanho e contraste e termina com o código de área segura na Unity e o equivalente no Godot.

Arte para jogo mobile: o que muda da tela de PC

No PC, o jogador está a mais ou menos meio metro de um monitor de 24 polegadas, com mouse de precisão de 1 pixel. No celular, a tela é umas quatro vezes menor, o dedo cobre uma área grande e imprecisa e a mão tampa parte da tela enquanto joga.

Consequências diretas para a arte:

• O dedo esconde o que está embaixo dele. Informação importante não fica onde o polegar descansa (cantos inferiores, no modo paisagem).
• Detalhe pequeno some. Um ícone de 32 pixels que lê bem no monitor pode virar uma mancha no celular.
• Hover não existe. Toda informação que, no PC, aparece ao passar o mouse precisa de outro jeito de aparecer.
• Orientação define o layout. Retrato (vertical) e paisagem (horizontal) pedem composições diferentes. Decida antes de desenhar.
• Ambiente ruim. Ônibus, sol, brilho de tela no mínimo para economizar bateria.

Tamanho de botão mobile e alvo de toque

As duas plataformas publicam o tamanho mínimo da área de toque (conferido em outubro de 2026):

• iOS (Apple Human Interface Guidelines): botão com área de toque de pelo menos 44x44 pontos.
• Android (Material Design): alvo de toque de pelo menos 48x48 dp. A página de acessibilidade do Android lembra que 48 dp equivalem a cerca de 9 mm na tela e recomenda pelo menos 8 dp de espaço entre alvos.

Ponto (pt) e dp são unidades independentes de densidade. Para converter em pixels:

O que isso significa na prática:

• Área de toque não é o desenho. O ícone pode ter 24 dp desenhados e uma área de toque invisível de 48 dp em volta. Combine com quem programa qual é a área real.
• Mínimo não é ideal. O mínimo é para menus. Botões de ação de jogo (pular, atacar), que o jogador aperta sem olhar, ficam bem maiores.
• Espaço entre botões. Dois botões colados aumentam o toque errado. Respeite o espaçamento.

Para controles virtuais (joystick e botões de ação), o post sobre controles touch no Godot com joystick virtual mostra o lado do código, e ajuda a desenhar a arte já no tamanho certo.

Legibilidade de sprite e texto em 6 polegadas

Sprites. Personagem de jogo mobile precisa ser lido rápido, muitas vezes em movimento:

• silhueta clara e contorno com contraste contra o fundo;
• cores do personagem que não existem no cenário (ou existem pouco);
• inimigos que se distinguem do jogador pela forma, não só pela cor;
• em pixel art, escala inteira: cada pixel da arte vira 3, 4 ou 5 pixels de tela, nunca 3,5.

Texto. Fonte fina e com serifa delicada some. Prefira fontes com traço grosso, letras abertas e boa altura de x. Evite texto longo na tela de jogo; deixe para menus. Texto sobre cenário sempre com fundo, sombra ou contorno.

Ícones. Ícones parecidos entre si são o erro clássico de UI mobile: poção de vida e poção de mana que só mudam de cor, em 32 pixels. Diferencie pela forma do frasco.

Teste rápido no Krita. Com a tela pronta, abra o Overview docker (Settings > Dockers > Overview). Ele mostra a imagem inteira em miniatura, mais ou menos como ela vai parecer no tamanho real do celular. Se você não reconhece o personagem e não lê o texto na miniatura, ele não vai ser lido no jogo.

Contraste e luz ambiente

Jogo mobile é jogado na rua, com brilho baixo e reflexo. Contraste que parece bom no monitor calibrado do seu quarto desaparece.

Como conferir:

• Teste em escala de cinza. No Krita, adicione uma camada de filtro no topo (Layer > New > Add Filter Layer, escolha Desaturate). Se personagem, inimigos e botões ainda se separam do fundo em cinza, o contraste de valor está bom. Desligue a camada depois.
• Texto com contraste alto. Para texto, uma referência útil é a recomendação de acessibilidade WCAG, que pede razão de contraste de pelo menos 4,5:1 para texto normal.
• Evite cor como única informação. Vermelho e verde lado a lado falham para parte dos jogadores e sob luz forte. Some forma ou ícone à cor.
• Fundo mais calmo que o primeiro plano. Menos saturação e menos contraste no fundo deixam personagem e UI saltarem.

Arte legível e com contraste é metade do problema. A outra metade é fazer essa arte caber em telas de proporções diferentes, com notch, barra de gestos e escala certa, e isso já depende da engine. É o ponto em que a arte deixa de ser imagem e vira jogo funcionando, e onde quem estuda sozinho mais trava, porque cada ajuste pede entender a arte e a engine ao mesmo tempo.

Área segura: notch e barras do sistema

Celulares atuais têm recorte de câmera (notch ou furo), cantos arredondados e barras de gesto. A área segura (safe area) é o retângulo livre disso tudo.

Regras para a arte:

• Fundo e cenário podem sangrar até a borda. Desenhe o fundo maior que a área segura, para não aparecer faixa preta.
• HUD, botões e texto ficam dentro da área segura. Vida, pontuação, pausa, botões de ação.
• Margem extra nos cantos. Mesmo dentro da área segura, os cantos arredondados cortam visualmente.

No Krita, monte um mockup de tela. Crie um canvas no tamanho de uma tela de referência (File > New, por exemplo 2400x1080 pixels para paisagem). Crie uma camada chamada area_segura e pinte, com 30% de opacidade, faixas nas laterais onde o notch pode aparecer e uma faixa embaixo para a barra de gestos. Desenhe o HUD em outra camada e confira que nada importante encosta nas faixas. Mantenha a camada area_segura oculta na exportação.

Na engine, a área segura é lida em tempo real, porque cada aparelho tem a sua. Na Unity, o Screen.safeArea devolve o retângulo em pixels. Este script, colado num painel de UI que contém o HUD, ajusta as âncoras do painel para caber na área segura. Arquivo SafeAreaFitter.cs:

using UnityEngine;

[RequireComponent(typeof(RectTransform))]
public class SafeAreaFitter : MonoBehaviour
{
    private RectTransform panel;
    private Rect lastSafeArea;
    private Vector2Int lastScreenSize;

    private void Awake()
    {
        panel = GetComponent<RectTransform>();
        Apply();
    }

    private void Update()
    {
        bool sizeChanged = Screen.width != lastScreenSize.x || Screen.height != lastScreenSize.y;
        if (Screen.safeArea != lastSafeArea || sizeChanged)
        {
            Apply();
        }
    }

    private void Apply()
    {
        Rect safeArea = Screen.safeArea;
        lastSafeArea = safeArea;
        lastScreenSize = new Vector2Int(Screen.width, Screen.height);

        Vector2 anchorMin = safeArea.position;
        Vector2 anchorMax = safeArea.position + safeArea.size;
        anchorMin.x /= Screen.width;
        anchorMin.y /= Screen.height;
        anchorMax.x /= Screen.width;
        anchorMax.y /= Screen.height;

        panel.anchorMin = anchorMin;
        panel.anchorMax = anchorMax;
    }
}

O painel precisa estar dentro de um Canvas e ocupar a tela inteira antes do ajuste. O fundo do jogo fica fora desse painel, para continuar sangrando até a borda. No Godot, o equivalente é ler DisplayServer.get_display_safe_area(), que devolve um Rect2i em pixels, e aplicar como margem num MarginContainer que envolve o HUD.

Proporções de tela e escala da arte

Celulares atuais são compridos, com proporções perto de 19,5:9 e 20:9; tablets ficam mais perto de 4:3. A mesma arte precisa funcionar em todas.

Como desenhar para isso:

• Defina uma resolução de referência (por exemplo, 1920x1080 em paisagem) e desenhe a UI nela. Na Unity, o Canvas Scaler em Scale With Screen Size com essa resolução cuida da escala; no Godot, o modo de stretch canvas_items com aspecto expand faz o papel.
• Desenhe o cenário com sobra nas laterais (ou em cima e embaixo, no retrato). Em tela mais comprida, a sobra aparece; em tela mais curta, fica cortada.
• Ancore a UI nas bordas, não no centro. Botão de pausa ancorado no canto superior direito acompanha qualquer proporção.
• Pixel art com escala inteira e filtro sem suavização, para os pixels não ficarem de tamanhos diferentes.

Erros comuns: UI do PC encolhida, texto fino, ícones parecidos

• UI do PC encolhida. Botões que eram ótimos com mouse viram alvos de 20 pixels no celular.
• Texto fino e pequeno. Fonte elegante de 12 pixels que ninguém lê no ônibus.
• Ícones que só mudam de cor. Ilegíveis em tamanho pequeno e para quem tem daltonismo.
• HUD encostado na borda. Coberto pelo notch ou pela barra de gestos.
• Informação embaixo do polegar. Barra de vida no canto inferior, exatamente onde o dedo fica.
• Escala fracionária em pixel art. Pixels de tamanhos diferentes que parecem tremer na tela.
• Detalhe demais no cenário. Fundo que compete com o personagem.

Testar no aparelho, não no monitor

Nada substitui ver a arte no celular. Três formas, da mais rápida para a mais completa:

1. Imagem no celular. Exporte o mockup do Krita em PNG no tamanho da tela de referência e abra na galeria do celular, em tela cheia. Leve para a rua e olhe sob o sol.
2. Espelhamento durante o desenvolvimento. Na Unity, o Device Simulator (Window > General > Device Simulator) mostra a tela com notch e área segura de vários aparelhos, útil para posicionar o HUD, mas ele não substitui o aparelho. No Godot, rode o projeto direto no celular com a exportação de Android configurada.
3. Build no aparelho. O teste final: jogar com o polegar, de verdade, por alguns minutos.

O próximo passo: pegue a tela principal do seu jogo, monte o mockup no Krita com a camada de área segura, exporte e abra no celular hoje. Anote três coisas que você não leu ou não conseguiu tocar. Depois, leia como criar seu primeiro jogo mobile para o lado de projeto e publicação, e o guia de UI e UX em jogos para hierarquia visual de menus.