Bloco 1 · O que torna algo um jogo

Definição prática

Um jogo é um sistema onde o jogador toma decisões significativas com regras claras, persegue um objectivo e recebe feedback imediato.

4 ingredientes: decisões, regras, objectivo, feedback.

Faltar qualquer um → não é jogo.

• Sem objectivo → brinquedo (Minecraft Creative é exceção: o jogador inventa objectivos).
• Sem decisões → animação interactiva.
• Sem feedback → sistema burocrático.
• Sem regras → sandbox descontrolada.

Jogador "core loop": MDA

Modelo MDA (Mechanics, Dynamics, Aesthetics):

• Mechanics — regras e ações concretas (saltar, atirar, virar carta).
• Dynamics — comportamentos emergentes quando os jogadores usam as mecânicas.
• Aesthetics — emoções/sentidos que o jogador experiencia (desafio, descoberta, expressão...).

Designer projecta mecânicas; jogadores vivem aesthetics.

Bloco 2 · Géneros e mecânicas

Géneros principais

• Plataformas (Mario, Celeste) — pular, evitar.
• Puzzle (Tetris, Portal) — resolver.
• Acção (shooter, beat'em up) — reflexos.
• Aventura / RPG — narrativa, progressão.
• Estratégia — recursos, decisão pensada.
• Casual / hyper-casual — 1 input, sessões curtas.
• Idle / clicker — automatização e progresso.

Para a primeira fase: puzzle, plataformas 2D simples, ou clicker.

Verbo do jogador

Cada jogo bom resume-se a um verbo principal:

• Mario → saltar
• Tetris → encaixar
• Portal → teletransportar
• Pong → rebater
• Cookie Clicker → clicar

Pergunta: qual é o verbo do teu jogo? Se for "fazer várias coisas", o jogador não vai entender o que está a fazer.

Game feel — o invisível

"Game feel" = a sensação táctil de jogar. Faz a diferença entre Mario e um clone tosco.

• Resposta imediata ao input (lag baixo).
• Aceleração/desaceleração subtis (não é botão = vai a 100).
• Squash & stretch ao aterrar.
• Screen shake controlado em colisões.
• Sons sincronizados com cada ação.
• Partículas para feedback.

80% do tempo de polimento vai para isto.

Bloco 3 · Loop de jogo

O coração técnico

Quase todo o jogo segue este loop:

while (jogo a correr):
    1. Ler INPUT       (teclado, rato, gamepad)
    2. UPDATE estado   (física, IA, regras)
    3. RENDER ecrã     (sprites, UI)
    4. Esperar próximo frame

Tipicamente 60 vezes por segundo (60 FPS) = 16.6 ms por frame.

Estados do jogo (state machine)

[Menu] → [Jogar] → [Pausa]
            ↓ 
        [Game over] → [Menu]

Cada estado sabe responder a inputs próprios e a transição entre estados é explícita. Sem isto, o jogo fica num "espaguete" de variáveis.

Tempo: delta time

Não assumas que cada frame demora 16 ms. Multiplica por delta time (tempo desde o último frame):

// mau (depende do FPS)
posicaoX += 5;

// bom (independente do FPS)
posicaoX += velocidade * dt;

Sem dt: jogo vai a velocidades diferentes em PCs diferentes.

Bloco 4 · Sprites, sons, física

Sprites

• PNG transparente ou sprite sheet (várias frames numa imagem).
• Pixel art → desligar interpolação (pixelated); usar múltiplos de 16/32 px.
• Anchor point (origem) decide rotação/escala — colocar no centro ou nos pés.

Ferramentas: Aseprite (pixel art), Krita, Photoshop, Figma para HUD.

Animação por frames

Tens 4 frames de uma personagem a andar → mostras em ciclo a 8-12 fps:

walk_01.png → walk_02.png → walk_03.png → walk_04.png → walk_01.png...

Animação curta (idle, walk, jump, hurt, die) costuma chegar. Mais que isso é tempo perdido em iteração 1.

Som

• Música — loop de 30-60s, MP3/OGG, baixo volume.
• SFX — saltar, colisão, moeda, dano. WAV/OGG curtos.
• Bibliotecas grátis: freesound.org, opengameart.org, kenney.nl.
• Gerar SFX rápido: bfxr.net, sfxr.me.

Sem som = jogo sente-se "morto". Mesmo SFX simples mudam tudo.

Física (2D)

Duas abordagens:

• Manual — calcular posição, velocidade, gravidade tu mesmo. Bom para arcade.
• Engine de física — Box2D/Chipmunk (Godot e Construct trazem). Bom para colisões realistas.

Conceitos:

• Hitbox (colisão) ≠ sprite (visual).
• Velocidade vs aceleração.
• Gravidade (constante adicionada ao Y por frame).
• Saltar = aplicar velocidade negativa quando no chão.

Colisões

• AABB (caixas alinhadas) — rápido, suficiente para 90% dos casos.
• Circle vs circle — distância < soma de raios.
• Layers/masks — bala não colide com bala; jogador colide com inimigo e chão.

Quando 2 objectos colidem: resolver (separar) e reagir (perder vida, abrir porta, etc.).

Bloco 5 · Ferramentas

Escolher ferramenta

Para iniciantes: Construct (sem código) ou Godot (com pouco código).

Godot 4 — exemplo plataforma

extends CharacterBody2D

const SPEED = 200.0
const JUMP = -400.0

func _physics_process(delta):
    # gravidade
    if not is_on_floor():
        velocity.y += 980 * delta
    # input horizontal
    velocity.x = Input.get_axis("left", "right") * SPEED
    # saltar
    if Input.is_action_just_pressed("jump") and is_on_floor():
        velocity.y = JUMP
    move_and_slide()

20 linhas → personagem que se move e salta.

p5.js — exemplo Pong

let paddleY = 200, ballX = 200, ballY = 200;
let bx = 3, by = 3;

function setup() { createCanvas(400, 400); }

function draw() {
  background(0);
  // input
  if (keyIsDown(UP_ARROW))   paddleY -= 5;
  if (keyIsDown(DOWN_ARROW)) paddleY += 5;
  // update bola
  ballX += bx; ballY += by;
  if (ballY < 0 || ballY > height) by *= -1;
  // colisão paddle
  if (ballX < 30 && ballY > paddleY && ballY < paddleY+60) bx *= -1;
  // render
  fill(255);
  rect(20, paddleY, 10, 60);
  ellipse(ballX, ballY, 15);
}

Bloco 6 · Polimento e publicação

Playtesting

A única maneira de saber se o jogo funciona é pôr outras pessoas a jogar.

• Não expliques antes — vê se entendem só pelo jogo.
• Observa as caras e mãos, não só o ecrã.
• Pergunta no fim: "o que querias fazer e não conseguiste?"
• Iteração curta: 1-2 sessões por semana.

80% das suposições "óbvias" do designer revelam-se erradas no primeiro playtest.

Onboarding

Os primeiros 30 segundos decidem se o jogador continua.

• 1 mecânica de cada vez introduzida.
• Aprender a fazer, não ler tutoriais longos.
• Falhar é OK — checkpoint frequente, dano leve.
• Recompensar cedo (1ª moeda em 10 segundos).

Mau onboarding = jogo abandonado mesmo que seja bom.

Dificuldade e flow

Flow = zona entre aborrecimento (fácil demais) e frustração (difícil demais).

• Dificuldade cresce gradualmente.
• Picos controlados (boss) com recuperação (zona segura depois).
• Variar mecânica (não 50 níveis iguais).
• Skip ou ajuste em jogos com público amplo.

Acessibilidade em jogos

• Remapeamento de controlos.
• Sem flashes ofensivos; aviso de epilepsia.
• Legendas em diálogos + indicação de quem fala.
• Modo daltonismo (cores configuráveis).
• Sons importantes têm pista visual alternativa.
• Dificuldade ajustável.

Inspiração: Celeste, The Last of Us Part II (referência de a11y em jogos).

Publicação

• HTML5 → itch.io (grátis, comunidade enorme), Newgrounds, próprio site.
• PC (Windows/Mac/Linux) → Steam (custos), itch.io, GOG.
• Mobile → App Store / Google Play (≈ 99-100 € / ano + revenue share).
• Web nativo → Construct exporta direto; Godot via HTML5; p5.js já é web.

Para escola: itch.io + página HTML5 chega.