Sebenta · Conceber o design e desenvolver jogos interativos (UC04380)

Introdução

Esta sebenta ensina a conceber e desenvolver um jogo interativo do princípio ao fim: desde a ideia registada num documento técnico até ao ficheiro final pronto a publicar. Cobrimos as duas metades da profissão: o design (o que torna um jogo divertido e coerente) e a programação (como esse design se transforma em código que corre a frame rate estável).

O percurso segue a ordem real de um estúdio: primeiro analisam-se requisitos de design e gamificação, depois concebe-se e programa-se o jogo, criam-se animações 2D e 3D, integra-se inteligência artificial, e por fim otimiza-se, renderiza-se e ajusta-se o projeto para publicação. É transversal a qualquer motor de jogo (Unity, Unreal, Godot): a lógica é a mesma, muda a sintaxe.

Objetivos de aprendizagem (referencial): analisar requisitos de design e de gamificação para um projeto de jogo interativo; conceber e programar o desenvolvimento do jogo; programar e desenvolver animações 2D e 3D; integrar e programar funções de inteligência artificial; renderizar e ajustar o projeto para publicação.

1. Jogos interativos: conceitos e desenvolvimento

Um jogo é um sistema de regras que gera desafios e devolve feedback ao jogador em resposta às suas ações. A diferença essencial face a um filme ou um livro é a interatividade: o jogador decide, o sistema reage.

Todo o jogo assenta em quatro elementos:

• Objetivos · o que o jogador tenta alcançar.
• Regras · o que é permitido e o que não é.
• Feedback · confirmação (visual, sonora, numérica) do efeito de cada ação.
• Desafio · a dificuldade calibrada que mantém o jogador motivado, nem demasiado fácil nem impossível.

Tipologias e géneros

Os jogos organizam-se por três eixos que se cruzam:

Cada género traz convenções próprias de mecânicas e de câmara (um jogo de plataformas usa câmara lateral; um jogo de estratégia usa câmara aérea). O mercado-alvo · a idade, os hábitos e o dispositivo do público · condiciona a escolha de género e de plataforma logo no início do projeto, não depois.

2. Game design: princípios, elementos e mercado-alvo

O game design é a disciplina que define o que significa "jogar" aquele jogo específico. Assenta num modelo clássico chamado MDA:

• Mecânicas · as regras e ações possíveis (saltar, disparar, negociar). É o que o designer desenha diretamente.
• Dinâmicas · o comportamento que emerge das mecânicas quando o jogo é jogado (correr para não ser apanhado).
• Estética · a experiência emocional sentida pelo jogador (tensão, descoberta, diversão). É o resultado, não uma escolha direta.

No xadrez, as mecânicas são simples (movimentos de peças), mas a dinâmica emergente (planeamento, bluff psicológico) é que produz a estética de tensão. Um erro comum de iniciantes é definir "quero que seja divertido" sem desenhar as mecânicas concretas que produzem essa diversão.

As três perguntas do design

Antes de programar uma linha de código, todo o design responde a:

1. Qual é o objetivo do jogo? (vencer uma corrida, sobreviver, resolver um mistério)
2. Quais são as regras? O que o jogador pode e não pode fazer.
3. Para quem é? Idade, plataforma preferida, tempo de sessão disponível.

A relação entre dispositivo de publicação e interação também é uma decisão de design: um jogo mobile privilegia toque e sessões curtas; um jogo de consola privilegia comando e sessões longas.

Exemplo resolvido: definir os pilares de um jogo simples

Enunciado: um jogo de plataformas 2D em que o jogador recolhe moedas e evita inimigos.

Resolução (modelo MDA):

1. Mecânicas: correr, saltar, colidir com moedas (soma pontos), colidir com inimigos (perde vida).
2. Dinâmicas: o jogador aprende a antecipar padrões de inimigos e a arriscar saltos para moedas difíceis.
3. Estética: satisfação de domínio (mastery) ao completar níveis cada vez mais difíceis sem perder vidas.

