Treinamento

O treinamento é um projeto recorrente do USPGameDev para ajudar quem não tem experiência em fazer jogos a fazer seu primeiro jogo do começo ao fim. O projeto é tipicamente sugerido para quem acabou de entrar no grupo embora não seja obrigatório de forma alguma. O USPGameDev costuma oferecer o treinamento todo semestre mas a demanda é normalmente maior nos semestres ímpares dado o início do ano letivo na USP e, em especial, a chegada de ingressantes.

O projeto de treinamento na verdade consiste de vários mini-projetos em grupos de mais ou menos 2 a 4 pessoas. Idealmente, cada grupo tem um tutor que os ajuda a escolher que jogo fazer e ensina o que for necessário. Quando não há tutores o suficiente, normalmente fazemos aulas conjuntas para os participantes em paralelo com os projetos.

Edições de Treinamento

Só começamos a registrar as edições de projetos de treinamento de 2021 em diante.

• Treinamento Conjunto (2021.1)

Duração e Entrega

O tempo aproximado para cada projeto de treinamento é de dois meses. É aproximado porque, na verdade, a entrega ocorre sempre em uma Reunião de Integração longa. Como essas reuniões são quinzenais, o treinamento dura mais ou menos um ciclo de quatro reuniões. Na reunião de entrega, os participantes do projeto apresentaram o que conseguiram desenvolver junto com o resto do USPGameDev, como uma forma de demonstrar sua participação concretizada no grupo.

Projetos possíveis

Como a ideia do treinamento é dar a experiência de fazer um jogo inteiro do começo a fim, os mini-projetos devem envolver jogos extremamente simples. Nossa sugestão é reproduzir um jogo clássico de arcade ou similar. Pequenos alterações e adaptações são perfeitamente possíveis mas o recomendado é deixar elas para depois que o "jogo base" estiver completo e funcional. É muito importante levar a sério as indicações aqui, pois o erro mais comum no desenvolvimento de jogos é errar o escopo e o treinamento perde todo o seu propósito se o participante não conseguir fazer o jogo até o fim.

Dito isso, aqui vão algumas sugestões de jogos para o treinamento. Essa lista é constantemente revisada e aceitamos sugestões!

• Asteroids
• Pong
• Space Invaders
• Snake
• Brick Breaker / Arkanoid
• Missile Command
• BBTAN
• Pac-man
• Bejeweled / Match-3
• Sokoban
• Jogos de tabuleiro clássicos (xadrez, damas, othello, backgamon, etc.)
• Tron
• Bomberman
• Scorched Earth / Worms / Gorillas / Angry Birds-ish
• Mais ideias

Notem a ausência de platformers. Platformers são difíceis.

Tópicos importantes

Para se fazer um jogo há alguns conceitos e ferramentas que todo mundo precisa dominar, independente da especialidade. Aqui deixamos uma referência rápida e focada nos tópicos que achamos importante incluir em toda edição de treinamento. Vale lembrar que temos uma página de Referências muito mais completa e abrangente também. Além disso, é importante ressaltar que os tópicos aqui estão levemente viesado para o uso de Git, Godot e ferramentas open source de maneira geral.

Introdução à Godot

Tem bastante material na Internet e a comunidade é bastante receptiva a dúvidas. Além disso, vocês sempre podem perguntar para veteranes do UGD! Dito isso, aqui vão algumas referências:

Tutoriais

Para quem gosta de aprender por conta própria, recomendamos os seguintes materiais:

• Guia oficial (versão em português)
• Canal do GDQuest (inglês)
• Noções básicas de Godot (português)

Organização de Projeto

Jogos são criações multidisciplinares e errar o escopo é a falha mais comum da indústria. Saber se organizar e reconhecer as limitações do time é um requisito fundamental para conseguir terminar um jogo dentro de um limite de tempo (e recursos, no caso de projetos comerciais).

Conheça os papéis de cada um

The Door Problem. Principalmente, saiba identificar se seu time não tem como cumprir certo papel e tenha alguma certeza de quem vai cuidar de cada parte.

Saiba fazer controle de versão dos arquivos do projeto

Git Básico

Usando GitLab com GitKraken. Porque manter os arquivos de um projeto sincronizado entre várias pessoas é o mínimo do mínimo para se garantir a integridade de um sistema e Git é o maior (e possivelmente o melhor) padrão na academia E na indústria.

Saiba o que priorizar em um projeto

Isso é algo que desenvolvemos com experiência mas algumas dicas genéricas a se considerar são:

• Ter um jogo jogável é mais importante do que ter as features completas
• Comece pelas features mais essenciais e difíceis (e desista/mude elas o quanto antes se for o caso)
• Sempre que achar um bug ou possível melhoria, ANOTE IMEDIATAMENTE mas não necessariamente resolva agora
  • Se você usa Issues de Git ou Trello para se planejar, abra uma issue ou cartão novo

Assets, Licenças e Ferramentas Recomendadas

Assets são os diversos arquivos de mídia que o jogo usa para rodar, como imagens, texturas, modelos 3D, músicas, efeitos sonoros, dentre muitos, muitos outros. Eles podem tanto ser produzidos pelos diversos tipos de artistas que uma equipe pode ter quanto serem licenciados por terceiros. De um jeito ou de outro, é fundamental entender como licenças se aplicam a assets.

Todos os jogos produzidos como parte das atividades do USPGameDev são código aberto ou possuem uma licença aberta equivalente - isso vale também para os assets que vocês fizerem e distribuírem com o jogo.

Saiba quais licenças permitem o uso de assets feitos por terceiros

Creative Commons (as mais comuns, incluindo CC0 / Public Domain)

Open Font License (sim, fontes têm licenças!)

Ferramentas recomendadas (porque são software livre e es veteranes saberão ajudar)

Audacity (edição de áudio)

Krita (desenho)

Tiled (edição de fases 2D)

Pixelorama (desenho pixel art)

Piskel (desenho pixel art)

Inkscape (desenho vetoial)

Blender (modelagem e animação 3D)

MagicaVoxel (modelagem 3D por voxels)

Assets on-line com licenças abertas

Open Game Art (assets de todos os tipos)

FreeSound (efeitos sonoros)

Kenney (sprites e modelos de domínio público)

Game Icons (ícones)

Google Fonts (muitas fontes, mas certifiquem-se da licença!)

Princípios de Game Design

Todo mundo que põe a mão no jogo está contribuindo para o design (projeto) dele. Logo, todos são responsáveis e deveriam saber pelo menos o básico.

Gameplay

Framework MDA. Um modelo teórico que tenta esclarecer a relação causal entre as mecânicas de um jogo e a experiência que elas geram nos jogadores.

Interface

Design for Subway Legibility. Introdução bem básica a hierarquia da informação e como fazer interfaces mais claras.

Juiciness

Juice it or lose it. É isso que faz a diferença entre um jogo parecer profissional ou não.

Playtest

Capítulo 28, "Good Games Are Created Through Playtesting", do livro The Art of Game Design por Jesse Schell. No final das contas, avaliar um jogo é inerentemente subjetivo e o único jeito garantido de saber se está do jeito que queremos é colocar alguém pra jogar e ver o que acontece.