Como Programar Jogos · Game Developer

SDL3 com Visual Studio, git submodule, e GitHub Workflow

Sun, 13 Jul 2025 00:00:00 +0000

Após minha graduação em Ciência da Computação, iniciei uma pós-graduação em Produção e Programação de Jogos com o objetivo de mudar minha carreira e entrar na indústria de jogos. Isso foi em 2009, e uma das primeiras ferramentas de desenvolvimento de jogos que tive contato foi o SDL2, onde fiz o meu primeiro projeto de game com SDL e C++ em uma disciplina da pós-graduação. De lá pra cá utilizei o SDL em diversos projetos, principalmente game jams e para aprender a programar homebrew para Nintendo DS e PSP, e sempre foi um framework fácil de usar e bem completo para jogos 2D.

Criar um projeto novo utilizando Visual Studio e configurar o SDL2 era um pouco mais trabalhoso, e inclusive escrevi este tutorial pra mim mesmo por que eu sempre esquecia de algum passo. Alguns meses atrás, o SDL3 foi oficialmente lançado, e trouxe algumas mudanças para simplificar o desenvolvimento de jogos e sua configuração. Neste post vou mostrar como criar um projeto novo no Visual Studio, adicionar o SDL3 como uma dependência usando git submodule, configurar o projeto para compilar um Hello World, e como automatizar builds em cada commit utilizando GitHub Workflows.

SDL como dependência usando git submodule
#

A parte mais importante de todo este post é este primeiro passo, pois aqui vamos configurar o projeto como um repositório git e adicionar o SDL3 como um submodule. Existem diversos conteúdos muito bons sobre git, então não vou alongar muito com uma introdução, e vamos direto ao ponto. Caso não tenha git na sua máquina, você pode instalar aqui.

Primeiro, precisamos criar um repositório local. Os comandos abaixo são os mesmos em qualquer sistema operacional, mas como vamos utilizar o Visual Studio neste tutorial, pode assumir que estou utilizando Windows. Criei um novo diretório no seu computador com o nome HelloWorldSDL3. Após criar o diretório, abra o prompt de comandos do Windows (cmd ou power shell), nave até a nova pasta criada e, dentro dela, execute o comando abaixo:

git init

Este commando vai criar uma pasta invisível chamada .git. Caso algum erro aconteça, como comando não encontrado, certifique-se que o git foi instalado e está adicionado no path do Windows. Em seguida, vamos adicionar o repositório do SDL como um submodule usando os comandos abaixo:

git submodule add https://github.com/libsdl-org/SDL.git SDL

Este comando vai adicionar um arquivo .gitmodules com uma referência do SDL no repositório local, e baixar o projeto em uma pasta chamada SDL. Se tudo der certo, seu diretório deverá estar com esta estrutura abaixo:

HelloWorldSDL3/
├── .git/
├── SDL/
└── .gitmodules

Neste momento você pode criar um repositório no GitHub (necessário criar uma conta gratuita se não tiver). No meu exemplo abaixo, estou criando um repositório público com o nome hello-world-sdl, e não selecionei nenhuma opção para inicializar o repositório com algum arquivo.

Depois de criar o repositório, volte para o prompt de comandos e digite os seguintes comandos (substitua USERNAME pelo seu usuário no github):

git add .
git commit -m "SDL submodule"
git branch -M main
git remote add origin https://github.com/USERNAME/hello-world-sdl.git
git push -u origin main

E, após executar os comandos acima com sucesso, o seu repositório estará parecido com o meu na imagem abaixo:

Isso é tudo que precisamos por agora, mas vamos voltar ao github no final deste post para configurar a automação de compilação no GitHub Workflow.

Criação de um projeto no Visual Studio
#

O SDL3 tem uma documentação bem simples e fácil de seguir. A configuração do projeto no Visual Studio pode ser vista aqui, porém vou adicionar os passos em português abaixo com algumas modificações que fiz.

A principal diferença é que, ao invés de fazer o download do código fonte, nós vamos usar o submodule que configuramos no passo anterior em nosso repositório git.

Novo projeto no Visual Studio
#

O Visual Studio 2022 (ou mais novo) pode ser baixado aqui, e a versão Community é gratuita para desenvolvedores solo, uso acadêmico, ou projetos open source. Siga os passos do instalador e lembre de marcar as opções para adicionar Desktop Development with C++ (você também pode marcar as opções de Unity e game development mas não são necessárias para o SDL).

Depois de instalado, selecione a opção Create a new project e procure por Empty Project com C++, como na imagem abaixo. Se você não estiver vendo essa opção, volte no instalador e veja se as opções de suporte ao C++ foram instaladas no Visual Studio.

Após selecionar Empty Project com C++, na próxima janela digite HelloGame em Project name, e no campo Location selecione o caminho em que está o repositório que criamos no início deste post. As configurações do novo projeto devem estar iguais a imagem abaixo.

Depois de criar o novo projeto no Visual Studio, esta é a estrutura do nosso repositório atualizada:

HelloWorldSDL3/
├── .git/
├── HelloGame/
├── SDL/
└── .gitmodules

Adicionando código
#

Agora que temos um projeto em branco, vamos adicionar um arquivo de C++ e configurar o projeto para utilizar o SDL que está no mesmo diretório. É importante adicionar um arquivo de código fonte em C++ antes de continuar por que isso vai habilitar as opções que vamos configurar mais pra frente.

Clique com o botão direito no projeto HelloGame e, em seguida, selecione a opção Add | New Item... e digite main.cpp. No novo arquivo criado, copie e cole o código abaixo. Não se preocupe com os erros de compilação agora, nós ainda vamos configurar o projeto para localizar o SDL e poder compilar com sucesso.

#define SDL_MAIN_USE_CALLBACKS 1
#include <SDL3/SDL.h>
#include <SDL3/SDL_main.h>

static SDL_Window* window = NULL;
static SDL_Renderer* renderer = NULL;

SDL_AppResult SDL_AppInit(void** appstate, int argc, char* argv[])
{
 if (!SDL_CreateWindowAndRenderer("Hello World", 800, 600, SDL_WINDOW_MAXIMIZED, &window, &renderer)) {
 SDL_Log("Couldn't create window and renderer: %s", SDL_GetError());
 return SDL_APP_FAILURE;
 }
 return SDL_APP_CONTINUE;
}

SDL_AppResult SDL_AppEvent(void* appstate, SDL_Event* event)
{
 if (event->type == SDL_EVENT_KEY_DOWN ||
 event->type == SDL_EVENT_QUIT) {
 return SDL_APP_SUCCESS;
 }
 return SDL_APP_CONTINUE;
}

SDL_AppResult SDL_AppIterate(void* appstate)
{
 const char* message = "Hello World!";
 int w = 0, h = 0;
 float x, y;
 const float scale = 4.0f;

 SDL_GetRenderOutputSize(renderer, &w, &h);
 SDL_SetRenderScale(renderer, scale, scale);
 x = ((w / scale) - SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE * SDL_strlen(message)) / 2;
 y = ((h / scale) - SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE) / 2;

 SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
 SDL_RenderClear(renderer);
 SDL_SetRenderDrawColor(renderer, 255, 255, 255, 255);
 SDL_RenderDebugText(renderer, x, y, message);
 SDL_RenderPresent(renderer);

 return SDL_APP_CONTINUE;
}

void SDL_AppQuit(void* appstate, SDL_AppResult result)
{
}

O código acima é uma variação do hello.c disponibilizado no repositório do SDL. As mudanças que fiz foram mudar a extensão para .cpp, remover os comentários para não ficar tão longo aqui, e configurar a janela usando SDL_WINDOW_MAXIMIZED (modo janela) ao invés do original que criava a janela em modo tela cheia.

Adicionando SDL como dependência
#

Agora vamos adicionar o SDL no Visual Studio junto com o nosso projeto. Para isso, clique com o botão direito na Solution 'HelloGame', selecione Add | Existing Project e, na nova janela navegue até SDL/VisualC/SDL (dentro do nosso repositório), e selecione o arquivo SDL.vcxproj. Depois de adicionar o projeto SDL junto ao nosso projeto HelloGame, você deve ter a estrutura abaixo no Visual Studio:

O próximo passo agora é adicionar o SDL como uma referência no projeto HelloGame. Cliquei com o botão direito no projeto HelloGame, selecione Add | Reference... e, na nova janela, selecione o projeto SDL e clique em OK. Isso vai garantir que o nosso projeto use o SDL como uma dependência para compilar o código.

Por fim, vamos adicionar os headers do SDL na configuração do nosso projeto. Para isso, clique com o botão direto no projeto HelloGame e selecione a opção Properties. Na nova janela, mude o filtro acima para All Configurations e All Platforms (se já não estiver assim). Em seguida, expanda a opção C/C++ no menu da esquerda, selecione General, e no primeiro campo Additional Include Directories, selecione Edit e adicione o caminho SDL/includes (dentro do nosso repositório).

A imagem baixo mostra como a configuração deste janela deve estar depois dos passos acima:

Rodando o projeto
#

Se tudo deu certo, agora basta rodar o projeto no Visual Studio utilizando o botão play verde ou pressionando F5, e você deverá ver a tela abaixo:

Caso encontre algum erro, dê uma revisada nos passos anteriores e compare as imagens que adicionei no post para ajudar. Se mesmo assim tiver dúvidas ou problemas, deixe um comentário que tentarei ajudar assim que possível.

Nós temos um repositório configurado no GitHub com o SDL adicionado como uma dependência e também o nosso projeto configurado para rodar no Visual Studio. O próximo passo agora é um extra, mas que com certeza vai ajudar o desenvolvimento ao médio e longo prazo.

Automação com GitHub Workflow
#

Automação é algo muito comum e essencial em empresas, não só em jogos. A automação pode ser desde rodar alguns testes unitários, compilar o projeto, e até rodar o jogo em um teste pré-definido. Para isso, muitas vezes precisamos de outras máquinas ou até servidores dedicados a rodar nosso projeto sempre que precisar de um teste, ou até mesmo a cada alteração.

É ai que entra o GitHub Workflow, onde podemos automatizar muita coisa no nosso repositório utilizando servidores Windows, Linux e macOS do GitHub. Existem alguns limites, mas mesmo uma conta gratuita tem o suficiente para bastante coisa em projetos pequenos e até médios. Você também pode registrar uma máquina sua como servidor e não se preocupar com limites (já fiz isso com um raspberry pi e funcionou bem para projetos pequenos!).

Não vou entrar em muitos detalhes sobre o GitHub Workflow em si, por que é algo muito grande e complexo de explicar tudo, mas recomendo dar uma olhada na documentação e pesquisar sobre também.

Para adicionar suporte a automação em nosso projeto, precisamos apenas adicionar um arquivo no repositório. No repositório, cria uma nova pasta .github e outra pasta dentro dela chamada workflows. Dentro da pasta workflows, adicione um novo arquivo chamado msbuild.yml. Seu repositório deve estar assim:

HelloWorldSDL3/
├── .git/
├── .github/workflows/msbuild.yml
├── HelloGame/
├── SDL/
└── .gitmodules

Por fim, abra o arquivo msbuild.yml em qualquer editor e copie e cole o conteúdo abaixo:

name: MSBuild

on:
 push:
 branches: [ "main" ]
 pull_request:
 branches: [ "main" ]

env:
 SOLUTION_FILE_PATH: ./HelloGame
 BUILD_CONFIGURATION: Release

permissions:
 contents: read

jobs:
 build:
 runs-on: windows-latest

 steps:
 - uses: actions/checkout@v4
 with:
 submodules: recursive

 - name: Add MSBuild to PATH
 uses: microsoft/setup-msbuild@v1.0.2

 - name: Restore NuGet packages
 working-directory: ${{env.GITHUB_WORKSPACE}}
 run: nuget restore ${{env.SOLUTION_FILE_PATH}}

 - name: Build
 working-directory: ${{env.GITHUB_WORKSPACE}}
 run: msbuild /m /p:Configuration=${{env.BUILD_CONFIGURATION}} ${{env.SOLUTION_FILE_PATH}}

 - name: Upload a Build Artifact
 uses: actions/upload-artifact@v4.6.2
 with:
 name: hellogame-x64-release
 path: ./HelloGame/x64/Release/

O arquivo acima parece um pouco confuso, mas se você ler cada linha vai começar a fazer sentido:

Este workflow roda quando commits forem adicionados no branch main ou quando tiver um pull request para ele.
O nosso env está configurado com o caminho do projeto HelloGame e a build Release.
O job vai rodar em máquinas windows.
Estamos utilizando msbuild para compilar o projeto pela linha de comando (já que é um servidor sem interface).
Depois de compilar, a build do jogo vai ficar arquivada como um artefato deste workflow.

Assim que adicionarmos esse arquivo no repositório e fizermos um commit para o branch main, este workflow vai rodar em gerar uma build que podemos baixar e testar, e vai estar no menu Actions do repositório no GitHub.

Além disso, é possível ver todo o processo de compilação e os logs do servidor. Caso algum erro aconteça, é lá que você vai entender o por que.

Conclusão
#

Este post demorou um pouco mais do que planejei para escrever, e ficou mais longo do que imaginei, mas acho que no fim é uma boa introdução de como criar um projeto novo usando SDL3, configurar o Visual Studio, e ainda como usar git submodule e GitHub Workflows para automação.

Tudo que fiz neste post pode ser visto no meu repositório público hello-worlds-sdl3. Fique a vontade para usar este repositório como um template ou base para o seu projeto, este é um dos motivos que fiz para mim mesmo.

Muito obrigado se você leu até o final, e espero que tenha sido útil. Qualquer dúvida, problemas no passo-a-passo, ou sugestões deixe um comentário abaixo.

Hello World usando SDL no Visual Studio

Sun, 21 Mar 2021 00:00:00 +0000

A SDL é uma biblioteca para desenvolvimento de jogos cross-platform com código aberto que existe desde 1998. Diversos jogos foram publicados utilizando SDL, como por exemplo, Half-Life 2, Left 4 Dead 2, Dying Light, Factorio, FTL, entre muitos outros. Sua linguagem de programação principal é C e C++, porém existem alguns bindings que permitem programar em outras linguagens como C#, Go, Lua, Rust e Python. Por ser "apenas" uma biblioteca, não possui uma interface gráfica como a Unity ou Unreal. Neste post vou demonstrar o passo a passo para criar um projeto utilizando o Visual Studio no Windows.

Para começar faça o download do runtime binaries da sua plataforma. Se você está utilizando Windows 10, pode fazer download da versão 64-bit Windows. Também é possível utilizar o código fonte, mas o runtime binaries é o suficiente para iniciar um projeto. Para referência, a versão da SDL utilizada é 2.0.14.

Configuração no Visual Studio
#

Estou utilizando o Visual Studio 2019 Community Edition que pode ser baixado aqui. Apesar das imagens abaixo serem da versão 2019 a configuração é a mesma em outras versões do Visual Studio.

Após realizar o download da SDL faça a extração em algum local do seu computador sem espaços no nome dos diretórios. Eu gosto de colocar meus projetos em C:\Projects e qualquer biblioteca ou dependência (como os arquivos da SDL) em C:\Dev.

Vamos criar um projeto novo do tipo Console App. Este projeto vai ter apenas um arquivo cpp, onde vamos adicionar o código do Hello World. O nome deste arquivo não importa, mas gosto de renomeá-lo para main.cpp.

Com o projeto criado basta clicar com o botão direito no Project (dentro da Solution) e selecionar a última opção chamada Properties. A seguir iremos adicionar o caminho para as pastas include e lib\x64 em VC++ Directories, e as libs SDL2.lib e SDL2main.lib em Linker/Input, conforme as imagens abaixo. Lembre-se de selecionar All Platforms antes de iniciar a configuração.

Por fim, precisamos copiar o arquivo SDL2.dll que está em lib\x64 para dentro do projeto, junto com o nosso arquivo cpp. Esta é a última etapa para configurar o Visual Studio e compilar o projeto com a SDL.

Como realizamos toda a configuração utilizando a lib\x64 lembre de selecionar x64 na Visual Studio antes de compilar e executar o projeto.

Hello World
#

Um projeto com SDL segue uma sequência bem definida de métodos, os quais devem ser executados para que tudo funcione corretamente. O código abaixo é a base que iremos utilizar, contendo a importação do SDL, o tamanho da tela e da imagem que vamos exibir e o método principal da aplicação. Este código não faz nada, mas pode ser executado para testar se a SDL está configurada corretamente no projeto do Visual Studio.

#include <SDL.h>

#define WINDOW_WIDTH 640
#define WINDOW_HEIGHT 480

#define IMAGE_WIDTH 256
#define IMAGE_HEIGHT 256

int main(int argc, char* args[])
{
 return 0;
}

Os trechos de código a seguir estão dentro do método main(). Em primeiro lugamos vamos inicializar a SDL e verificar se foi inicializada com sucesso. Caso algum erro seja retornado, iremos exibir a mensagem de erro no console utilizando SDL_Log() e finalizar a aplicação. Mais detalhes do método de inicialização aqui.

if (SDL_Init(SDL_INIT_EVERYTHING) != 0)
{
 SDL_Log("SDL_Init Error: %s\n", SDL_GetError());
 return -1;
}

A seguir criaremos nossa Window onde o jogo será exibido. No código abaixo, a janela será criada no centro da tela com o tamanho definido anteriormente, e o título Hello World SDL2. Você pode ver aqui todos os parâmetro em detalhes.

SDL_Window* window = SDL_CreateWindow("Hello World SDL2", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, WINDOW_WIDTH, WINDOW_HEIGHT, SDL_WINDOW_SHOWN);
if (window == nullptr)
{
 SDL_Log("SDL_CreateWindow Error: %s\n", SDL_GetError());
 return -1;
}

O último item necessário para terminarmos a inicialização da SDL é o Renderer, responsável por "desenhar" na tela criada anteriormente. Os detalhes da criação do renderer podem ser vistos aqui.

SDL_Renderer* renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);
if (renderer == nullptr)
{
 SDL_Log("SDL_CreateRenderer Error: %s\n", SDL_GetError());
 return -1;
}