O design está coerente: mecânicas simples produzem uma dinâmica de risco calculado, que gera a estética de domínio pretendida.

3. O game design document (GDD)

O Game Design Document (GDD) é o documento técnico central de um projeto de jogo. Descreve visão, mecânicas, narrativa, níveis e requisitos técnicos, e serve de referência comum a toda a equipa. Sem GDD, cada elemento da equipa tende a "inventar" o jogo à sua maneira, e o projeto diverge.

O GDD é um documento vivo: atualiza-se ao longo do desenvolvimento, em paralelo com o protótipo. Um GDD demasiado detalhado antes de existir um protótipo é frequentemente tempo perdido, porque o design muda assim que se testa.

Estrutura de um GDD

Exemplo resolvido: esboçar a secção de mecânicas de um GDD

Enunciado: escrever a secção "Mecânicas" do GDD para o jogo de plataformas do exemplo anterior.

Resolução:

## Mecânicas
- Movimento: esquerda/direita (contínuo), salto (botão único, altura variável
  consoante o tempo premido).
- Colisão com moeda: +10 pontos, som de recompensa, moeda desaparece.
- Colisão com inimigo: -1 vida, breve invulnerabilidade (1,5s), personagem pisca.
- Fim de jogo: 0 vidas → ecrã de "Game Over" com opção de recomeçar.
- Vitória de nível: chegar à bandeira final → ecrã de resumo + próximo nível.

Este texto, por si só, já dá a qualquer programador da equipa informação suficiente para começar a implementar sem ambiguidades.

4. Scripts de interação e storyboards operacionais

Scripts de interação

O script de interação descreve, passo a passo, como o jogador interage com uma funcionalidade específica: que botão prime, o que acontece, que estados o sistema assume. Define os fluxos prioritários (o caminho que a maioria dos jogadores segue) e também os casos de exceção (o que acontece quando o jogador falha ou desiste).

Storyboards operacionais

O storyboard operacional representa visualmente a lógica de interação: sequência de ecrãs, ações do jogador, estados do sistema, feedbacks e bifurcações (pontos onde o fluxo se divide consoante a escolha do jogador).

[Ecrã menu] --jogar--> [Carregar nível] --sucesso--> [Jogo a decorrer]
                                        --falha-----> [Ecrã de erro]

Exemplo resolvido: storyboard operacional de um menu de pausa

Enunciado: desenhar o storyboard operacional do menu de pausa de um jogo.

Resolução:

[Jogo a decorrer] --prime pausa--> [Menu de pausa]
    [Menu de pausa] --continuar--> [Jogo a decorrer] (retoma o estado exato)
    [Menu de pausa] --opções-----> [Ecrã de opções] --voltar--> [Menu de pausa]
    [Menu de pausa] --sair--------> [Confirmar saída]
        [Confirmar saída] --sim--> [Ecrã menu principal]
        [Confirmar saída] --não--> [Menu de pausa]

Note-se a bifurcação de confirmação antes de sair: evita que o jogador perca progresso por um clique acidental. É exatamente este tipo de detalhe que um script de interação bem escrito obriga a pensar antes de programar.

5. Linguagens de programação e motores de jogo

Tipos de linguagens

C# é a linguagem principal do motor Unity. GDScript é a linguagem própria do Godot, inspirada em Python. Blueprints, no Unreal Engine, é uma linguagem visual, por nós e ligações, sem escrever texto.

Motores de jogo

Escolher motor é uma decisão de projeto (plataforma-alvo, equipa, orçamento), não uma preferência pessoal. Os conceitos (game loop, colisão, animação) são transferíveis entre motores; a sintaxe não.

Objetos, scripts e ciclo de vida

Num motor moderno, um jogo é uma coleção de objetos (personagens, inimigos, itens), cada um com um ou mais scripts anexados que definem o seu comportamento. Cada script tem um ciclo de vida: eventos que o motor chama automaticamente (ao iniciar, a cada frame, ao colidir).

Exemplo resolvido: script de salto em pseudocódigo

