Pensando nisso e aproveitando para responder a pergunta do nosso incauto leitor, resolvi escrever um roteiro para o DD, atualizando bastante um que eu mesmo já escrevi a um tempo atrás aqui na CubaGames, com as nossas experiências no desenvolvimento de jogos.

Mas antes de começar o roteiro para o DD, vamos falar um pouco de escopo de projeto.

Todo o jogo é um projeto e todo projeto tem um escopo.

Essa é a premisa basica antes de começar a desenvolver o seu jogo. Escopo é, basicamente, o que o seu jogo vai ter e o que ele não vai ter. Só começe a escrever o seu DD quando tiver essa idéia bem clara. Faça reuniões com a sua equipe (ou com os seus amigos se estiver fazendo o jogo sozinho) para que eles te digam se você está “pirando” demais, ou se está fazendo um jogo muito pequeno. Escute as opiniões de várias pessoas, procure na internet pense nas suas capacidades (de forma realista) e depois de tudo isso defina o que o seu jogo vai ter e o que ele não vai ter. Daí você terá um escopo. A quantidade de trabalho que você tem quase certeza de poder cumprir. Depois do escopo bem definido vamos começar o trabalho de especificação do Jogo.

O roteiro que eu vou colocar aqui é o do DD que usamos atualmente na CubaGames. Se ele não se adaptar a sua realidade, mude, adapte, peça ajuda para nós, ou até mesmo não use nada do que está aqui. Você como Game Designer tem todo o direito de fazer isso.Vou separar o roteiro por tópicos que espelham o que está no DD.

Introdução – Na introdução é importante que você resuma o conteúdo do seu DD e também descreva o seu jogo, mas bem simplificadamente, para dar uma idéia rápida do jogo para quem lerá o seu DD. Na introdução também é onde normalmente se coloca a descrição dos tópicos do seu DD, ou seja, sobre o que cada um dos itens do seu DD vai tratar. A introdução serve, basicamente para que a pessoa se interesse pelo seu DD e vá buscar mais informações no resto do documento. Isso significa que é aqui que você venderá o peixe do seu jogo.

Jogos Similares – Descreva os jogo que são parecidos com o seu e também as suas fontes de inspiração. Pode ser que o seu jogo seja conceitualmente inovador, mas pelo menos alguma inspiração de cenário, personagens e métodos você tem que deixar para o seu leitor, já que ele não está dentro da sua cabeça para ver o que você imagina.

Conceito – Aqui você vai descrever “o que” você quer que o seu jogo passe. Qual a idéia central do jogo, por qual o motivo alguém jogaria o jogo, quem jogaria o seu jogo. A descrição de um publico-alvo é importante, e não vale escrever “para todos os públicos” todos os jogos tem um direcionamento, seja uma classe de pessoas, seja uma idade, seja um estilo. Podem ser vários grupos, mas nunca todos.

Especificações – Aqui você vai descrever as regras do seu jogo. Todos os elementos dele tem que ser descritos aqui, por exemplo, se nós tivéssemos acesso ao DD do Street Figther IV, veríamos aqui a descrição detalhada de cada um dos jogadores (pode-se adicionar desenhos conceituais também), descrição do sistema de luta, descrição da barra de energia, descrição do conceito dos especiais e mais todos os elementos que fazem parte do mundo do Street Fighter IV (pode contar até um pouco de história aqui). Nesse tópico você também deve escrever elementos de apoio ao seu jogo tais como: Websites, rankings externos e manuais disponíveis. Quem ler esse tópico deve sair daqui com uma idéia bem formada de como o seu jogo funciona e o que ele vai conter. Aqui também se coloca a informações técnicas do jogo, tais como: linguagem de programação, 3D ou 2D, banco de dados, servidores necessários, configuração para rodar o jogo, video games que rodam o jogo, algoritmos de inteligência artificial conhecidos, engines utilizadas e todas as outras informações de caráter técnico.

