Ficha 02 · Implementação, sprites, polimento, publicação · Ficha de trabalho

Aluno(a)

Turma

Nº

Data

Objectivos da ficha

Sprites/anim
Física 2D
Ferramenta certa
Playtest
Publicar

Parte I · Sprites e animação

Exercício 1 · Sprite sheet (10 pts)

O que é uma sprite sheet e quais 2 vantagens face a ter 1 PNG por frame?

Sprite sheet = uma única imagem que contém várias frames organizadas em grelha. O motor lê coordenadas (x, y, w, h) para mostrar a frame certa.

Vantagens: 1. Performance — menos chamadas ao disco/GPU; 1 textura carregada vs 20. 2. Organização — animações inteiras num só ficheiro; mais fácil exportar/manter.

(Também: facilita usar packers como TexturePacker para optimizar espaço.)

Exercício 2 · Pixel art (10 pts)

Tens um sprite 32×32 pixel art. Que 3 cuidados ter no motor (Godot/Unity) para ele aparecer bem?

Desligar interpolação (filtro Nearest em vez de Linear) — sem isto, o pixel art parece desfocado ao escalar.
Escalar por múltiplos inteiros (×2, ×3, ×4) — escalar por 1.5× cria distorção.
Snap a píxeis (pixel snap) na câmara e no movimento — evita "tremedeira" sub-pixel.

Bónus: 4) Definir paleta de cores consistente entre sprites.

Exercício 3 · Frames de andar (10 pts)

Tens 4 frames de uma personagem a andar. A que FPS vais reproduzir e porquê? E se duplicasses para 8 frames?

Com 4 frames: cerca de 8-10 fps (não 60). Mais lento = mais legível e estilo "clássico"; muito mais e parece tremer.

Com 8 frames: pode subir para 12-16 fps; ciclo mais suave, mais "vivo". Tipicamente 8 frames a 12 fps é um sweet spot.

Regra: ajusta empiricamente — repete a animação no jogo e vê se "sente" certo à velocidade de andar do personagem.

Parte II · Física

Exercício 4 · Boas práticas de salto (15 pts)

Indica 3 truques que melhoram a sensação do salto num platformer, e explica brevemente o que cada um resolve.

Coyote time (~0.1s) — permite saltar 0.1s depois de sair da plataforma. Resolve a sensação de "saí da plataforma e nem cheguei a saltar"; alivia precisão exigida.
Jump buffer (~0.1s) — se carregaste no botão antes de aterrar, salta no instante de aterragem. Resolve "carreguei demasiado cedo, jogo não respondeu".
Salto variável — soltar o botão antes interrompe o salto; manter, vai mais alto. Resolve "todos os saltos têm a mesma altura, jogo robótico".

Bónus: 4) Aceleração horizontal suave em vez de "ligar/desligar" velocidade. 5) Squash & stretch ao saltar/aterrar.

Exercício 5 · Colisão AABB (10 pts)

Tens 2 rectângulos A e B com x, y, w, h. Escreve em pseudocódigo a função colide(a, b) que devolve true se se sobrepõem.

function colide(a, b) {
  return a.x < b.x + b.w &&
         a.x + a.w > b.x &&
         a.y < b.y + b.h &&
         a.y + a.h > b.y;
}

Os 4 lados têm de falhar estarem separados. Suficiente para 90% dos casos em jogos 2D. (Pixel-perfect só quando muito necessário, é mais caro.)

Parte III · Ferramentas

Exercício 6 · Escolher engine (10 pts)

Para cada cenário, escolhe a engine adequada e justifica em 1 linha:

a) Aluno sem programação quer fazer um jogo para a aula em 2 semanas. ___

b) Jogo 2D plataformas com física, exportar para web e desktop. ___

c) Esboço rápido de uma mecânica num browser para mostrar a um colega. ___

a) Construct 3 — visual blocks, sem código, web-based, exporta HTML5. b) Godot 4 — open source, leve, GDScript simples, exporta web + desktop. c) p5.js — JavaScript directo no browser, prototipagem em minutos (CodePen/editor.p5js.org).

Exercício 7 · GDScript (15 pts)

Lê este código Godot e responde:

extends CharacterBody2D
const SPEED = 200.0
const JUMP = -400.0

func _physics_process(delta):
    if not is_on_floor():
        velocity.y += 980 * delta
    velocity.x = Input.get_axis("ui_left", "ui_right") * SPEED
    if Input.is_action_just_pressed("ui_accept") and is_on_floor():
        velocity.y = JUMP
    move_and_slide()

a) Quanto vale a "gravidade" por segundo?

b) Por que é que velocity.y += 980 * delta está dentro de if not is_on_floor()?

c) Que comportamento esperar se o jogador mantiver ui_accept premido no ar?

a) 980 px/s² — multiplica por delta (segundos) para somar à velocidade. Em 1 segundo, a velocidade vertical aumenta 980 px/s se nada o impedir.

b) Quando está no chão, não queremos somar gravidade (ficaria a "afundar" no chão). Só aplicamos gravidade quando está no ar.

c) Nada — o salto está em is_action_just_pressed (só dispara uma vez ao premir, não enquanto está premido). Tem de soltar e voltar a carregar.

Parte IV · Playtest e publicação

Exercício 8 · Plano de playtest (10 pts)

O teu jogo está num estado alpha (jogável mas com bugs). Indica 4 regras para uma boa sessão de playtest.

Não expliques antes — vê se o jogo se ensina sozinho.
Observa cara e mãos, não só o ecrã (frustração, hesitação).
Pergunta não-leading ("o que querias fazer agora?" em vez de "viste o botão de saltar?").
Notas durante, não depois — memória é traiçoeira.

Bónus: 5) Gravar com permissão. 6) Mínimo 3 pessoas com perfis diferentes. 7) Iterar entre sessões (não juntar 10 testers e depois mudar tudo de uma vez).

Exercício 9 · Onde publicar (10 pts)

Acabaste um jogo HTML5 e queres publicá-lo. Indica 2 plataformas apropriadas e 1 que não faz sentido para um primeiro jogo de aluno, com justificação.

Apropriadas: - itch.io — grátis, comunidade indie enorme, suporta HTML5 directo, página personalizável, game jams. - Site próprio (Vercel/Netlify) — controle total, ligado ao portfolio.

Não recomendado: - Steam — 100 USD por jogo, processo de submissão exigente, mercado PC competitivo. Faz sentido para um produto polido com público; um primeiro jogo de aluno fica perdido. - (Também desnecessário 1ª vez: App Store / Google Play com taxa anual + revenue share.)