Enunciado: escrever a lógica de um salto que só funciona quando o personagem está no chão.

Resolução:

variavel no_chao = verdadeiro
variavel velocidade_salto = 8

funcao AoCadaFrame():
    se tecla_espaco_premida E no_chao:
        aplicar_forca_vertical(velocidade_salto)
        no_chao = falso

funcao AoColidirComChao():
    no_chao = verdadeiro

O detalhe crítico é a variável no_chao: sem ela, o jogador pode saltar infinitamente no ar (bug clássico de iniciante), porque nada impede que a tecla dispare o salto repetidamente.

6. Gameplay: lógica, estruturas de dados e algoritmos

O gameplay é o conjunto de regras e sistemas que definem como o jogo funciona quando jogado. O centro de tudo é o game loop: o ciclo processar entrada → atualizar estado → desenhar ecrã, repetido a cada frame (tipicamente 30 ou 60 vezes por segundo).

O estado do jogo é o conjunto de variáveis que descrevem a situação atual (vida, pontuação, nível, inventário). As regras determinam as transições entre estados (perder vida ao colidir, subir de nível ao atingir pontos).

Estruturas de dados aplicadas

Exemplo resolvido: deteção de colisão por caixas (AABB)

Enunciado: verificar se dois retângulos (jogador e inimigo) se sobrepõem.

Resolução:

se (jogador.x < inimigo.x + inimigo.largura) E
   (jogador.x + jogador.largura > inimigo.x) E
   (jogador.y < inimigo.y + inimigo.altura) E
   (jogador.y + jogador.altura > inimigo.y)
então colisao = verdadeiro
senao colisao = falso

Este algoritmo, chamado AABB (Axis-Aligned Bounding Box), verifica sobreposição nos dois eixos em simultâneo. Um erro comum é testar só um eixo e concluir colisão quando os retângulos apenas se alinham verticalmente sem se tocarem horizontalmente.

7. Gamificação: sistemas de progressão

Gamificação é aplicar elementos e mecânicas de jogo (pontos, níveis, desafios) a contextos que não são jogos · aprendizagem, fitness, produtividade · para aumentar a motivação e o envolvimento. Difere de "fazer um jogo pequeno": não precisa de narrativa nem de género, só das mecânicas certas, aplicadas com feedback significativo.

Sistemas comuns

• Sistema de progressão: pontos de experiência (XP) que acumulam e desbloqueiam níveis.
• Leaderboard: ordena jogadores/utilizadores por pontuação, geralmente ligado a uma base de dados.
• Moeda virtual: pontos ou créditos trocáveis por recompensas dentro do sistema.
• Badges/conquistas: reconhecimento visual por objetivos cumpridos.

O critério de desempenho da UC é claro: garantir integração funcional e feedback motivacional em projetos não-jogo na codificação do sistema de gamificação. A gamificação tem de funcionar tecnicamente, não só parecer bonita no papel.

Exemplo resolvido: lógica de subida de nível

Enunciado: codificar a subida de nível de um sistema de XP.

Resolução:

funcao GanharXP(pontos):
    xp = xp + pontos
    enquanto xp >= xp_necessario_proximo_nivel:
        xp = xp - xp_necessario_proximo_nivel
        nivel = nivel + 1
        xp_necessario_proximo_nivel = xp_necessario_proximo_nivel * 1.2
        mostrar_feedback("Subiste para o nível " + nivel + "!")

Repare-se no enquanto (não se): se o jogador ganhar XP suficiente para subir dois níveis de uma vez (por exemplo, um bónus grande), o ciclo processa as duas subidas corretamente. Usar apenas se é um erro comum que deixa o contador de XP negativo ou disparado.

8. Animação 2D e 3D

Animação 2D

A animação 2D assenta em duas técnicas:

• Sprite sheet: uma imagem única com vários frames de uma animação, trocados em sequência para simular movimento.
• Animação esquelética 2D: um "esqueleto" de ossos articulados que deforma uma imagem única, poupando memória face a muitos sprites.

