O que é um jogo interativo

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

• Objetivos: o que o jogador tenta alcançar.
• Regras: o que é permitido e o que não é.
• Feedback: som, animação, pontuação, que confirmam o efeito da ação.
• Desafio: a dificuldade que mantém o jogador motivado, nem fácil nem impossível.

Sem interação não há jogo, só uma animação bonita a correr sozinha.

Tipologias e géneros de jogos

Os jogos organizam-se por plataforma, género e modo de jogador:

• Cada género traz convenções próprias de mecânicas e de câmara.
• O mercado-alvo (idade, hábitos, dispositivo) condiciona o género e a plataforma escolhidos.

Os pilares do game design

O game design é a disciplina que define o que é jogar aquele jogo. Assenta em quatro elementos que se reforçam mutuamente:

• Mecânicas: as regras e ações possíveis (saltar, disparar, negociar).
• Dinâmicas: o comportamento que emerge das mecânicas em jogo (correr para não ser apanhado).
• Estética: a experiência emocional que o jogador sente (tensão, descoberta, diversão).
• Interação: como o jogador comunica com o sistema (comandos, ecrã tátil, voz).

Este é o modelo MDA: Mecânicas → Dinâmicas → Estética. O designer desenha mecânicas, mas quem sente a estética é o jogador.

Objetivos, regras e mercado-alvo

Antes de programar uma linha de código, o design responde a três perguntas:

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 é design: um jogo mobile usa toque e sessões curtas; um jogo de consola usa comando e sessões longas.

Para que serve o 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 para toda a equipa.

• Evita que cada elemento da equipa "invente" o jogo à sua maneira.
• É um documento vivo: atualiza-se ao longo do desenvolvimento.
• Serve para comunicar a ideia a produtores, investidores ou professores.

Sem GDD, um projeto de jogo em equipa tende a divergir em direções incompatíveis.

Estrutura de um GDD

Um GDD típico inclui:

O GDD não precisa de estar completo antes de começar a programar: cresce em paralelo com o protótipo.

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 fluxos prioritários: o caminho principal que a maioria dos jogadores segue.
• Cobre também casos de exceção: o que acontece se o jogador falhar ou desistir.
• É a ponte entre o design e a implementação: o programador lê o script e sabe o que codificar.

Um script de interação bem escrito elimina ambiguidades antes de a equipa perder tempo a programar o comportamento errado.

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 (diferentes caminhos possíveis).

• Sequência: a ordem dos eventos.
• Ações: o que o jogador faz em cada passo.
• Estados do sistema: o que o jogo mostra em cada momento.
• Feedbacks: confirmação visual ou sonora de cada ação.
• 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]

Tipos de linguagens de programação

As linguagens usadas em desenvolvimento de jogos dividem-se por paradigma e nível:

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

Objetos, scripts e o ciclo de vida

Em quase todos os motores modernos, 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).
• Variáveis guardam o estado do objeto (vida, posição, pontuação).
• Funções encapsulam comportamentos reutilizáveis (saltar, disparar, morrer).

void Update() {
    if (Input.GetKeyDown("space")) {
        Saltar();
    }
}

A lógica de gameplay

O gameplay é o conjunto de regras e sistemas que definem como o jogo realmente funciona quando jogado: o loop central que se repete até o jogador ganhar, perder ou sair.

• Loop de jogo (game loop): o ciclo processar entrada → atualizar estado → desenhar ecrã, repetido a cada frame.
• Estado do jogo: variáveis que descrevem a situação atual (vida, pontuação, nível, inventário).
• Regras: condições que determinam transições de estado (perder vida ao colidir, subir de nível ao atingir pontos).

Definir a lógica de gameplay de forma organizada evita que o código se torne incontrolável à medida que o jogo cresce.

Estruturas de dados e algoritmos aplicados

O gameplay usa estruturas de dados e algoritmos concretos, não apenas "código":

Exemplo resolvido: detetar colisão simples

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 colisão = verdadeiro

O que é gamificaçã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 o motivação e o envolvimento.