Desenvolvimento – A parte toda de cronograma vai estar nesse tópico. Sempre tente dividir o seu jogo em várias tarefas. Dando como exemplo novamente o Street Figther IV, vamos imaginar algumas tarefas do seu desenvolvimento. Normalmente, depois de escrever o DD, a equipe responsável se reúne para discutí-lo. Isso é uma tarefa. A revisão depois da reunião é outra tarefa. A pesquisa para a identidade visual dos personagens é de outra tarefa, o desenho conceitual dos personagens, a animação básica, a animação completa, a programação dos movimentos, os testes de jogo e a campanha de marketing também são outras tarefas. Para cada uma das tarefas você tem que definir um prazo. Como definir esse prazo corretamente? Só com experiência. Sua experiência e também perguntando para outras pessoas que fizeram coisas parecidas, pois não existe livro nenhum que ensine a fazer prazos. Normalmente, nos meus DD eu divido as tarefas que tem o mesma “classe” (como “desenho conceitual” e “pesquisa de identidade visual”) somente para questões de divisão de tarefas entre a equipe, mas lembre-se, isso é uma prática adotada por mim na CubaGames, não é obrigatória, se achar isso bom faça assim, senão somente divida as tarefas.

Metodologia de Mercado – Essa é parte que você deve convencer alguém (ou a você mesmo) de como esse jogo irá gerar dinheiro. Seja com propaganda ingame, venda em caixinhas, venda pela internet, venda de itens ou até mesmo se ele for gratuito você descreve aqui, pois você tem que definir que ele realmente é gratuito. Demonstre gráficos de projeção, explique os preços, some os valores, mostre os custos, calcule o ponto de equilíbrio (entre custos e ganhos). Se achar necessário também descreva aqui como será a sua campanha de divulgação do jogo.

Normalmente também se coloca um apêndice com coisas que não se encaixam em nenhum dos tópicos anteriores, tais como: conceitos do logo do jogo, storyboards de elementos muito específicos, descrição de itens especificos e qualquer outra coisa que você ache que é importante para o seu jogo.

O roteiro para o DD é “só” isso. Se tiver qualquer dúvida, crítica, sujestão ou melhoria é só comentar. Estamos aqui para melhorar o nosso trabalho e ajudar quem quiser a também melhorar o seu trabalho.

PS.: Um Modelo de DD em Word para quem quiser dar uma olhada na formatação e detalhes assim.

Na ultima parte, falei um pouco sobre algumas linguagens mais comuns no mundo dos jogos, útil para quem quer começar o jogo do zero. Mas hoje, vou falar um pouco sobre as engines que facilitam o desenvolvimento de um jogo. O Romulo já explicou o que elas são, então não vou me extender muito na explicação, só vou linkar algumas que eu acho interessantes. Se algum comentarista conhecer alguma outra, pode avisar que eu coloco um update no post. Vou começar pelas engines gráficas, passar pelas de som, física e inteligência artificial e terminar nas de rede.

Gráficas:

Ogre3D – O Object-Oriented Graphics Rendering Engine (OGRE) é uma engine escrita em C++ para facilitar o desenvolvimento de aplicações gráficas em 3D. A Ogre3D não é somente para o desenvolvimento de jogos, mas sim para todo o tipo de desenvolvimento que utilize gráficos 3D. A engine está sobre a licença GNU, então pode ser utilizado sem custo (sobre os limites da licença). A documentação no site é extensa e vale a pena uma olhada no Wiki da engine, para entender como funciona, como foi feita e o que fazer para começar.

Agar – A Agar é uma engine gráfica portável (independe de sistema operacional) que utiliza OpenGL e SDL para realizar os gráficos. A licença de uso é a BSD License.

Som:

Aztica 6DX - Uma engine completa, que trabalha utilizando o DirectX e COM. Com essa engine você pode fazer um jogo completo, mas a parte de som dela é ótima e pelas informações que consegui (nunca a utilizei), pode ser utilizada independentemente.

Física:

PhysX – Uma das melhores engines de controle da física do jogo, essencial para jogos 3D. A lista completa dos jogos que utilizam essa engine pode ser encontrada aqui. Essa engine pode ser utilizada inclusive para jogos de celular. Ela é ótima, mas tem um problema, é paga. Vale para quem tem grana para começar o jogo (quase impossível aqui no Brasil, mas nunca se sabe).

Inteligencia Artificial:

OpenSkyNet – Com um nome muito sugestivo, essa engine de licença livre ainda está em desenvolvimento, mas já tem os algoritimos de pathfinder (busca de caminhos) funcionando. A visita ao site vale também para baixar os fontes para quem tem curiosidade de como funcionam alguns processos da IA.

Rede:

RakNet - A melhor engine de rede para jogos disponivel atualmente é a mais conhecida de nós da CubaGames, pois foi nela que nos inspiramos para fazer a nossa engine de rede (que ainda não ficou pronta). Com essa engine o programador não se preocupa mais se ele está desenvolvendo para um jogo single ou multiplayer. A engine deixa tudo transparente ao desenvolvedor. Ótima para quem não quer se preocupar com isso. Mas ela é paga, então, cuidado ao fazer o download.

Bom, essas são as engines que eu conheço e pesquisei agora. Se alguém conhecer alguma outra, por favor avise! Estou esperando. Até a próxima parte!

Update: Blog com artigos da Game Engine Blender. Tem até tutorial!

C++ – Todo mundo que cursou algum curso de informática, engenharia e afins viu no minimo o pai dessa linguagem, o C. Muitas engines foram escritas nessa linguagem e muitos jogos ainda hoje são escritos em C++. É uma linguagem muito poderosa, com muitas bibliotecas já prontas, testadas e em uso. A sua bibliografia é extensa, e existem MUITOS tutoriais de C++ na internet. Mas ela não é uma linguagem para quem está começando a programar, pois ele é uma linguagem com muitos detalhes que podem confundir os iniciantes (vide os ponteiros e a orientação a objeto). Só para constar, o SDL é escrito em C++.

JAVA – Uma das linguagens mais bem falada dos ultimos tempos é uma linguagem robusta e portavel, o que significa que pode ser colocada em qualquer equipamento eletrônico, desde relógios a ônibus espaciais. É uma linguagem muito utilizada atualmente para se desenvolver jogos para dispositivos móveis, em especial celulares. O mercado de jogos para dispositivos móveis cresce a cada dia, então essa linguagem é uma boa para quem pensa em fazer o seu jogo para esse tipo de mercado.

Phyton – O Phyton é uma linguagem extremamente portável também, mas bem mais simples de se aprender do que o JAVA. Ela é um pouco mais desconhecida que as outras duas que eu citei, mas é bem utilizada quando se desenvolve jogos mais voltados para o mundo do software livre. Existem muitos tutorias na internet que ensinam a programar em Phyton e por acaso tem um deles que ensina a fazer um jogo em Phyton. O jogo implementa até um tipo de inteligência artificial, vale a pena dar uma olhada.

Lua – Uma linguagem desenvolvida no Brasil (pessoal da Tecgraf para um projeto para petrobrás) que atualmente é muito utilizada para se fazer jogos por sua simplicidade e velocidade no desenvolvimento de aplicações. Segundo a Wikipédia, dois jogos da Lucas Arts foram desenvolvidos em Lua: Escape from Monkey Island e Grim Fandango. Mais informações sobre a linguagem Lua podem ser encontradas no site oficial.

Sabendo esse pouquinho sobre cada uma dessas linguagens ainda não é o bastante para começar a fazer um jogo, mas é o bastante para começar uma pesquisa a fundo de cada uma dessas linguagens e escolher a melhor para o seu “perfil de programador” e para o seu jogo.

Na próxima parte, vou falar sobre as engines mais famosas que existem por aí. Até!

Update: Todas as linguagens acima são de uso livre, aproveitem.

Primeira coisa, você vai usar uma engine (se não sabe o que é uma engine, leia esse post) ou vai fazer o jogo na “mão”, ou seja vai usar algo que já está pronto ou fazer você mesmo? Cada uma das opções tem os seu prós e contras, então vamos a eles:

Engine
Prós:
– Já tem a maioria das funções básicas prontas, você não irá perder tempo fazendo elas;
- Já foi testada;
- Muitas delas são utilizadas em jogos de renome;
- Algumas até dá para usar como propaganda (“Mesma Engine do Quake 3″).

Contras:
- Tempo de aprendizado;
- Tempo de adaptação da Engine ao seu jogo;
- Bugs não resolvidos na Engine que podem tomar MUITO do seu tempo para contorná-los;

Fazer sozinho:
Prós:
– Vai fazer só o que necessita para o seu jogo e por consequência utilizar só isso;
- Será personalizado;
- Você irá saber (a maoria) dos problemas que o seu jogo tem, e vai ter uma idéia de como resolvê-los.

Contras:
- Leva muito tempo para fazer as coisas básicas;
- Você vai reinventar a roda do seu jeito;
- Os testes tem que ser muito mais pesados, já que ninguém nunca usou antes.

