🎮 Jogos Digitais II

Em Jogos I vocês montaram um personagem e o fizeram andar. Este semestre a pergunta muda: o que separa aquilo de um jogo que alguém baixa, joga até o fim e recomenda?

Curso

Engenharia de Software

Carga Horária

80 horas

Engine

Godot

Encontros

Quartas-feiras

1. Como a disciplina funciona

O semestre inteiro constrói um único jogo, individual. Cada aula acrescenta uma camada ao mesmo projeto: personagem, arena, física, inimigo com inteligência artificial, otimização, exportação. No fim, você tem um jogo que roda fora do editor e uma página de divulgação — não treze demonstrações soltas que ninguém volta a abrir.

O incremento acontece em sala, com roteiro. Não é trabalho para fazer em casa no fim de semana: é construção acompanhada, aula após aula, num repositório Git seu. Começa hoje.

Ementa

1 · Game Engines

O que é uma engine; framework contra engine; anatomia de uma engine.

2 · Godot Engine

Cenas e nodes; GDScript; física avançada.

3 · Recursos avançados

Culling e níveis de detalhe; inteligência artificial com pathfinding e comportamentos.

4 · Mercado

Ciclo de vida do jogo, do protótipo ao lançamento; Steam e redes sociais.

Avaliação

MB1 = P1 + MT1

MB2 = P2 + MT2

MF = (MB1 + MB2) ÷ 2

A prova do bimestre vale até 5,0 e cobre o conteúdo ministrado até ali. A média dos trabalhos vale os outros 5,0. Frequência mínima de 75%.

Metade da nota vem de entrega, não de prova. Numa disciplina prática isso é coerente: o que se avalia é jogo funcionando, aula após aula. Os quizzes de fechamento não valem nota, mas contam na pontuação de participação e alimentam o ranking da turma.

Datas

Data	O que acontece
12/08	Início das aulas
16/09	P1 — prova do 1º bimestre
14/10	Semana do saco cheio — sem aula
21/10	Entrega do T2: inimigo com IA e navegação
11/11	Entrega do T3: build exportada e página publicada
18/11	Entrega final e apresentação dos projetos
25/11	P2 — prova do 2º bimestre, último encontro

2. O problema que a engine resolve

Antes de definir o que é uma game engine, vale responder outra pergunta: o que seria preciso escrever, do zero, para colocar um quadrado andando na tela?

Parece pouco. Não é. Sem nenhuma ferramenta pronta, essa é a lista mínima:

Janela e contexto gráfico

Abrir uma janela do sistema operacional e conseguir desenhar dentro dela.

Laço de jogo

Repetir processar entrada, atualizar estado e desenhar, controlando quanto tempo passou entre um quadro e outro.

Carregar imagem e som

Decodificar PNG, OGG, WAV e transformar em algo que a placa de vídeo entenda.

Desenhar na ordem certa

Respeitar profundidade, transparência e câmera sem redesenhar o mundo inteiro à toa.

Ler teclado, mouse e controle

E mapear isso para ações do jogo, não para teclas fixas no código.

Detectar colisão

Descobrir que duas formas se tocaram — e fazer isso rápido com centenas de objetos.

Tocar áudio sem travar

Som e música em paralelo com o jogo, sem engasgar a imagem.

Gerar o executável

Empacotar código, imagens e sons num arquivo que roda na máquina de outra pessoa.

Nada nessa lista é sobre o seu jogo. É infraestrutura — a mesma para um jogo de plataforma, um RPG ou um simulador de fazenda. Uma game engine é esse conjunto já resolvido, com um editor visual por cima.

Ideia central

A engine não faz o jogo. Ela remove o que todo jogo precisa e ninguém quer escrever duas vezes, para que o tempo sobre para o que é específico do seu.

3. Framework e engine não são a mesma coisa

Muita gente usa os dois termos como sinônimos. A diferença é de escopo, e ela aparece na hora de trabalhar.

	Framework (Pygame)	Engine (Godot, Unity, Unreal)
O que entrega	bibliotecas: gráficos, som, entrada	tudo isso mais editor, física, animação e exportação
Como se monta a cena	por código, posicionando tudo à mão	visualmente, arrastando objetos
Laço de jogo	você escreve	já existe
Importar assets	você carrega e converte	pipeline pronto
Exportar para outra plataforma	por sua conta	um botão
Controle sobre o que acontece	total	vai até onde a engine permite