• Objetivo: transformar tarefas repetitivas ou difíceis em experiências motivadoras.
• Difere de um "jogo completo": não precisa de narrativa nem de género, só das mecânicas certas.
• Aplica-se em apps educativas, programas de fidelização, formação empresarial.

O critério de desempenho da UC exige integração funcional e feedback motivacional em projetos não-jogo: a gamificação tem de funcionar, não só parecer bonita.

Progressão, leaderboards e moeda virtual

Os sistemas mais comuns de gamificação, e a sua implementação programática:

• Sistema de progressão: pontos de experiência (XP) que acumulam e desbloqueiam níveis.
• Leaderboard (tabela de classificação): ordena jogadores 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.

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

xp = xp + pontos_ganhos
se xp >= xp_necessario_proximo_nivel:
    nivel = nivel + 1
    xp = xp - xp_necessario_proximo_nivel
    mostrar_feedback("Subiste de nível!")

Motores de jogo

Um motor de jogo (game engine) é o software que fornece a infraestrutura comum a qualquer jogo: renderização, física, áudio, gestão de assets e execução de scripts.

• O motor poupa a equipa de reescrever física ou renderização de raiz.
• Cada motor tem o seu pipeline: a sequência de passos entre criar um asset e vê-lo em jogo.

O pipeline de produção

O pipeline de produção organiza o fluxo de trabalho entre disciplinas, dos assets ao jogo final:

Conceito/GDD → Prototipagem → Arte (2D/3D) → Programação →
Integração de assets → Testes → Otimização → Build final

• Prototipagem: testar a mecânica central rapidamente, com gráficos simples.
• Integração de assets: importar modelos, texturas e sons para o motor.
• Scripts de motor: código próprio do motor que liga a lógica aos objetos da cena.
• Gestão de recursos (assets): organizar pastas, nomear ficheiros, controlar versões.

Um pipeline organizado é o que permite a uma equipa trabalhar em paralelo sem pisar o trabalho uns dos outros.

Animação 2D

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

• 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"

• O frame rate da animação (não confundir com o frame rate do jogo) define a suavidade do movimento.
• Estados de animação (parado, a andar, a saltar) trocam-se consoante o estado do gameplay.

Animação 3D e interativa

Em 3D, a animação usa esqueletos (rigs) com ossos e articulações, e animações programadas que respondem ao gameplay em tempo real:

• Keyframes: poses-chave definidas pelo animador; o motor interpola (calcula) os frames intermédios.
• Blend de animações: transição suave entre duas animações (de andar para correr).
• Máquina de estados de animação: controla que animação toca consoante o estado do personagem.

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

Programar a lógica das animações interativas significa ligar estas transições a eventos reais do jogo (input, colisão, dano).

Física e colisão em ambientes 2D e 3D

Os motores de jogo trazem um motor de física integrado que simula gravidade, forças e colisões sem que o programador tenha de calcular tudo manualmente.

• 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, separada do visual.
• Camadas de colisão: definem que tipos de objetos podem colidir entre si (jogador colide com paredes, não com moedas).

A física bem configurada é o que faz um salto "sentir-se" correto: nem flutuante, nem pesado demais.

Gestão de recursos (assets)

A gestão de 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: evitar perder trabalho quando vários elementos da equipa mexem no mesmo projeto.

Um projeto com assets bem geridos carrega mais rápido e é mais fácil de manter à medida que cresce.

Agentes e comportamentos de IA

A inteligência artificial (IA) em jogos não é a mesma coisa que 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 (behaviour trees): estruturas mais flexíveis para IA complexa, usadas em jogos AAA.
• Perceção: o agente "vê" ou "ouve" o jogador dentro de um raio ou cone definido.

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

Pathfinding

O pathfinding é o cálculo do caminho mais curto (ou mais eficiente) que um agente percorre para chegar a um destino, evitando obstáculos.

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

Exemplo resolvido: quando o pathfinding falha

Um inimigo fica "preso" contra uma parede em vez de contornar um obstáculo. Causa mais provável: a NavMesh não foi recalculada depois de o cenário mudar (uma porta fechada, um objeto colocado).