Esses prós e contras, são só os que eu achei na minha experiência em fazer jogos. Mas mesmo assim eles já pesam bastante na escolha do que fazer.
Então, escolha com cuidado.

No proximo post, vou falar um pouco sobre as engines mais conhecidas e também um pouco sobre linguagens de programação para jogos. Até!

Projetos de jogos, normalmente são chamados de Game Desing e, por consequência, o documento que especifica o projeto é chamado de Design Document (já falei sobre ele nesse post, mas vale a pena reforçar e atualizar o conhecimento).
O Design Document é aonde você vai transformar a sua ideia em realidade, pois nele vão estar descritos todos os aspectos do seu jogo, desde a descrição do universo ao som utilizado quando o personagem principal morre.
Se você tiver algum investidor de olho no seu jogo ele provavelmente irá pedir para ver o seu Desing Document, pois é lá que ele vai validar a viabilidade econômica do seu projeto e ver se o investimento tem possibilidade de retorno. Logo o seu Design Document deve ser realista, preciso e completo.

Então vamos as partes mais comuns e importantes de um Design Document:

Conceito: Apresentação do universo do Jogo, da mecânica do jogo, da história, do público-alvo e do estilo do jogo. Cada um desses tópicos deve ser amplamente discutido e demonstrado deixando-se bem claro qual é o seu jogo e qual a ideia que ele quer passar aos jogadores. Nessa parte é aonde você vai “vender o seu peixe” e também ditar o escopo do que vai ser realizado no jogo. Nada mais que aquilo que você colocar aqui deve ser desenvolvido, com o risco do projeto inteiro ser comprometido.

Especificações Técnicas: Descrição do Hardware e o Software necessários para o jogo. Se o seu jogo tem três configurações de Hardware (minima, recomendada e ótima) você coloca aqui, e se achar necessário, explica “o por que” dessas três configurações.

Especificações do Jogo: Os dados do jogo vão aqui. Número de vidas, de personagens, modos de jogo, sistema de pontuação, definição das cameras, itens, cenários, fases, tabelas de evolução. Os conceitos que você criou para o jogo serão definidos e explicados aqui. Se você criou uma regra revolucionária para a evolução dos Personagens, é aqui que você a explica. Se o seu jogo é uma simulação, é aqui que você vai descrever as regras do que ele simula. Bom, defina todos os detalhes do seu jogo aqui.

Especificações da Arte: Storyboards, descriação dos layouts dos cenários e descrição do clima do jogo (terror, suspense, aventura). É aqui também que você anexa o roteiro do seu jogo.

Especificações Sonoras: As músicas para cada cenário e os efeitos sonoros do jogo são definidos e demonstrados aqui (o seu Design Document pode acompanhar um CD com a demonstração dos sons) .

Desenvolvimento: Essa é a parte mais chata trabalhosa do Design Document. Aqui vão o Cronograma, as metas, a descrição das tecnologias utilizadas, descrição das tarefas a serem realizadas, descrição da equipe realizadora (ótimo artigo do Romulo sobre como motivar a equipe), analise dos riscos, diagramas(UML, DER, Gantt, etc), demonstrativo de custos e mais muitos outros itens comuns a projetos de software (esses itens podem ser encontrados em livros que ajudam a desenvolver projetos de jogos) (sim, ler livros também ajuda).

O Design Document é um documento trabalhoso de ser escrito. Um bom Design Document pode levar meses para ficar pronto. Mas ele é o que direciona o desenvolvimento de um jogo com alguma pretenção de retorno, sem ele é muito difícil fazer um jogo de qualidade.

Na próxima parte começamos a falar sobre “mão na massa”.

Um jogo, tal como qualquer outra coisa que vai ser desenvolvida, é um projeto e um projeto bem estruturado, tem grandes chances de se atingir sucesso, ou seja, o seu jogo será um produto real e quem sabe, “vendável”.

E primeiro de tudo, quais são as fases que todo (eu falei TODO) deve seguir?

- Conceito: é nessa fase que você tem uma ideia, a elabora e a viabiliza;
- Planejamento e Organização: é nessa fase que você escreve o projeto propriamente dito;
- Implementação: aqui você desenvolve o projeto (constroi o foguete, limpa a casa, faz o jogo, etc);
- Encerramento: aqui se avaliam os resultados e a “medida” de sucesso;