Framework não é a opção inferior

Dá para fazer jogo comercial com Pygame, e existem jogos famosos escritos sem engine nenhuma. A escolha é entre quanto você constrói antes de começar a fazer o jogo e quanto controle abre mão. Em prazo de semestre, com equipe pequena, a engine ganha. Numa pesquisa sobre renderização, talvez não.

4. Anatomia de uma engine

Toda engine, independentemente do nome, é composta pelas mesmas peças. Reconhecê-las ajuda a aprender qualquer outra depois desta.

Editor de cenas

Onde o mundo do jogo é montado visualmente. É a peça que mais diferencia uma engine de um framework.

Sistema de arquivos do projeto

Como o projeto se organiza em disco e como a engine encontra cada recurso.

Pipeline de importação de assets

Converte PNG, OGG e modelos 3D para os formatos que o jogo usa em execução. É por isso que arrastar uma imagem para a engine simplesmente funciona.

Motor de renderização

Decide o que aparece na tela, em que ordem, e conversa com a placa de vídeo.

Motor de física

Gravidade, colisão, atrito e forças. Tema das aulas 04 e 06.

Exportador

Empacota o projeto para Windows, Linux, Android, navegador ou console. Tema da aula 12.

5. Três engines e a escolha desta disciplina

	Godot	Unity	Unreal
Licença	MIT, código aberto	proprietária, com planos	proprietária, com royalties
Custo	nenhum	gratuito até certo faturamento	royalty acima de um limite de receita
Linguagens	GDScript, C#, C++	C#	C++ e Blueprints
Tamanho da instalação	algo em torno de 100 MB	vários gigabytes	dezenas de gigabytes
Onde se destaca	2D, times pequenos, prototipagem rápida	mobile, ecossistema e loja de assets	3D de alta fidelidade

A licença é uma decisão de arquitetura

Em 2023 a Unity anunciou uma cobrança por instalação que afetaria inclusive jogos já publicados. A reação da comunidade foi intensa e a política acabou revertida, mas o episódio deixou uma lição que vale além daquele caso: a licença da ferramenta é uma decisão de projeto com risco associado, do mesmo tipo que escolher um banco de dados ou um provedor de nuvem.

Isso não faz da Unity uma escolha ruim. Faz da avaliação de licença parte do trabalho de engenharia, e não detalhe jurídico para depois.

Por que Godot aqui

É a engine indicada no plano de ensino. Além disso: roda sem instalar, cabe num pendrive, não pede conta nem licença, o projeto abre igual no laboratório e na casa de vocês, e a licença MIT significa que nada do que produzirem fica preso à ferramenta. Para uma disciplina de um semestre, essas são vantagens concretas.

Sobre a pergunta que sempre aparece — dá para fazer jogo de verdade com Godot? Brotato, Dome Keeper, Cassette Beasts e Halls of Torment são comerciais, foram feitos nela e vendem bem.

6. Prática: primeiro projeto

Ao final desta aula todos precisam ter a Godot rodando e um projeto criado. Se algo travar, resolva agora — a Aula 02 começa de dentro do editor.

Baixe a Godot em godotengine.org, versão standard, e descompacte. Não há instalador: o arquivo baixado já é a engine.
Crie um projeto novo em pasta vazia, com o renderizador Compatibility. O nome é o do seu jogo — pode mudar depois.
Reconheça os painéis: Cena, Sistema de Arquivos, viewport, Inspetor e Saída. Deixe o painel Saída aberto — é onde os erros aparecem.
Crie uma Cena 2D, renomeie a raiz para Principal e salve como principal.tscn.
Arraste o icon.svg do projeto para o viewport e rode a cena com F6. Esse é seu personagem por enquanto.
Crie o repositório no GitHub, faça o primeiro commit e marque com a tag aula-01. Os comandos estão na seção 7.

F6 roda a cena aberta; F5 roda o projeto e pede uma cena principal. Confundir os dois é o tropeço mais comum do primeiro dia.

Fixe a versão

Anote a versão da Godot que você baixou e use a mesma o semestre inteiro. Código de Godot 3.x não roda na 4.x — nomes de classe e assinaturas mudaram. Boa parte dos tutoriais que você vai encontrar na internet é da versão antiga, e o erro que isso gera não é óbvio.