[frame 1][frame 2][frame 3][frame 4]  → reproduzidos a 12 fps → personagem "anda"

Os estados de animação (parado, a andar, a saltar) trocam-se consoante o estado do gameplay: é o mesmo tipo de máquina de estados usada na lógica de jogo, aplicada agora a poses visuais.

Animação 3D

Em 3D usam-se esqueletos (rigs) com ossos e articulações, e keyframes: poses-chave definidas pelo animador, entre as quais o motor interpola (calcula) os frames intermédios automaticamente. O blend de animações faz a transição suave entre duas animações (de andar para correr), evitando saltos bruscos.

Exemplo resolvido: máquina de estados de animação

Enunciado: desenhar as transições de animação de um personagem que anda, corre e salta.

Resolução:

Estado: Parado --anda--> Andar --corre--> Correr --salta--> Salto --aterra--> Parado

O detalhe que iniciantes esquecem é o estado Aterrar: ir diretamente de "Salto" para "Parado" faz o personagem parecer teletransportado. Um estado intermédio curto de aterragem, com a sua própria animação, resolve o problema.

9. Física, colisão e gestão de assets

Física

Os motores trazem um motor de física integrado que simula gravidade, forças e colisões:

• Rigidbody: componente que dá a um objeto propriedades físicas (massa, gravidade, velocidade).
• Collider: forma invisível (caixa, esfera, malha) usada para detetar colisões, geralmente mais simples do que o modelo visual.
• Camadas de colisão: definem que tipos de objetos podem colidir entre si (jogador colide com paredes, não com moedas).

Gestão de assets

A gestão de recursos (assets) organiza modelos, texturas, sons e scripts ao longo de todo o desenvolvimento:

• Convenção de nomes e estrutura de pastas consistente (Personagens/, Cenarios/, Audio/).
• Formatos otimizados: texturas comprimidas, modelos com contagem de polígonos adequada à plataforma.
• Reutilização: prefabs/blueprints reutilizáveis em vez de duplicar objetos.
• Controlo de versões: evita perder trabalho quando vários elementos da equipa mexem no mesmo projeto.

Exemplo resolvido: escolher o collider certo

Enunciado: um personagem 3D detalhado (milhares de polígonos) precisa de um collider para detetar colisões com o cenário. Que forma escolher?

Resolução: usar uma cápsula simples que envolva aproximadamente o corpo do personagem, em vez de um collider de malha (mesh collider) idêntico ao modelo visual. A cápsula é computacionalmente barata de testar contra o cenário; um mesh collider de milhares de polígonos degrada o frame rate sem melhorar de forma percetível a jogabilidade.

10. Inteligência artificial em jogos

A inteligência artificial (IA) em jogos não é IA generativa: são agentes com comportamentos programados que reagem ao jogador e ao ambiente.

• Máquina de estados finita (FSM): o agente muda de comportamento (patrulhar, perseguir, atacar) consoante condições.
• Árvores de comportamento: estruturas mais flexíveis para IA complexa, usadas em jogos de maior escala.
• Perceção: o agente "vê" ou "ouve" o jogador dentro de um raio ou cone definido, nunca de forma perfeita e ilimitada · isso tornaria o jogo injusto.

Estado: Patrulhar --vê o jogador--> Perseguir --está perto--> Atacar
                                                --perde de vista--> Patrulhar

Pathfinding

O pathfinding é o cálculo do caminho mais eficiente que um agente percorre até um destino, evitando obstáculos.

• NavMesh (malha de navegação): superfície que define onde os agentes podem andar, calculada a partir do cenário 3D.
• Algoritmo A*: o mais usado em jogos, combina a distância já percorrida com uma estimativa da distância que falta até ao destino.

Exemplo resolvido: diagnosticar uma falha de pathfinding

Enunciado: um inimigo fica "preso" contra uma parede em vez de contornar um obstáculo novo colocado no cenário. Qual a causa mais provável e a solução?