Com a SDL inicializada e a window e o renderer criados, podemos desenhar uma imagem na tela. O código abaixo carrega uma imagem no formato BMP e a exibe no centro da tela. Primeiro criamos uma surface para então criar a texture. Com a textura criada, podemos remover a surface da memória (a texture será removida só no final da aplicação). O SDL_Rect possui as coordenadas onde a imagem será desenhada e seu tamanho, considerando que o ponto de origem da imagem é no seu centro. Por fim, desenhamos a texture na tela utilizando o SDL_Render.

SDL_Surface* image = SDL_LoadBMP("image.bmp");
if (image == nullptr)
{
 SDL_Log("SDL_LoadBMP Error: %s\n", SDL_GetError());
 return -1;
}

SDL_Texture* texture = SDL_CreateTextureFromSurface(renderer, image);
if (texture == nullptr)
{
 SDL_Log("SDL_CreateTextureFromSurface Error: %s\n", SDL_GetError());
 return -1;
}

SDL_FreeSurface(image);

SDL_Rect rect;
rect.x = (int)(WINDOW_WIDTH * 0.5f - IMAGE_WIDTH * 0.5f);
rect.y = (int)(WINDOW_HEIGHT * 0.5f - IMAGE_HEIGHT * 0.5f);
rect.w = IMAGE_WIDTH;
rect.h = IMAGE_HEIGHT;

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, texture, nullptr, &rect);
SDL_RenderPresent(renderer);

Todo esse código acontece antes do main loop, ou seja, será executado apenas uma vez. A imagem do exemplo será desenhada apenas uma vez na tela e, como no loop abaixo não tem outra chamada para o SDL_Render, ela continuará desenhada até o fim. Este loop é usado apenas para ler o input do jogador e sair do loop se a janela for fechada.

while (true) {
 SDL_Event e;
 if (SDL_PollEvent(&e)) {
 if (e.type == SDL_QUIT) {
 break;
 }
 }
}

Quando o jogador fechar a tela e o jogo sair do loop vamos finalizar a SDL. Para isso tiramos tudo que foi alocado da memória, como texture, renderer e window. E por fim finalizamos a SDL.

SDL_DestroyTexture(texture);
SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(window);
SDL_Quit();

Assim temos nosso Hello World com uma imagem desenhada na tela. A class completa pode ser vista neste gist. Se tiver alguma dúvida sobre os métodos e objetos da SDL acesse a documentação da biblioteca, a qual contem bastante informação e exemplos práticos.

Cuidados
#

Pelo tamanho do post é possível ver que desenhar uma simples imagem na tela exige uma boa quantidade de código. Enquanto na Unity, isso pode ser feito praticamente arrastando uma imagem para dentro da engine, com a SDL tudo é mais "manual". Isso pode dar mais trabalho, mas também da mais controle ao programador. Por isso, é preciso prestar atenção para não fazer algo errado sem perceber.

Quando estava criando este exemplo para o post, percebi que o simples fato de desenhar uma imagem na tela estava utilizando 97% da minha GPU (o que é um absurdo). Notei que meu erro foi executar os métodos SDL_RenderClear(), SDL_RenderCopy() e SDL_RenderPresent() a cada loop (é um exagero para uma imagem estática).

Movendo as chamadas destes métodos para fora do loop, a utilização da GPU caiu para 1%. Existem algumas técnicas para controlar melhor o main loop e o frame rate, assim como desenhar apenas quando a imagem mudar de posição, entre outras possibilidades. O que me pegou de surpresa foi a própria documentação ter este exemplo, de uma imagem estática sendo desenhada todo frame.

Conclusão
#

Trabalhar com a SDL é um pouco lento no início até ter a base do jogo pronta, depois disso é a programação do jogo em si. É mais complicado do que utilizar a Unity e C#, por exemplo, com uma curva de aprendizado bem maior. Porém, é bem recompensador e importante aprender a programar (e programar jogos) em um "nível mais baixo" do que em uma engine que já te dá tudo pronto e você não vê muito bem o que acontece por trás do seu script.

O código completo está disponível neste link. Caso queira se aprofundar, recomendo olhar a documentação oficial. Este site também possui bons exemplos de programação de jogos com SDL.

Cursos e tutoriais para aprender a programar jogos

Sun, 03 Jan 2021 00:00:00 +0000

Já escrevi algumas vezes sobre cursos e tutoriais para aprender a programar jogos, porém é sempre bom relembrar este assunto com novas referências para quem está começando hoje. Então, decidi escrever um post bem simples e direto com recomendações, para diferentes níveis de conhecimento, combinando aprendizado em programação, inglês e desenvolvimento de jogos.

O conteúdo deste post são recomendações pessoais, baseadas na minha experiência e com certeza não são as únicas opções disponíveis no mercado. Não adicionei cursos acadêmicos, apenas cursos livres e sites com tutoriais.

Conhecimento Básico ou Nenhum
#

Se você está começando a estudar desenvolvimento de jogos, seja por hobby ou para entrar na indústria de jogos, é bom começar do básico e com conteúdo de qualidade. Nenhum destes cursos substitui uma formação acadêmica, que eu recomendo fazer, porém são complementares para entender como é desenvolver um jogo, ou para ter um primeiro contato e validar se é algo que realmente quer investir como carreira.

Alura

É um serviço de cursos online com excelente conteúdo para quem quer aprender a programar, ou até expandir seus conhecimentos. É um serviço pago, mas que o conteúdo vale cada centavo investido, já que a plataforma conta com mais de 1242 cursos até o momento. Confira os cursos de desenvolvimento de jogos disponíveis. E não se preocupe se sentir que não está pronto para iniciar direto com programação de jogos, é possível começar a aprender com alguns cursos de programação para se familiarizar um pouco, antes de partir para games. Acesse aqui.

Udemy

Se você ainda não tem certeza que é isso que quer estudar, talvez seja interessante ter um primeiro contato com um curso livre no Udemy, que possui cursos de desenvolvimento de jogos muito bons em português ou com legenda disponível. Lembre sempre de verificar se o curso está disponível em português ou se existem legendas, além de verificar os comentários dos alunos sobre o curso desejado. Acesse aqui.

Conhecimento Intermediário à Avançado
#

Para quem já tem um conhecimento prévio em programação e inglês, porém não necessariamente um conhecimento de programação de jogos, existem excelentes conteúdos disponíveis gratuitamente. Neste ponto é importante focar em uma game engine, como a Unity ou a Unreal. Com exceção do site da Unreal, todos os links abaixo são sobre Unity, já que é a game engine que trabalho há anos e tenho mais referências para indicar. Este conteúdo também é indicado para quem já teve um primeiro contato com desenvolvimento de games e quer se aprofundar mais.

Unreal Online Learning

No site oficial da Unreal Engine existe uma boa quantidade de tutoriais para aprender a desenvolver jogos utilizando esta tecnologia, seja através de C++ ou Blueprints. Existem tutoriais para todo nível de conhecimento, porém é necessário um conhecimento prévio em inglês para poder aproveitar melhor os cursos. O canal no YouTube da Unreal também possui muito conteúdo bom, recomendo seguir. Acesse aqui

Unity Learn

A Unity também tem o seu portal de tutoriais e cursos, o Unity Learn, que ficou totalmente gratuito no início do ano passado. Já fiz vários cursos disponíveis e não canso de recomendar esta plataforma para todos que queiram aprender a fazer jogos com Unity ou aprimorar seus conhecimentos na engine. O canal no YouTube da Unity também é um ótimo lugar para encontrar mais conteúdo sobre a engine. Acesse aqui.

Brackeys

Infelizmente, este canal deixou de produzir conteúdo desde o final do ano passado, com os criadores anunciando que vão focar em novos projetos. Porém, ainda existe muito conteúdo bom neste canal para estudar. Acesse aqui.

Code Monkey

Com vídeos curtos e objetivos, o Code Monkey explica muito bem como fazer algo bem específico na Unity. O canal tem crescido bastante, com tutoriais cada vez melhores e atuais. Acesse aqui.

Game Dev Guide

Este canal também possui vídeos curtos e objetivos, com excelente explicações, mas com uma frequência de postagem menor. Acesse aqui.

Infallible Code

Por fim, um canal que conheci a pouco tempo, com alguns vídeos bem interessantes. O autor realiza lives com frequência discutindo assuntos bem relevantes, vale conferir. Acesse aqui.

Conhecimento Avançado e Específico
#

Com um nível avançado em programação, desenvolvimento de jogos e entendimento de conteúdos em inglês, começa a surgir uma necessidade de se especializar em determinado assunto. Na minha opinião, é difícil um curso de desenvolvimento de jogos ser para um público avançado, uma vez que a base necessária para desenvolver um jogo já existe. Assim, faz mais sentido para mim aprender e recomendar técnicas diferentes, assuntos específicos e palestras sobre o desenvolvimento de grandes jogos.

GDC

A Game Developers Conference (GDC) é um evento anual que reúne profissionais da indústria do mundo todo com palestras e workshops sobre técnicas e tecnologias utilizadas para o desenvolvimento de jogos. O evento conta com palestras desde postmortems até soluções bem inovadores utilizadas na geração atual de consoles. Mesmo que boa parte do conteúdo seja com base em game engines restritas, é possível abstrair e ter boas ideias para implementar em seu próprio projeto, ou aprender como um determinado desafio técnico foi solucionado. Acesse aqui.