7. Seu jogo começa hoje

O projeto é individual e cresce a cada aula. O gênero é o mesmo para todos — uma arena de sobrevivência vista de cima, com inimigos chegando em ondas. O que muda de aluno para aluno é a carta sorteada hoje.

A carta

Quatro atributos sorteados definem o seu jogo. São mais de mil combinações possíveis, e a sua é registrada no README do seu repositório:

Ambientação

Estação espacial, masmorra, cidade submersa, laboratório, deserto, floresta, fábrica ou navio fantasma. Define arte e clima.

Mecânica-assinatura

Arrancada, impulso de parede, guarda, tempo lento, troca de lugar, onda de choque, torreta ou contragolpe. É o que torna o jogo reconhecível.

Inimigo principal

Perseguidor, atirador, emboscador, enxame, ronda ou divisor. Define o desafio.

Restrição

Quatro cores, uma tela só, não pode parar de andar, sem interface, partida de 3 minutos ou um botão apenas.

Restrição não é castigo

Restrição estreita o espaço de decisão e obriga a escolher com critério. É assim que game jam funciona, e é o que separa “fiz o que o tutorial mandou” de “resolvi um problema”. A sua restrição é o que vai deixar o seu jogo interessante.

As oito mecânicas foram calibradas para dar o mesmo trabalho: todas cabem em torno de 20 a 35 linhas e usam só o que teremos visto até a Aula 07. Nenhuma carta é mais difícil que a outra — o que muda é o jogo que sai dela. Para quem terminar antes, cada mecânica tem uma extensão opcional, que não vale nota.

Um commit por aula, com tag

Toda aula termina com um commit e uma tag no seu repositório. É assim que o professor acompanha a construção — e é assim que você prova que o jogo é seu.

git add .

git commit -m "aula-01: projeto criado e personagem na tela"

git tag aula-01

git push origin main --tags

Além do código, mantenha um DEVLOG.md com três a cinco linhas por aula: o que você fez, o que travou e como resolveu. É rápido de escrever e é o que mais ajuda quando você voltar ao projeto depois de duas semanas.

Sobre cópia e uso de IA

Consultar documentação, tutorial, fórum e assistente de IA é permitido e esperado — é assim que se programa hoje. O que não é permitido é entregar como seu um código que você não sabe explicar.

Na apresentação final você vai responder perguntas sobre qualquer trecho do seu projeto. Se o código estiver lá e você não souber dizer o que ele faz, a nota é a mesma de não ter entregado.

Cite a origem. Trecho vindo de tutorial, documentação ou IA: um comentário de uma linha dizendo de onde veio. Isso não tira ponto — omitir, sim.

Cópia entre colegas zera o trabalho dos dois envolvidos, com ou sem consentimento de quem escreveu.

8. Para a próxima aula

Sem entrega. Traga pronto:

Godot instalada e o projeto do semestre criado.
Tutorial oficial “Your first 2D game” feito, em docs.godotengine.org, com o resultado rodando.
Leitura: Capítulo 1 de Rabin, v. 1.

Depois de terminar o tutorial, refaça sem olhar. Onde travar é o que ainda não entendeu — e é o que vale perguntar na aula.

9. Referências

📚 Estudo desta aula

DOS SANTOS, Marcelo Henrique. Fundamentos de jogos digitais: game design, game engine e level design. São Paulo: Saraiva, 2021.
RABIN, Steve. Introdução ao Desenvolvimento de Games, v. 1 — Entendendo o universo dos jogos. São Paulo: Cengage Learning, 2012. Capítulo 1.
GODOT ENGINE. Documentação oficial. docs.godotengine.org (disponível em português).

📖 Leitura complementar

ARRUDA, Eucidio P. Fundamentos para o desenvolvimento de jogos digitais. Porto Alegre: Grupo A, 2014.
NOVAK, Jeannie. Desenvolvimento de games. 2. ed. São Paulo: Cengage Learning, 2017.
CHANDLER, Heather M. Manual de produção de jogos digitais. 2. ed. Porto Alegre: Bookman, 2012.

A documentação da Godot é a fonte técnica principal da disciplina. Prefira sempre ela a tutoriais avulsos: a engine mudou bastante da versão 3 para a 4, e há muito material desatualizado circulando.

Meus Conteúdos

Aula 01 — Apresentação, mercado e o que é uma Game Engine