Resolução: a causa mais provável é a NavMesh não ter sido recalculada depois de o cenário mudar (um obstáculo novo, uma porta fechada). O agente continua a navegar segundo a malha antiga, que ainda não conhece o obstáculo.

Solução: marcar o cenário e os objetos relevantes como "estáticos para navegação" e forçar o recálculo da NavMesh sempre que o layout do nível é alterado em tempo de jogo.

11. Áudio dinâmico

O áudio dinâmico ajusta música e efeitos sonoros em tempo real, consoante o que acontece no jogo, em vez de tocar uma faixa fixa do início ao fim.

• Efeitos sonoros (SFX): disparados por eventos (salto, dano, colecionável).
• Música adaptativa: camadas de música que se ligam ou desligam consoante a tensão (exploração vs combate).
• Áudio espacial (3D): volume e direção do som mudam consoante a posição da fonte face ao jogador.

Integrar e programar módulos de áudio dinâmico no motor de jogo é um critério de desempenho explícito desta UC.

Exemplo resolvido: disparar som ao apanhar um colecionável

void AoColidirComMoeda() {
    AudioSource.PlayOneShot(somMoeda);
    pontuacao += 10;
    AtualizarUI();
}

O evento dispara três coisas em sequência: som (feedback imediato), atualização de estado (pontuação) e atualização de interface. PlayOneShot permite tocar vários sons curtos sobrepostos, sem cortar o som anterior · essencial quando várias moedas são apanhadas em rápida sucessão. Usar uma função que substitui o som anterior, em vez de sobrepor, é um erro comum que "corta" o áudio em sequências rápidas de eventos.

12. Otimização: código, memória e desempenho

Um jogo interativo tem de correr a frame rate estável (30 ou 60 fps), mesmo em cenas complexas.

• Object pooling: reutilizar objetos (balas, inimigos) em vez de criar e destruir constantemente, operação computacionalmente cara.
• Culling: não processar nem desenhar o que está fora da câmara.
• Nível de detalhe (LOD): usar modelos 3D mais simples quanto mais longe estão da câmara.
• Profiling: medir onde o jogo gasta tempo (CPU, GPU, memória) antes de otimizar. Otimizar sem medir é adivinhar.

Bugs de memória e desempenho

• Memory leak (fuga de memória): objetos que deviam ser libertados continuam ocupados; a memória usada só cresce.
• Garbage collection: em linguagens como C#, o coletor de lixo liberta memória automaticamente, mas picos de GC causam quebras visíveis de frame rate.
• Testes de stress: sessões longas de jogo apanham quebras que só aparecem ao fim de tempo.

Exemplo resolvido: diagnosticar um memory leak

Enunciado: um jogo começa fluido e, ao fim de 20 minutos, a frame rate cai gradualmente até se tornar impraticável. Que hipótese investigar primeiro e como corrigir?

Resolução: uma queda gradual e crescente ao longo do tempo (não logo no início) é a assinatura clássica de uma fuga de memória, tipicamente objetos criados a cada frame ou a cada evento (por exemplo, efeitos de partículas de cada disparo) que nunca são destruídos nem reutilizados.

Correção: aplicar object pooling aos efeitos e projéteis, criando um número fixo de objetos ao início do nível e reciclando-os, em vez de instanciar e destruir a cada disparo.

13. Renderização e publicação

O rendering transforma a cena (3D ou 2D) em pixels no ecrã, a cada frame, através de um pipeline: geometria → texturas e materiais → iluminação → pós-processamento → imagem final.

• Iluminação em tempo real é flexível mas cara computacionalmente; iluminação pré-calculada (baked) é barata mas não reage a mudanças na cena. Um jogo mobile usa quase sempre iluminação baked, precisamente pelo custo.
• Pós-processamento: efeitos sobre a imagem final (bloom, color grading, anti-aliasing). Ativar todos sem medir o impacto no frame rate é um erro comum.

Ajustar para publicação