Sebastian Lague

Descobri este canal recentemente e fiquei impressionado com os tutoriais. O Sebastian explica um pouco rápido, mas é possível aprender muita coisa sobre shader e técnicas avançadas para desenvolvimento de jogos na Unity. Alguns destaques são as playlists sobre geração procedural de planetas e simulação de ecossistemas, além de muito conteúdo sobre matemática aplicada em programação de jogos. Acesse aqui.

AI and Games

Se a especialização que você procura é em Inteligência Artificial, este canal tem muitos vídeos que vão te abrir os olhos para como determinadas técnicas são implementadas em jogos. Acesse aqui.

The Cherno

O Cherno faz vídeos sobre C++, OpenGL e tem uma série mostrando como desenvolver uma game engine do zero. Mesmo que não seja seu interesse criar uma game engine, este conhecimento é excelente para saber o que acontece por trás do seu código. Acesse aqui.

Game Maker's Toolkit

Um canal bem grande sobre game design. Seus vídeos dissecam mecânicas e sistemas implementados em jogos, com discussões desde geração de números aleatórios e até o que torna uma Inteligência Artificial boa para um game. Acesse aqui.

Game Brain

Este canal é mais focado em game design e discussões sobre como alguns problemas foram resolvidos em determinados jogos. Apesar de não ter programação, seu conteúdo é bem técnico. Acesse aqui.

O que mais posso fazer para aprender?
#

Jogos. Desenvolva jogos sempre que puder. Busque inspirações em outros jogos ou em coisas que você gosta e tem interesse, sempre mostre seu projeto e peça feedback para você saber onde deve melhorar. Lembre-se que você deve fazer um jogo para alguém jogar, e não deixar escondido no seu computador.

Tem mais alguma dica de curso ou tutoriais que quer recomendar? Deixe um comentário aqui no post.

Como ser um programador de jogos

Wed, 27 Jan 2016 00:00:00 +0000

Há pouco mais de 2 anos comecei uma série de posts sobre como ser um programador de jogos, e cada semana tratei um assunto relacionado a como começar uma carreira como programador na indústria de games. Fiz 32 posts nesta série e acabei não escrevendo mais posts há quase 1 ano nesta categoria por que os assuntos para iniciantes foram diminuindo e eu acabei ficando sem tempo para posts semanais.

Decidi fazer este post para reunir a lista com os 32 posts em apenas um lugar. Muitas vezes recebo emails de pessoas que estão querendo começar na área, e um dos links que sempre envio é o da categoria Como Começar. Porém, acredito que todos links em um único post devem ser mais úteis e fáceis de consultar.

#01 Pré-requisitos

#02 Hello World

#03 Engine vs Framework

#04 Primeiro jogo

#05 Cursos

#06 Livros

#07 Concursos e Game Jams

#08 Playground

#09 Protótipos

#10 Códigos Open Source

#11 Programar sem ter a Arte Final

#12 Para que serve um Maker

#13 Delta Time

#14 Dados analíticos do jogo

#15 Teste com jogadores

#16 Game Design Document

#17 Parallax

#18 Você já fez um jogo?

#19 Gerenciamento do seu tempo

#20 Jogue bastante, mas jogos diferentes

#21 Pixel Perfect

#22 Boas práticas para animações 2D

#23 Feedback de ações para o jogador

#24 200 mecânicas de gameplay

#25 Definição de prioridade de tarefas

#26 Transformando jogo em produto

#27 Por onde começar a programar

#28 Mantenha tudo simples

#29 Avaliando um Framework

#30 Programando com estilo

#31 Design Patterns

Olhando os 32 posts aqui até parecem capítulos de um livro, e a ideia inicial dessa série era ser um pequeno guia com informações úteis para quem estiver começando na área. Diferente dos últimos posts desta série, não vou prometer que vou voltar a postar nesta categoria toda semana, mas prometo que vou tentar continuar ou pelo menos atualizar os assuntos tratados anteriormente com novos posts e novas informações.

Recomendação da semana

Esta semana finalmente assisti uma série de ficção científica incrível chamada Firefly. Nesta série a civilização humana desenvolveu uma tecnologia que transforma outros planetas e luas em lugares similares a Terra, permitindo a expansão pelo espaço. O interessante desta série é que não existem máquinas com inteligência artificial avançada e muito menos alienígenas, apenas humanos e naves. É possível aplicar essa mesma ideia em games, usando jogabilidades comuns porém com diferentes abordagens.

Como ser um programador de jogos: Design Patterns

Mon, 23 Mar 2015 00:00:00 +0000

Este é um assunto complicado até para quem decorou todos design patterns possíveis e imagináveis em programação. Por mais que existem muitos por ai, poucos são utilizados no dia-a-dia, e muitas vezes por falta de conhecimento.

Antes de começar a trabalhar com jogos eu imaginava que muitos design patterns eram utilizados nos jogos, afinal são programas bem complexos e grandes. Porém, o que eu aprendi é que nem sempre é necessário utilizar todas as técnicas possíveis só para dizer que utilizou.

Em praticamente todos jogos que trabalhei na Glu e na EA o design pattern mais utilizado era sempre o Singleton. Praticamente todas as classes que não eram objectos ou entidades tinham este padrão implementado que tem como objetivo expor uma variável estática para acessar todo conteúdo da classe.

É claro que aqui e ali se via alguns outros design patterns, como Factory e Prototype, mas o mais utilizado sem dúvidas era o Singleton, por que funciona muito bem quando você precisa acessar conteúdos de outras classes. É importante conhecer alguns design patterns mais utilizados, mas também saber onde e quando utilizar.

Não adianta implementar todos design patterns só para falar que utilizou todos se os demais programadores da equipe (ou futuros programadores) não vão manter tudo funcionando, principalmente por falta de conhecimento. Por isso é muito importante conhecer bem os mais utilizados e pelo menos saber onde utilizar. Para estudar mais sobre design patterns eu recomendo os 3 livros abaixo:

Este livro possui uma Game Programming Patterns (o autor começou o link na internet e depois publico a versão impressa). Obrigado Gabriel Sussumu por lembrar deste link nos comentários!

UPDATE 1: Links de mais conteúdo de Design Patterns em jogos enviado pelo leitor Fernando Mondo:

UPDATE 2: Reescrevi algumas partes do texto para tentar expressar melhor minha opinião.

Como ser um programador de jogos: Programando com estilo

Tue, 17 Mar 2015 00:00:00 +0000

Faz um bom tempo desde que escrevi o último post desta série, mas agora pretendo voltar com a frequência de 1 post por semana sobre como como ser um programador de jogos. Por mais que o título seja sobre programação, muitas dicas já apresentadas são úteis para todas as áreas.

Programar com estilo não é escrever um código enquanto salta de um avião e fazer ele compilar com sucesso antes de abrir o paraquedas, mas sim programar seguindo um estilo ou um padrão que deixe o código mais organizado e fácil de entender para outros programadores.

A primeira vez que li um documento sobre padronização de código foi enquanto trabalhava na EA. Era um documento bem completo sobre melhores práticas de programação em C/C++ para deixar o código organizado e bem escrito para qualquer desenvolver trabalhar sem problemas.

Muitas empresas de tecnologia tem este tipo de documento, porém poucas publicam na internet. Neste post reuni alguns muito interessantes para se estudar e que são públicos.

Google C++ Style Guide (dica do Rodrigo Delduca)
Id Software Coding Style Conventions (usado no DOOM 3)
Airbnb JavaScript Style Guide
Mozilla Coding Style

Vale a pela ler antes de programar, e se for o caso procure algo voltado para a linguagem de programação que você está utilizando no momento. E você, conhece algum guia que faltou aqui?

Veja todos os posts desta série clicando aqui!

Como ser um programador de jogos: Avaliando um framework

Thu, 26 Jun 2014 00:00:00 +0000

Existem muitos frameworks para jogos na internet, e cada vez mais estão sendo lançados para diversas plataformas. Por isso, é importante saber o que um framework deve ter e o que deve ser testado, antes de escolher a tecnologia errada e descobrir isso tarde demais para mudar.

Os itens abaixo foram baseados em necessidades que tive (e não foram atendidas) quando desenvolvi o TCC da minha pós-graduação. O framework que eu usei foi uma escolha tão errada que ele falha em quase todos os itens abaixo, mas era tarde demais para mudar.

Por isso, vale a pena perder um tempo no começo do projeto avaliando se o framework escolhido realmente serve para o que você quer fazer, e também se funciona bem, para não te deixar na mão.