Todo o projeto que deseja ter algum nível de sucesso deveria passar por todas essas fases (alguns pulam a segunda e dão certo, mas é por sorte, não por competência).

Além dessas fases (que são o Ciclo de Vida do projeto) existem elementos que todos os projetos devem ter:

- Partes Envolvidas: Cada competência necessária para o bom desenrolar do projeto. Normalmente essas competências são o Gerente, o Cliente e a equipe de desenvolvimento. Dependendo do projeto podemos ter mais competências. E ainda uma pessoa pode todas as competências, o que ocorre normalmente em projetos de jogos independentes.
- Escopo: Todo o bom projeto tem uma lista de coisas a fazer. E essa lista tem que ser bem definida para que não aja trabalho desnecessário, ou até mesmo perda de trabalho quando estiver no meio do projeto.
- Prazo: Projetos tem prazo finito. Projetos sem prazo não são projetos, e sim “zonas generalizadas que nunca ficam prontas”. E para o controle desse prazo, se montam cronogramas (nos próximos posts dessa série, falarei mais sobre eles) que devem ser realistas e atingiveis. De nada adianta um cronograma que diz que leva dois dias para se realizar uma tarefa, se na verdade ela leva vinte. E o caso contrário também é válido.
- Pessoas: Pessoas são essenciais, e o controle dessas pessoas é o que vai mais pesar no sucesso ou falha do projeto. Quanto mais pessoas mais difícil controlar e organizar, mas isso não quer dizer que um projeto com um única pessoa é simples. O “Auto-controle” é uma disciplina rara e muito valiosa.

Esses dois tópicos (Fases e Elementos) são o básico que todo mundo precisa saber sobre projetos, e a partir disso podemos começar a transformar a nossa ideia de jogo em uma coisa mais factivel e ainda aumentar a sua chance de sucesso.

O artigo anterior, já é uma grande parte da fase do Conceito do projeto. E no próximo artigo, vou mostar o documento mais usado para se descrever um projeto de jogos, o Design Document.

E se quiserem saber mais sobre projetos, o PMI é a referência mundial.

São duas perguntas:
- Quero ganhar dinheiro com isso?
- É viavel fazer isso?

As respostas a essas duas perguntas é que vão direcionar o tipo de jogo que você quer fazer.

Sobre a primeira pergunta:
Não adianta querer fazer um jogo exatamente do jeito que você acha extremamente legal, com todos os elementos que você acha legais, juntando conceitos de 10 outros jogos que você acha que ficariam geniais e mais toda a tranqueira que o desenvolvedor de jogos quer fazer, se isso não vende. Se você pretende viver de fazer jogos (não só fazer jogos por prazer e para mostrar aos amigos) esse jogo vai precisar vender. Sempre analise a sua ideia antes de começar a fazer o jogo. Sempre pense em como você vai vender aquilo, se alguém quer comprar aquilo, se o mundo está preparado para o seu jogo. Como você vai saber isso? Google, ou seja, pesquise muito, faça enquetes no Orkut, faça perguntas em foruns, entre nos Blogs de Jogos, pegunte para os seus amigos, seus colegas de aula, colegas de trabalho, irmãos, pais, parentes, todo mundo que estiver disponível. Só assim você vai ter uma ideia se o jogo tem chance de vender ou não. Mas, se você não quer vender, está liberado para fazer o jogo que quiser, como quiser, contanto que a segunda pergunta seja um “SIM”.

Sobre a segunda pergunta:
Sempre pense se você pode fazer o jogo que você quer fazer pode ser feito dentro da sua realidade. Se você é um designer que sabe fazer super animações e desenhos “muito massas”, mas não sabe programar, ou sabe programar um pouco, não tente fazer um WoW da vida, com uma lógica interna de gerenciamento de memória e de gasto de rede soberbas (na verdade não tente fazer um jogo desse porte sem ter uma equipe). O caso inverso também é verdadeiro, ou seja, programadores não são designers. Existem outras limitações também: falta de conhecimento em certa área específica e o a pior de todas as limitações (até os grandes sofrem com isso) o recurso financeiro. Por tudo isso, pense bem como vai ser o seu jogo antes de começar a faze-lo. A frustração de ter que parar no meio por descobrir que não vai conseguir fazer por alguma dessas limitações é muito maior que se parar no meio do desenvolvimento do jogo.

Por hoje é só isso…
Na próxima parte vou falar de Planejamento e Documentação.