• Adaptabilidade da interface: layouts que se ajustam a diferentes resoluções e proporções de ecrã (16:9, 21:9, vertical).
• Anchors/âncoras de UI: elementos que se mantêm no lugar relativo (canto, centro) independentemente do tamanho do ecrã, em vez de coordenadas fixas que "saem" do ecrã noutras proporções.
• Build final: compilar o jogo para a plataforma-alvo (Windows, Android, WebGL), com as definições de qualidade adequadas a cada uma.

Exemplo resolvido: checklist mínima antes de publicar

Enunciado: que verificações fazer antes de submeter uma build a uma loja de aplicações?

Resolução:

1. Testar em pelo menos duas resoluções/proporções diferentes.
2. Confirmar que todos os controlos (teclado, comando, toque) funcionam na build final, não só no editor.
3. Verificar o tamanho do ficheiro final e comprimir assets se necessário.
4. Correr o jogo do início ao fim na build compilada, não apenas no editor de desenvolvimento.
5. Rever se há iluminação, texturas ou UI que dependam de definições que só existem no editor.

14. Realidade virtual e aumentada, segurança e ambiente

A realidade virtual (RV) imerge o jogador num ambiente totalmente digital através de um headset; a realidade aumentada (RA) sobrepõe elementos digitais ao mundo real, através da câmara de um telemóvel ou de óculos próprios.

• Em RV, a animação tem de responder ao movimento da cabeça sem atraso percetível (latência), sob pena de causar enjoo (motion sickness).
• Em RA, os objetos digitais têm de se ancorar a superfícies reais e manter-se estáveis quando a câmara se move.
• Em ambas, o frame rate elevado e constante é a prioridade máxima: quebras são muito mais percetíveis do que num jogo de ecrã plano tradicional.

Segurança e ambiente

• Normas de segurança e saúde no trabalho: pausas regulares ao usar equipamento de RV, ajuste ergonómico do posto de trabalho, espaço livre suficiente à volta do utilizador.
• Normas de proteção ambiental: gestão responsável de equipamento eletrónico (headsets, sensores) em fim de vida.

O percurso completo desta UC segue sempre a mesma lógica: GDD → prototipagem → programação de gameplay → arte e animação → IA e áudio → otimização → renderização e build final. Domina este fluxo e adaptas-te a qualquer motor ou género de jogo.

Erros comuns

• Escrever "quero que seja divertido" sem desenhar as mecânicas concretas que produzem essa diversão.
• GDD escrito uma vez e nunca atualizado, ficando desalinhado do jogo real à medida que este evolui.
• Storyboard operacional sem bifurcações, esquecendo o que acontece quando o jogador erra ou desiste.
• Testar colisão só num eixo (AABB incompleta), gerando falsos positivos ou negativos.
• Usar se em vez de enquanto ao subir de nível, perdendo XP acumulado quando o jogador ganha o suficiente para subir vários níveis de uma vez.
• Ir diretamente de "salto" para "parado" na máquina de estados de animação, sem um estado de aterragem.
• Colliders de malha idênticos ao modelo visual, degradando o frame rate sem necessidade.
• IA com perceção perfeita e ilimitada, tornando o jogo injusto e frustrante.
• Não recalcular a NavMesh depois de mudar o cenário, deixando agentes presos.
• Instanciar e destruir objetos a cada frame (sem object pooling), causando quebras de frame rate e fugas de memória.
• Testar só na resolução do editor e descobrir problemas de UI só depois de publicar.

Glossário