Possui alguma biblioteca de física? Se não, existe alguma recomendada pelos criadores do framework que funciona bem em conjunto?
Consegue trabalhar com sprite sheets ou apenas imagens separadas?
É necessário muitas linhas de código para carregar e desenhar algo na tela?
Possui suporte para eventos de entrada (teclado, mouse, touch, etc)?
No caso de 3D, quais são as compressões de textura que tem suporte?
Existe um site/forum para tirar dúvidas? Algo feito para a comunidade de desenvolvedores que usa a tecnologia?
O framework é atualizado constantemente?
Possui um roadmap de futuras atualizações? Eles são abertos a sugestões?
Pode ser utilizado em mais de uma plataforma?
Se for pago, existe uma versão trial para testes?
Possui suporte a redes sociais, publicidade e pagamento (para comprar itens no jogo com dinheiro de verdade)? Se não, aceita algum framework externo?
Em quais sistemas operacionais e IDEs (visual studio, xcode, eclipse, etc) funciona?
O framework é famoso e já foi utilizado em jogos publicados?
É fácil de debugar e entender os problemas?

Isso tudo é bem genérico, e é claro que depende do tipo de jogo que você está desenvolvendo. Mas, mesmo se não usar algo no início do projeto, é bom saber se o framework tem suporte a uma determinada funcionalidade, ou seu jogo não será flexível. Existe mais algum ponto que vale a pena ser verificado antes de escolher um framework? Comente abaixo!

Como ser um programador de jogos: Mantenha tudo simples

Mon, 12 May 2014 00:00:00 +0000

Esta semana li este comentário que me inspirou a escrever este post, que é a frase famosa “Keep it simple, stupid”, algo como “Mantenha simples, idiota” em tradução literal.

Muitas vezes buscamos programar a melhor solução possível para um problema, mas muitas vezes o problema não requer uma solução complicada. Por exemplo, não é necessário programar um algoritmo de ordenação complexo para ordenar uma lista que sempre será pequena, neste caso vale a pena usar algo mais simples.

O Brian Kernighan, explicou a frase “Keep it simples, stupid” da seguinte forma: debugar um código é duas vezes mais complexo do que escrevê-lo. Sendo assim, se você escrever o melhor código possível, você mesmo não será capaz de debugá-lo. Faz sentindo, não?

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

Brian Kernighan

Quanto maior for a complexidade, mais difícil será entender algum bug no código. Por isso, mantenha seu código com baixa complexidade e sempre pense em como debugar enquanto programa, isso ajuda a identificar problemas e prevenir código complexos.

Uma dica para simplificar um código é quebra-lo em métodos e funções, pois assim você deixa o código reusável e mais simples de entender e debugar. Existem outras formas de simplificar um código, está é uma das mais básicas e usadas.

Outra dica é ler livros que ensinam programar e também boas práticas, como Code Complete e Effective C++.

UPDATE

Dicas do leitor Lucas Oliveira:

Practical Object-Oriented Design in Ruby by Sandi Metz

Como ser um programador de jogos: Por onde começar a programar um jogo

Fri, 02 May 2014 00:00:00 +0000

Muita gente se perde na hora de começar a programar um jogo, e independente do tamanho do projeto pode ser realmente uma tarefa difícil saber por onde começar.

A melhor alternativa é sempre começar pela mecânica principal do jogo, quebrando ela em tarefas menores. Por exemplo, em um jogo onde um personagem movimenta-se pela tela, a primeira coisa que deve ser programada é este personagem. Antes mesmo de pensar em atacar, sistema de níveis, inimigos, e qualquer outra coisa, o jogador deve poder movimentar o personagem.

A partir disso, você pode criar um nível de playground para poder testar o comportamento do personagem com diversas opções no cenário do jogo. Isso é apenas um exemplo, pois esta abordagem pode variar de acordo com o tipo do jogo, mas no geral é sempre bom começar pela mecânica principal, e trabalhar nela até ficar bem polida.

Em jogos de puzzle, por exemplo, a primeira coisa a ser programada são os movimentos que o jogador pode fazer para resolver um puzzle, antes mesmo de programar o puzzle. Com os movimentos bem definidos e testados, programar os diferentes puzzles ficará mais fácil.

Algumas coisas que escrevi neste post já foram apresentadas nesta série Como ser um programador de jogos, vale a pena conferir os posts anteriores por que tem muita coisa legal e útil para começar.

Como ser um programador de jogos: Transformando jogo em produto

Wed, 23 Apr 2014 00:00:00 +0000

Um game nasce de uma idéia ou um conceito, que então é validado com um protótipo, para depois tornar-se em algo jogável. Porém, esse “algo jogável” pode ser tecnicamente perfeito e, mesmo assim, não agradar aos jogadores. Nesse caso, a culpa não é da equipe de desenvolvimento, e sim de quem pensou na sua idéia sem tratá-la como um produto.

Para um jogo tornar-se um produto é necessário pensar em alguns detalhes antes (ou enquanto) o protótipo é desenvolvido, pois não basta o jogo ser bem feito e divertido se existe muita concorrência de jogos similares. Para transformar o jogo em um produto, deve-se montar um tipo de plano de negócio com foco em lançamento de produtos, e para isso deve-se levar em conta os seguintes itens:

Público-Alvo: Quem vai jogar o seu jogo? Onde você vai encontrar o seu público-alvo? Como você vai fazê-lo jogador?
Plataforma: Em qual plataforma você quer lançar o seu jogo? A ideia é viável na plataforma escolhida? Como funciona a publicação de um jogo nessa plataforma?
Mercado: As pessoas vão querer jogar o seu jogo? A plataforma escolhida é viável? O mercado está saturado para o tipo de jogo que você quer fazer?
**Concorrência **Quais empresas e quais jogos são seus concorrentes diretos e indiretos? Quais jogos são similares em algumas funcionalidades?
Diferenciais: Por que as pessoas vão querer jogar o eu jogo ao invés dos jogos concorrentes? Por que um investidor colocaria dinheiro em seu projeto?

Basicamente, esses são os pontos iniciais para transformar um jogo em produto. Apenas com esse tipo de análise de negócio será possível descobrir se o seu jogo terá chances de ser um sucesso ou não. É algo simples de fazer, não demora muito, e pode te deixar rico ou frustrado (para então tentar de novo!).

UPDATE

Dica do leitor Lucas Oliveira:

Modelo Canvas para plano de negócio

Site para montar um Canvas

Dica do Martin Luenendonk, do site STARTUP FUNDRAISING:

Investment Readiness Level Guide: How to Boost Your Startup’s Attractiveness to Venture Capital Investors using the Business Model Canvas

Como ser um programador de jogos: Definição de prioridade de tarefas

Wed, 09 Apr 2014 00:00:00 +0000

Assim como em qualquer projeto, existem tarefas e elas necessitam de prioridade para você saber quais são mais importantes e urgentes. No desenvolvimento de um jogo, muitas vezes as tarefas podem ter dependência com outras áreas, como arte ou som, porém mesmo com dependências podemos definir prioridades nas tarefas.

Podemos olhar para elas pensando exclusivamente na programação, assim você saberá o que deve ser programado primeiro. Por exemplo, não adianta fazer a programação do movimento de um personagem sem antes ter um personagem na tela. Algumas tarefas podem ser difíceis de priorizar, pois muitas podem ter a mesma dependência básica. Por exemplo, com o personagem na tela você pode fazer ele andar, atacar, pular, correr, etc, mas essas tarefas podem não dizer claramente quais são as mais importantes.

Para saber o que é mais importante na hora de programar, devemos olhar para o nosso objetivo. Se queremos fazer o personagem lutar, fazer ele se movimentar é mais importante do que fazer ele interagir com portas, por exemplo. Por isso, muitas vezes as tarefas são derivadas de uma tarefa maior, que na verdade é um requisito do jogo, uma mecânica, uma jogabilidade, uma feature, entre outras coisas. É importante também manter o foco, pois se o objetivo é ver o personagem lutar, não é necessário criar todo o nível nestas tarefa, pois o foco dela é jogabilidade.

A seguir está um exemplo de uma tarefa quebrada em outras menores, e (ordenado por prioridade sempre que possível). Através do exemplo abaixo, podemos ter uma idéia de por que uma tarefa tem mais prioridade do que a outra. Se ajudar, você podem também adicionar números nas tarefas e marcar o nome de qual tarefa é dependente dela, mas isso não é necessário se um objetivo tiver mais ou menos o mesmo tamanho que o exemplo. Se for muito maior do que isso, ele precisa ser quebrado em menores antes de definir as tarefas.

Objetivo

Movimentar o personagem através de um controle de touch na tela

Tarefas

Desenhar jogador na tela (apenas uma imagem)
Desenhar botões na tela (cima, baixo, esquerda e direita)
Capturar o input do jogador nos botões
Mover o personagem de acordo com o input
Definir uma velocidade de movimento
Substituir a imagem do jogador por animações para todas direções
Alterar a imagem dos botões quando ele for pressionado
Testar a jogabilidade e refinar até ficar boa e constante

Uma boa dica é utilizar ferramentas como o Trello para organizar as tarefas. Este post é legal para saber mais sobre o Trello e outras ferramentas e técnicas para organização do tempo, que podem ser úteis na organização das tarefas do projeto.

Como ser um programador de jogos: 200 mecânicas de gameplay

Wed, 26 Mar 2014 00:00:00 +0000

Você consegue pensar em várias mecânicas de gameplay diferentes? Conseguiria definir o conceito de mais de 200 diferentes? No site Squidi.net atualmente estão listadas 200 exemplos de mecânica de gameplay diferentes, que podem ser utilizadas livremente por qualquer pessoa. Seu objetivo é chegar em 300 conceitos diferentes.