Solução: marcar o cenário como "estático para navegação" e recalcular a NavMesh sempre que o layout muda.

Sistemas de áudio dinâmico

O áudio dinâmico ajusta a música e os 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/desligam consoante a tensão (exploração vs combate).
• Áudio espacial (3D): o volume e a 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 dos critérios de desempenho explícitos da UC.

Exemplo resolvido: disparar um som por evento

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

• O evento (colisão com a moeda) dispara três coisas em sequência: som, atualização de estado, atualização de interface.
• PlayOneShot permite tocar vários sons curtos sem cortar o som anterior, essencial quando há eventos rápidos e repetidos.

Otimização de código e gestão de memória

Um jogo interativo tem de correr a frame rate estável (normalmente 30 ou 60 frames por segundo). A otimização garante isso mesmo com cenas complexas:

• Object pooling: reutilizar objetos (balas, inimigos) em vez de criar e destruir constantemente, que é uma operação 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 às cegas.

Otimizar sem medir é adivinhar: o profiler diz exatamente onde está o gargalo.

Corrigir bugs de memória e desempenho

A estabilidade de um jogo depende de eliminar falhas antes do lançamento:

• Memory leak (fuga de memória): objetos que deviam ser libertados continuam ocupados, e 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: jogar sessões longas para apanhar quebras que só aparecem ao fim de tempo.

Exemplo resolvido: sintoma de memory leak

O jogo começa fluido e, ao fim de 20 minutos, a frame rate cai gradualmente. Diagnóstico: provável fuga de memória, objetos criados a cada frame (ex.: efeitos de partículas) que nunca são destruídos.

Solução: usar object pooling para os efeitos, em vez de instanciar novos a cada disparo.

Princípios de rendering

O rendering é o processo de transformar a cena 3D (ou 2D) em pixels no ecrã, a cada frame:

• Pipeline de rendering: geometria → texturas e materiais → iluminação → pós-processamento → imagem final.
• Iluminação: em tempo real (dinâmica, cara) ou pré-calculada (baked, mais rápida mas estática).
• Pós-processamento: efeitos aplicados sobre a imagem final (bloom, color grading, anti-aliasing).

O equilíbrio entre qualidade visual e desempenho é uma decisão de design, não só técnica: um jogo lindo que engasga é pior do que um jogo simples que corre bem.

Adaptar a diferentes resoluções e ajustar para publicação

Antes de publicar, o jogo tem de se comportar bem em qualquer ecrã e cumprir os requisitos da plataforma de destino:

• 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ã.
• Build final: compilar o jogo para a plataforma-alvo (Windows, Android, WebGL), com as definições de qualidade adequadas.
• Checklist de publicação: testar em pelo menos duas resoluções, confirmar controlos, rever tamanho do ficheiro final.

Animação em ambientes de RV e RA

A realidade virtual (RV) imerge o jogador num ambiente totalmente digital (headset); a realidade aumentada (RA) sobrepõe elementos digitais ao mundo real (câmara do telemóvel, óculos).

• Em RV, a animação tem de responder ao movimento da cabeça sem atraso (latência), sob pena de causar enjoo.
• 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.
• Ambas exigem frame rate elevado e constante: quebras são muito mais percetíveis do que num jogo de ecrã plano.

A UC exige o uso de equipamentos de RV/RA e de aplicações de desenvolvimento em ambiente virtual 3D como recursos do curso.

Segurança, ambiente e boas práticas finais

• Normas de segurança e saúde no trabalho: pausas regulares ao usar equipamento de RV, ajuste ergonómico do posto de trabalho.
• Normas de proteção ambiental: gestão responsável de equipamento eletrónico em fim de vida.
• Do design ao lançamento: GDD → prototipagem → programação → arte e animação → IA e áudio → otimização → build final.
• Atitudes da UC: responsabilidade, autonomia, empenho, iniciativa, flexibilidade, sentido criativo, organização, rigor, cooperação.

Um jogo interativo profissional não é só código: é design, arte, som e engenharia a funcionar em conjunto, com rigor do princípio ao fim.