• Game design · disciplina que define as regras, mecânicas e experiência de um jogo.
• GDD (Game Design Document) · documento técnico central que descreve o jogo para toda a equipa.
• MDA · modelo Mecânicas, Dinâmicas, Estética.
• Script de interação · descrição passo a passo de como o jogador interage com uma funcionalidade.
• Storyboard operacional · representação visual da lógica de interação, com estados e bifurcações.
• Game loop · ciclo repetido a cada frame: processar entrada, atualizar estado, desenhar ecrã.
• Gamificação · aplicar mecânicas de jogo a contextos que não são jogos.
• Motor de jogo (engine) · software base que fornece renderização, física, áudio e execução de scripts.
• Rigidbody / Collider · componentes de física e de deteção de colisão de um objeto.
• Sprite sheet · imagem com vários frames de uma animação 2D.
• Rig / Keyframe · esqueleto de animação e pose-chave interpolada pelo motor.
• FSM (máquina de estados finita) · estrutura de decisão usada em IA e em animação.
• Pathfinding / NavMesh / A* · cálculo de caminho, malha de navegação e algoritmo de procura de caminho mais usado em jogos.
• Object pooling · reutilização de objetos em vez de criar e destruir constantemente.
• Memory leak · fuga de memória, objetos nunca libertados.
• Rendering · processo de gerar a imagem final a partir da cena.
• LOD (Level of Detail) · nível de detalhe de um modelo, adaptado à distância da câmara.
• RV / RA · realidade virtual e realidade aumentada.

Síntese

Desenvolver um jogo interativo segue sempre a mesma ordem: analisar requisitos de design e gamificação → documentar no GDD, scripts de interação e storyboards operacionais → conceber e programar o gameplay com estruturas de dados e algoritmos → animar em 2D e 3D → integrar física e assets → programar IA (FSM, pathfinding) e áudio dinâmico → otimizar código e memória → renderizar e ajustar para publicação, incluindo RV/RA quando aplicável. Domina este fluxo completo e és capaz de conceber e desenvolver qualquer jogo interativo, em qualquer motor.

Exercícios resolvidos

1. Um colega diz "não preciso de GDD, já sei o que quero fazer". Que lhe respondes?

Resolução: que o GDD não é só para ele, é para alinhar toda a equipa com a mesma visão, evitando que cada elemento "invente" partes do jogo à sua maneira. Mesmo trabalhando sozinho, o GDD serve de referência para não perder consistência ao longo de semanas de desenvolvimento.

2. Um jogo tem duas moedas que se tocam ligeiramente na diagonal, mas o código não regista colisão. Qual o erro mais provável no algoritmo AABB?

Resolução: o código provavelmente testa a sobreposição só num eixo (x ou y) em vez dos dois em simultâneo. O AABB correto exige que as quatro condições (x mínimo, x máximo, y mínimo, y máximo) sejam verdadeiras ao mesmo tempo para haver colisão real.

3. Um sistema de XP faz o contador ficar negativo quando o jogador ganha um bónus grande. Qual é a causa e a correção?

Resolução: a subida de nível está implementada com se em vez de enquanto, processando apenas uma subida de nível mesmo quando o XP ganho chega para subir vários. A correção é usar um ciclo enquanto xp >= xp_necessario que processa todas as subidas necessárias.

4. Um inimigo com IA fica sempre "colado" a uma parede depois de o jogador colocar uma caixa nova no caminho dele. Diagnostica e resolve.

Resolução: a NavMesh não foi recalculada depois de a caixa ser colocada, pelo que o agente continua a navegar segundo a malha antiga. Resolve-se marcando a caixa como obstáculo de navegação e forçando o recálculo da NavMesh sempre que o layout do nível muda em tempo de jogo.

5. Um jogo mobile começa a "engasgar" (queda de frame rate) sempre que há muitos tiros no ecrã ao mesmo tempo. Que técnica de otimização aplicar primeiro?

Resolução: object pooling para os projéteis: em vez de instanciar e destruir um objeto por cada tiro (operação cara e potencial fonte de fuga de memória), criar um conjunto fixo de projéteis ao início e reutilizá-los, ativando e desativando-os conforme necessário.

6. Antes de publicar, um jogo só foi testado no ecrã do computador do programador (16:9). Que problema é provável surgir e como se previne?

Resolução: elementos de interface fixos por coordenadas podem sair do ecrã ou sobrepor-se de forma incorreta noutras proporções (ex.: ecrãs verticais de telemóvel). Previne-se usando âncoras (anchors) relativas em vez de posições absolutas, e testando sempre em pelo menos duas resoluções antes de submeter a build final.