Pra que serve isso? O trabalho de um Game Designer é criar mecânicas e validá-las com protótipos de gameplay, pra garantir que o jogo seja divertido. Nesse site existem diversos exemplo muito bons e bem explicados de mecânicas diferentes, que podem ser misturadas ou até gerar novas idéias. É como se fosse um repositório de idéias genéricas de gameplay.

Isso também é útil para programadores e artistas, pois ao ler sobre como uma mecânica funciona, você também entenderá o trabalho necessário para implementá-la, tanto na parte de código quando na parte de arte. Está sem idéias? Dê uma olhada no site, e novos jogos irão surgir na sua cabeça!

Site: http://www.squidi.net/three/index.php

Como ser um programador de jogos: Feedback de ações para o jogador

Wed, 19 Mar 2014 00:00:00 +0000

Uma das coisas mais frustrantes para um jogador é fazer uma ação no jogo e não ter um feedback do próprio jogo informando se a ação foi realizada, ou se ele fez algo errado.

É importante para um bom gameplay fornecer ao jogador um feedback para cada ação, para deixar claro se ação foi realizada com sucesso ou não.

O feedback pode ser uma mensagem de texto, um ícone na tela ou simplesmente um som. Fornecer um feedback das ações é um detalhe que deixa o jogo mais profissional, e evita o jogador de se sentir perdido ou irritado.

Este tipo de recurso faz parte do design de interface do jogo, pois deve ser prevista uma área para exibir o feedback para o jogador (caso seja um aviso gráfico). Um exemplo de feedback é a mensagem do windows quando você tenta apagar algo, ele pergunta se você realmente quer apagar:

No caso de jogos, pode ser exibido uma outra mensagem informando que a ação foi realizada com sucesso (ou não). Pode parecer chato sempre querer confirmar ações, mas isso é menos chato para o jogador do que perder algo importante no jogo por falta deste recurso.

Como ser um programador de jogos: Boas práticas para animações 2D

Wed, 05 Mar 2014 00:00:00 +0000

Um artista costuma fazer a animação completa de um determinado sprite, porém nem sempre será necessário utilizar todos os frames da animação para causar o mesmo efeito.

Mesmo com sprites detalhados, nem sempre a animação precisa ter muitos frames. Por exemplo, se você reparar em um jogo de luta 2D, a animação dos golpes normais (chute e soco) é muito rápida, praticamente um frame de antecipação e um do golpe. Muitos frames mostrando o golpe em detalhes vai pesar na memória, não será percebido no jogo e vai precisar de mais trabalho do artista.

Na imagem abaixo do jogo Street Fighter II, do Super Nintendo, podemos ver o que foi dito acima. Os dois primeiros frames são a antecipação, o frame do meio é o golpe, e os dois últimos frames é o feedback para o jogador após o golpe. Você pode conferir a spritesheet completa do Ken clicando aqui.

Em jogos que possuem animações rápidas, quanto menos detalhes tiver é melhor. O importante é focar no que a animação deve passar, como a sensação de um golpe rápido em um jogo de luta. Vale mais a pena investir em detalhes do que em mais frames, assim o jogo fica mais bonito, menos pesado e será possível ver toda animação sem desperdiçar frames.

Como ser um programador de jogos: Pixel Perfect

Wed, 26 Feb 2014 00:00:00 +0000

Uma das dúvidas mais comuns no desenvolvimento de jogos para dispositivos móveis é qual a melhor maneira para que o jogo se adapte em várias resoluções, e uma das técnicas mais usadas é a chamada Pixel Perfect, que consiste em utilizar a PPI do aparelho como base para isto.

Neste post vou explicar como está técnica funciona usando como base os aparelhos da Apple com iOS. No Android e Windows Phone é a mesma coisa, porém eles possuem mais variações de PPI, por isso dá um pouco mais de trabalho. Aqui não vou explicar como identificar a DPI de um aparelho, e sim o uso da técnica. Lembrando que isto funciona apenas para jogos em 2D, pois em 3D é outra história.

PPI significa Pixels Per Inch, ou seja, é o número de pixels por polegada. Isto é literalmente o número de pixels que são exibidos em uma polegada da tela, quanto maior mais detalhes se o tamanho da tela for grande também. Algumas pessoas chama isso também de DPI, que significa Dots Per Inch, ou seja, pontos por polegada. Esta atribuição é incorreta quando falamos de aparelhos digitais, pois esta medida é usada em impressões. Porém, é bem comum chamar PPI de DPI, o próprio Google chama esta medida de DPI no Android, então acostume-se a ouvir ambos.

Primeiro, vamos analizar a resolução e o PPI dos aparelhos da Apple. No Android a DPI é classificada como MDPI, HDPI, XHDPI, entre outros. Não vou entrar nos detalhes de classificação, pois o importante neste técnica é o valor da PPI/DPI. No caso do Android, você pode encontrar mais detalhes aqui.

iPhone 3G/3GS 320x480 163 ppi

iPhone 4/4S 640×960 326 ppi

iPhone 5/5C/5S 640×1136 326 ppi

A PPI do iPhone 3, assim como a resolução da sua tela, é exatamente a metade da PPI do iPhone 4 e de sua tela também. Por ser exatamente metade, isto significa que se você usar uma imagem do tamanho do iPhone 4 com resize no iPhone 3, ela ficará “perfeita”, e dai vem o termo Pixel Perfect. Isto só funciona quando a PPI (ou DPI) possui esta proporção de ser metade, então nestes casos você pode usar uma imagem maior com resize para um tamanho menor sem perder a qualidade e definição.

No caso do iPhone 5 temos um problema, embora sua PPI seja a mesma do iPhone 4, o tamanho da sua tela é diferente e não é proporcional, pois a largura é a mesma e a altura é diferente. Uma imagem no tamanho do iPhone 5 ficará cortada no iPhone 4, pois apesar da mesma DPI não é possível fazer o resize sem perder qualidade. Isto se aplica ao iPhone 3 também, que também tem a metade da PPI do iPhone 5, mas não tem a metade da resolução. Assim, a imagem ficará distorcida.

Estes são dois exemplos levando em conta apenas imagens com o tamanho da tela do aparelho, sendo que funciona do iPhone 4 para o iPhone 3, mas não funciona do iPhone 5 para os demais. Neste caso, muitos desenvolvedores criam uma imagem para o iPhone 5 e uma para o iPhone 4, que é usada também no iPhone 3.

Porém, para imagens que não ocupam a tela inteira como botões ou sprites, a mesma imagem usada no iPhone 5 pode ser usada no iPhone 4 sem resize, e usada no iPhone 3 com resize mas sem perder a qualidade e definição graças a PPI. Basicamente, a regra geral é esta:

Para imagens com o tamanho da tela:
– Resize só funciona sem perder a qualidade se os aparelhos tiverem a PPI/DPI e o tamanho da tela proporcionais.

Para imagens menores:
– Resize funciona baseado apenas na PPI/DPI, o tamanho da tela pode influenciar apenas o posicionamento dos itens na tela.

Já utilizei esta técnica algumas vezes quando trabalhei na Glu Mobile e na Electronic Arts. O jogo que mais usei isto foi o Scrabble, para Android e iOS. Todo seu layout é baseado na PPI/DPI do aparelho, e as imagens são usadas de acordo com esta classificação. Neste jogo o layout do tablet é diferente do smartphone, então não tivemos problemas com a PPI/DPI e resolução destes aparelhos, o que ajudou bastante no resultado final.

Espero ter conseguido explicar direito esta técnica, ela é bem simples de usar e um pouco complicada de explicar. Lembre-se que este exemplo foi feito para os modelos de iPhone, que é o mais simples de todos. Aparelhos Android geralmente dão mais problemas por causa da fragmentação e falta de padrões por parte dos fabricantes, mas não é impossível fazer uso do Pixel Perfect da mesma maneira. Qualquer dúvida, fique a vontade para perguntar nos comentários abaixo!

Como ser um programador de jogos: Jogue bastante, mas jogos diferentes

Wed, 12 Feb 2014 00:00:00 +0000

Muita gente acha quem trabalha com games fica jogando o dia inteiro. Isto é verdade, jogamos muito o projeto em que trabalhamos, mas também precisamos jogar outras coisas para ter novas ideias.

É incrível como, com o passar o tempo, quanto mais você desenvolve games, mais seu olhar fica atento a detalhes em um jogo. Não estou falando disso no sentido de falar mal de um jogo ou ficar achando defeitos, mas sim no sentido de aprender observando o jogo.

Por exemplo, você pode estar desenvolvendo um jogo em que uma determinada mecânica da jogabilidade não está muito boa. Neste caso, você pode jogar jogos que tenham a mecânica parecida e tentar entender como o seu problema foi resolvido neste jogo. Este é um dos benefícios de jogar tentando entender como o jogo foi feito, mas existem outras formas de aprender com games.

Jogar tipos diferentes de jogos, que você normalmente não está acostumado, pode te ajudar muito a aprender novas mecânicas de jogabilidade e até ter novas ideias para interface e HUD. É possível aprender e ter ideias para seus próprios projetos jogando desde games AAA hardcore para consoles até jogos sociais de Facebook e mobile. Mesmo que você não goste do jogo, ou não seja o seia tipo de jogo, jogue para extrair novas experiências que você pode proporcionar aos seus jogadores.

