Dicas de John Romero para desenvolver jogos

John Romero, co-fundador da Id Software e criador dos jogos DOOM e Quake, entre muitos outros, deu uma palestra em um evento da revista britânica Develop e falou sobre algumas técnicas para desenvolvimento que ele sempre usou, muitas indo contra ao que encontramos nos livros. Abaixo estão algumas frases que retirei do texto, a notícia completa pode ser lida aqui.

“No prototypes,” he said. “Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.

Tradução:

“Sem protótipos”, ele disse. “Apenas crie o jogo. Faça polimento durante o projeto. Não conte com o polimento acontecendo mais tarde. Sempre tenha código pronto para ser lançado.”

Na continuação do texto ele fala que se existe muito dinheiro e pessoas envolvidas, que provavelmente haverá um protótipo, mas quando se é pequeno e independente (como ele era). Segundo Romero, o melhor é sempre desenvolver algo final ao invés do ciclo que normalmente inicia com um protótipo, que então é descartado para desenvolver o jogo, e após o desenvolvimento estar completo entra na fase de polimento.

Isso faz muito sentido quando pensamos em empresas pequenas e independentes, mas é claro que existe um risco da equipe desenvolver um jogo se que muitas perguntas importantes tenham sido respondidas na fase de protótipo. Acho que se o game designer tem experiência, e o jogo está bem claro para a equipe, este é um risco que pode ser tomado. Muitas vezes não há tempo suficiente para fazer um protótipo, por isso é comum mesmo as empresas partirem para o jogo final desde o começo.

“As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs, your new code will be built on a buggy codebase and ensure an unstable foundation.”

Tradução:

“Ao encontrar um bug, corrija-o. Não continue o desenvolvimento. Se você não corrigir seus bugs, you novo código será escrito em cima de um projeto com problemas e resultando em uma base instável para o jogo”

Romero diz que não devemos perder o tempo de outras pessoas, se você encontrou um bug ele deve ser corrigido antes de prosseguir. É comum o programador saber que existem bugs mas envia o jogo para a equipe de testes sem falar nada, esperando que eles encontrem para ele corrigir após o bug ser “oficial” e estar anotado em algum lugar.

Novamente, esta é uma dica para pequenas empresas, pois não possuem processos burocráticos. Mas, independente do tamanho da empresa e do projeto, todo bug deve ser sempre corrigido, especialmente se for seu. Ou, se não houver tempo, pelo menos informe a equipe de testes (ou a pessoa que vai testar).

“Write your code for this game only – not for a future game. You’re going to be writing a new code later because you’ll be smarter.”

Tradução:

“Escreve seu código para este jogo apenas - não para jogos futuros. Você irá escrever um código novo depois pois você terá aprendido mais”

Muitos programadores, não só da área de games, se preocupam em fazer um código que poderá ser utilizado por vários projetos depois. Isto é uma preocupação válida, mas quando não se tem muito tempo não devemos nos preocupar em criar um framework antes de criar o jogo em si. E a segunda parte que ele disse é verdade, provavelmente você irá escrever um código melhor na segunda vez.

Em empresas grandes existem até equipes desenvolve ferramentas e frameworks para que as equipes que desenvolvem os jogos consigam focar em fazer o jogo.

O texto contém mais detalhes e dicas, e vale muito a pena ler. John Romero é um grande game designer, e sempre podemos aprender muito com desenvolvedores experientes como ele.