Se você quer aprender mesmo observando outros jogos, tente fazer isto: pegue um jogo que você não gosta e acha que tem muitos defeitos e tente melhorá-lo. Você irá, pelo menos, analisar o jogo, escrever um GDD para definir o game design e programar um protótipo para validar a jogabilidade. Se realmente você conseguiu melhorar o jogo seu aprendizado foi muito grande durante o processo. Basicamente, não critique se você não puder fazer melhor.

Não esqueça também de aprender com os famosos glitches, como no vídeo abaixo. Tentar entender uma mecânica para aproveitar em uma ideia é algo simples comparado com tentar entender como um determinado glitch acontece e por que.

Como ser um programador de jogos: Gerenciamento do seu tempo

Wed, 22 Jan 2014 00:00:00 +0000

Sem dúvidas um dos principais problemas que a maioria dos desenvolvedores enfrentam é a falta de tempo para se dedicar em um projeto, mas isso o pode ser amenizado com umas dicas para otimizar seu tempo.

Tudo que esta escrito neste post eu aprendi com o tempo e experiência. Algumas coisas deram certo pra mim e algumas para outras pessoas, por isso a melhor dica que posso dar é tentar sempre encontrar alguma forma de melhorar o uso do seu tempo, pois sem isso você já está perdendo um tempo que poderia estar trabalhando no seu jogo.

Uma das primeiras coisas que testei foi a técnica Pomodoro (Pomodoro Technique), que consiste em se concentrar por um tempo e depois descansar alguns minutos. Por exemplo, você pode trabalhar sem parar por 25 minutos e depois faz uma pausa de 5 minutos para fazer o que quiser, e depois continue repetindo este ciclo várias vezes. O tempo de descanso pode variar, mas o de trabalho não.

Existem várias maneiras de usar esta técnica, a minha preferida é esta extensão para o Chrome chamada Strict Workflow. Ele conta o tempo de trabalho e descanso e também bloqueia seu acesso a sites que você quiser durante os 25 minutos. Eu, pessoalmente, não consegui me adaptar para trabalhar usando esta técnica, pois as vezes estou concentrado e não quero parar meu tempo para descansar. Porém, para estudar funciona muito bem.

Outra forma de organizar seu tempo é criando uma lista de tarefas e colocando prazos. Esta parte é muito importante, coloque prazos e planeje sua semana. Eu utilizo o Any.Do, que é um aplicativo mobile com uma extensão para Chrome também. Nele listo as tarefas que tenho que fazer e coloco datas e alarmes para me lembrar. Funciona muito bem para tarefas do dia-a-dia que você tem que lembrar e fazer, mas para trabalhar eu prefiro usar outra coisa.

Eu senti uma necessidade de organizar os posts do blog, porém o Any.Do não funcionou na maneira que eu queria para isto. Então, decidi usar o Google Calendar, e até hoje funciona muito bem. Eu planejo os posts todas as semanas, e me cobro para escrever e postar nos dias certos. Se você acompanha o blog há um tempo pode perceber que nos útimos meses eu comecei a postar com muito mais frequência, e foi graças a minha organização no Google Calendar.

No trabalho também utilizo o Google Calendar para colocar prazos de cada projeto, mas não das tarefas relacionadas ao projeto em si.Lembre-se que neste post não estou falando em organização de projetos, que utilizo outros recursos como o Trello. Estou falando de como eu organizo meu tempo e minhas tarefas no dia para conseguir fazer tudo que preciso e quero. O foco é muito importante para que todo seu planejamento dê certo, e você precisa estar motivado para conseguir realizar todas as suas terefas.

Para meus projetos pessoais eu geralmente sou mais produtivo a noite, porém as vezes chego cansado do trabalho e sem vontade de fazer outra coisa. Nessa hora eu busco me distrair um pouco jogando ou assistindo algo, e depois eu começo a trabalhar. Isso funciona muito bem para mim, principalmente com jogos, pois eu perco até o sono. O único problema é que as vezes você pode acabar jogando até tarde e esquece de trabalhar, mas isso não é algo ruim se acontecer as vezes, afinal a gente merece descansar também!

No final de semana eu durmo até tarde, vou passear, jogo, assisto séries e filmes e tento trabalhar em meus projetos pessoais, porém sem a cobrança que me faço durante a semana. Por isso, sempre fazemos estas coisas juntos, mesmo que cada um tenha que fazer algo diferente. E funciona muito bem, pois a companhia dela é demais todos os dias =)

Por mim, nada disso funciona sem um elemento primordial: Música! Eu só consigo me concentrar com música, por isso uso no escritório um fone gigante que isola o som externo (este aqui da Philips), é muito bom e recomendo! Eu geralmente ouvia trilha sonora de filmes e jogos no Youtube (procure por OST), até fiz esta playlist com algumas que mais gostei, mas agora estou ouvindo tudo no rdio, que é fantástico. O vídeo abaixo é uma coletânea de músicas épicas, este é o meu preferido da minha playlist.

Outra coisa que faço para otimizar meu tempo é tentar fazer coisas em qualquer lugar. Por exemplo, eu leio e respondo emails no caminho para o trabalho. Quando estou em algum lugar esperando uso meu tablet para escrever algum post ou organizar minhas terafas. Quando preciso me concentrar, mas não aguento ficar em casa ou no escritório, vou para um café e levo meu tablet. Também leio bastante notícias da indústria e livros de fantasia para relaxar, quando não estou jogando no celular ou no tablet.

Existem muitas outras ferramentas para organizar seu tempo, e muitas técnicas para te manter focado. O que escrevi aqui é o que funciona comigo, mas para você pode ser diferente. Se tiver alguma recomendação fique a vontade para postar nos comentários. É importante focar, mas também saiba aproveitar os momentos para relaxar e não deixe de fazer as coisas que você tem vontade.

Como ser um programador de jogos: Você já fez um jogo?

Wed, 15 Jan 2014 00:00:00 +0000

Em primeiro lugar, peço desculpas por não ter postado nesta série nas últimas semanas. Mas agora eu voltarei a publicar semanalmente, toda quarta-feira, e no primeiro post deste ano começo com a pergunta: você já fez um jogo?

Quase todo mundo que fala que já fez um jogo, na verdade nunca fez um jogo. Fazer um jogo envolve criar o conceito, desenvolver e publicar para o mundo conhecer seu projeto e jogar. E, infelizmente, muitas pessoas não chegam a publicar seu jogo. Quando eu falo publicar, não é necessariamente vender o jogo em alguma loja virtual. Publicar é apenas tornar público, ou seja, colocar em algum site um link para as pessoas baixarem e compartilhar esta informação com seus amigos.

Geralmente, o principal objetivo em desenvolver um jogo é divertir as pessoas. Existem diversos livros como o Homo Ludens e Regras do Jogo que falam da importância dos jogos na sociedade, e não há nada mais satisfatório do que ver uma pessoa jogando algo que você desenvolveu. É por isso que entrei nesta área, e é isso que me deixa apaixonado em criar jogos e experiências para as pessoas fugirem da sua realidade e se divertirem.

Não faz sentido fazer um jogo e não divulgar para todos jogarem. Você pode fazer diversos jogos, mas uma pessoa que fez e publicou um único jogo tem um diferencial maior que o seu para trabalhar em uma empresa de jogos. Publicar um jogo também é tornar seu portifólio público, e se você quer trabalhar com jogos isto é essencial. Não importa se você acha que não vai fazer dinheiro com o seus primeiros jogos, você tem que publicar para começar a receber feedback das pessoas e validar se você está indo para o caminho certo.

Portanto, se você desenvolveu jogos e não publicou nenhum deles, você NÃO fez um jogo. E isso vale para toda forma de arte, se você não divulgar o que você faz para as pessoas verem e darem seu feedback, você não pode se considerar um artista. Não seja tímido e não tenha vergonha, mostre para o mundo seu trabalho, e então você poderá falar que faz jogos.

O meu portfólio está desatualizado desde que terminei a minha pós-graduação em 2010, então lá não estão os jogos que desenvolvi na Glu Mobile, Electronic Arts e freelances. Em breve vou montar uma página nova para mostrar todos os jogos que participei do desenvolvimento, mas por enquanto vocês podem ver o meu portfólio aqui.

Como ser um programador de jogos: Parallax

Wed, 18 Dec 2013 00:00:00 +0000

Praticamente todo jogo em 2D com visão lateral, seja o Super Mario Bros ou Mortal Kombat, possui um cenário de fundo. Este cenário não é estático, pois precisa dar a impressão de que realmente existe algo “vivo” no fundo do jogo, e que complementa a fase.

Para que o fundo mude de acordo com a movimentação do personagem, utilizando a técnica chamada de Parallax Scrolling, que consiste em movimentar a imagem do fundo de acordo com a movimentação do personagem, porém mais lento para dar a impressão de profundidade. Um dos detalhes mais interessantes do Parallax Scrolling é que quando mais imagens com velocidade de movimento diferente houverem no fundo da fase, maior será a sensação de profundidade.

O exemplo abaixo é um pseudo-código baseado na cocos2d-x que mostra como podemos implementar esta técnica, utilizando três imagens diferentes (podem ser várias imagens, depende da profundidade e detalhes que você quer).

Iniciamos as variáveis com cada imagem. Devemos ter atenção na hora de adicionar as imagens, pois na cocos2d essa ordem influência na ordem que a imagem será desenhada na tela. Neste caso queremos o pSky atrás, e as demais imagens na sua frente.

CCSprite* pSky = CCSprite::create("sky.webp");
this->addChild(pSky, 0);

CCSprite* pMountain = CCSprite::create("mountain.webp");
this->addChild(pMountain, 0);

CCSprite* pGround = CCSprite::create("ground.webp");
this->addChild(pGround, 0);

Depois de inicializar e posicionar as imagens nos lugares corretos (com o setPosition()), vem a parte da movimentação. Vamos imaginar que temos duas variáveis que nos dizem para qual lado o jogador está se movimentando, assim vamos fazer o Parallax ir para o lado correto. Também vamos imaginar que já existe uma variável com o sprite do jogadar inicializada.

void update(float dt)
{
 if (pPlayerMoveRight)
 {
 pSky->setPosition(ccp(pSky->getPosition().x + (1.0f * dt), pSky->getPosition().y));
 pMountain->setPosition(ccp(pMountain->getPosition().x + (10.0f * dt), pMountain->getPosition().y));
 pGround->setPosition(ccp(pGround->getPosition().x + (100.0f * dt), pGround->getPosition().y));
 pPlayer->setPosition(ccp(pPlayer->getPosition().x + (100.0f * dt), pPlayer->getPosition().y));
 }
 else if (pPlayerMoveLeft)
 {
 pSky->setPosition(ccp(pSky->getPosition().x + (-1.0f * dt), pSky->getPosition().y));
 pMountain->setPosition(ccp(pMountain->getPosition().x + (-10.0f * dt), pMountain->getPosition().y));
 pGround->setPosition(ccp(pGround->getPosition().x + (-100.0f * dt), pGround->getPosition().y));
 pPlayer->setPosition(ccp(pPlayer->getPosition().x + (-100.0f * dt), pPlayer->getPosition().y));
 }
}

Repare que o valor da movimentação do pSky é bem menor do que os demais. Isso influencia na velocidade do movimento, pois o que está mais afastado deve se mover mais lentamente para dar a impressão de profundidade. O resultado é que o céu irá se movimentar bem devagar, pois está mais longe, depois a montanha irá se movimentar um pouco mais rápido, mas ainda lenta por estar longe também, e o chão irá se movimentar na mesma velocidade que o jogador.

Esta técnica pode ser utilizada em praticamente qualquer jogo 2D com visão lateral, seja de aventura, corrida, luta, ou qualquer outro estilo. Alguns jogos com visão lateral e gráficos 3D (o que chamamos também de 2.5D) utilizam essa técnica com modelos ao invés de imagens, o que aumenta a profundidade. Um exemplo é o Trine, que possui jogabilidade 2D com gráficos 3D, e podemos ver claramente o Parallax feito com modelos 3D no video abaixo.

Mais informações sobre o Parallax Scrolling e fonte das imagens na Wikipedia.

Como ser um programador de jogos: Game Design Document

Wed, 11 Dec 2013 00:00:00 +0000

O Game Design Document (GDD), é um documento escrito pelo Game Designer para os programadores e artistas entenderem sua visão da mecânica do jogo. Este documento é muito importante, mas infelizmente é tão ignorado quanto o próprio Game Designer.

Muita gente acha que o GDD é praticamente a mesma coisa que a especificação técnica que um analista de sistemas escrever ~~depois~~ antes da equipe começar a fazer o projeto. Ambos são documentos que devem ser escritos antes do desenvolvimento do projeto, porém o GDD não é definitivo e pode ter constantes mudanças, pois algumas coisa no jogo podem não sair como foi esperado, e neste caso mudanças são necessárias.

Nas primeiras fases do desenvolvimento, enquanto a equipe está trabalhando no protótipo junto com o Game Designer, ele está escrevendo o GDD e definindo todas as mecânicas e features do jogo. Pode ser que após o término do protótipo, usado para apenas para validar a mecânica básica do jogo, muita coisa tenha mudado, e o Game Designer deve manter o GDD sempre atualizado, e sempre pedir para a equipe acompanhar as atualizações.

Na Glu Mobile, todo GDD é uma página na wiki interna, e todo mundo da empresa tem acesso para ler e conhecer mais sobre os jogos. É muito legal este tipo de documento por ser uma página onde todos podem editar e ver as alterações, as vezes mais prático do que compartilhar um o GDD usando o Google Drive ou Dropbox, por exemplo. Eu achava muito legal, e passava horas lendo o GDD de outros projetos!

Compartilhar um documento funciona bem neste caso, pois geralmente a equipe não vai editá-lo, irão apenas visualizar seu conteúdo, por isso não é normal acontecer problemas de mais de uma pessoa editar ao mesmo tempo. Independente da maneira que você irá fazer o GDD, faça e sempre avise a equipe que nova alterações foram feitas, não espere que todo mundo irá sempre ler este arquivo para ver se algo mudou. Mesmo tendo um documento, é bom conversar sobre seu conteúdo em reuniões, para ter certeza de que todos entenderam a visão do Game Designer.

A organização do documento é algo que não tem um padrão, mas existem diversas sugestões. Meu modelo favorito é o apresentado pelo Scott Rogers, no livro Level Up: Um guia para o design de grande jogos. Quando fiz meu TCC na pós-graduação em games, o jogo Oniro, usei o modelo do livro Game Design Workshop, da Tracy Fullerton, e você pode baixar o GDD que escrevi clicando aqui.

Existem diversos modelos de GDD espalhados por ai, porém vale lembrar que nada em um modelo de GDD é obrigatório ou deve ser usado sempre. Você deve analisar estes modelos e ver o que se adapta melhor ao seu jogo, e preencher apenas estes itens. Se algum item do GDD não será usado, ou não faz sentido manter, remova do seu documento para deixar tudo mais organizado e apenas com informações úteis. Não adianta escrever 100 páginas se a equipe não vai ler, por isso existem dicas legais no livro do Scott Rogers para fazer uma versão menor para facilitar a apresentação da ideia do jogo.

A partir do GDD, também, o produtor ou o próprio Game Designer pode criar a lista de tarefas de cada área, o que facilita muito o processo de desenvolvimento. Em muitas empresas é comum programadores e artistas ajudarem o Game Designer no começo do documento, principalmente apontando as limitações técnicas da ideia antes de começar a fazer ou durante o desenvolvimento do protótipo.

Como em qualquer equipe, para qualquer projeto, a chave do sucesso é uma boa comunicação entre todos os membros de forma clara e transparente. Não tenha medo de compartilhar o GDD com a equipe, ele não deve ser um segredo guardo apenas para o Game Designer.

Como Programar Jogos · Game Developer

SDL3 com Visual Studio, git submodule, e GitHub Workflow

SDL como dependência usando git submodule #

Criação de um projeto no Visual Studio #

Novo projeto no Visual Studio #

Adicionando código #

Adicionando SDL como dependência #

Rodando o projeto #

Automação com GitHub Workflow #

Conclusão #

Hello World usando SDL no Visual Studio

Configuração no Visual Studio #

Hello World #

Cuidados #

Conclusão #

Cursos e tutoriais para aprender a programar jogos

Conhecimento Básico ou Nenhum #

Conhecimento Intermediário à Avançado #

Conhecimento Avançado e Específico #

O que mais posso fazer para aprender? #

Como ser um programador de jogos

Como ser um programador de jogos: Design Patterns

Como ser um programador de jogos: Programando com estilo

Como ser um programador de jogos: Avaliando um framework

Como ser um programador de jogos: Mantenha tudo simples

Como ser um programador de jogos: Por onde começar a programar um jogo

Como ser um programador de jogos: Transformando jogo em produto

Como ser um programador de jogos: Definição de prioridade de tarefas

Como ser um programador de jogos: 200 mecânicas de gameplay

Como ser um programador de jogos: Feedback de ações para o jogador

Como ser um programador de jogos: Boas práticas para animações 2D

Como ser um programador de jogos: Pixel Perfect

Como ser um programador de jogos: Jogue bastante, mas jogos diferentes

Como ser um programador de jogos: Gerenciamento do seu tempo

Como ser um programador de jogos: Você já fez um jogo?

Como ser um programador de jogos: Parallax

Como ser um programador de jogos: Game Design Document

SDL como dependência usando git submodule
#

Criação de um projeto no Visual Studio
#

Novo projeto no Visual Studio
#

Adicionando código
#

Adicionando SDL como dependência
#

Rodando o projeto
#

Automação com GitHub Workflow
#

Conclusão
#

Configuração no Visual Studio
#

Hello World
#

Cuidados
#

Conclusão
#

Conhecimento Básico ou Nenhum
#

Conhecimento Intermediário à Avançado
#

Conhecimento Avançado e Específico
#

O que mais posso fazer para aprender?
#