Loodo

Se você é um desenvolvedor hobbista, que nunca trabalhou ou numa empresa ou em um projeto de jogo mais formal talvez não saiba, mas uma das primeiras coisas que deve ser pensada, num projeto de desenvolvimento, é o pipeline de produção, essencial ao bom andamento do projeto e, acredite, na felicidade das pessoas da equipe! Afinal, ninguém quer ter o seu trabalho arruinado por um arquivo perdido, não é verdade?

Apesar do nome bonito, esta organização já é muitas vezes feita, mesmo que de maneira improvisada, por times de desenvolvimento. O cenário é o seguinte, você é um desenvolvedor, que se juntou com seu amigo artista para fazer um clone de Space Invaders, só que com gráficos mais bonitinhos. O desenvolvimento vai caminhando tranquilamente com você fazendo o jogo no seu computador, seu amigo mandando as imagens por e-mail, e você mandando algumas versões do jogo para ele ver como ficaram as artes - ou até mesmo mandando apenas alguns screenshots.

Tudo vai muito bem, e funciona para vocês. Ao terminar este projeto vocês querem fazer algo mais desafiador, digamos, um shooter vertical, e entra na jogada mais um artista, que vai dividir o trabalho com seu amigo. Tudo continua na mesma, só que agora temos mais um e-mail na jogada. No meio do caminho um outro amigo seu, que viu o primeiro jogo e gostou muito quis entrar no barco, o time aceitou pois o trabalho é muito grande. Mas, e agora? Como dividir exatamente os pedaços do código que cada um deverá alterar? E quando os artistas gerarem as imagens, terão que mandar para os dois? E se o projeto não compilar porque o outro desenvolvedor esqueceu de mandar um arquivo? Pior ainda, e se a ferramenta utilizada armazena todo o projeto dentro de um único arquivo binário, e vocês dois precisam meter a mão nele?

Agora pense neste cenário com mais um desenvolvedor. Complicado, não? E pode ficar ainda mais. Este exemplo serve para mostrar o quão caótico pode ficar um projeto onde não houve um cuidado em definir um pipeline, uma linha de produção.

O termo em inglês surgiu para ilustrar a integração de várias equipes, envolvidas em várias etapas do desenvolvimento de um jogo, deixando claro as dependências entre elas e em que direção deve fluir a produção. Agora você conseguiu visualizar um encanamento, cheio de conexões?

Pode parecer complicado, mas na verdade não é. Definir um pipeline depende em boa parte de conhecer as ferramentas certas, ou pelo menos de entender as suas necessidades para procurar as ferramentas adequadas. Por exemplo, num time como o inicialmente citado acima, com duas pessoas, a organização inicial era suficiente e não impactava na produtividade. Mas faltou reavaliar as necessidades ao aumentar a equipe.

Mas então, quais deveriam ser as suas preocupações? Basicamente, estas:

• Controle de versão
• Atomicidade dos artefatos
• Estrutura de pastas e arquivos
• Geração do executável

Explicando abaixo.

Controle de versão consiste em um servidor que armazena arquivos, provendo diversas funcionalidades como manter várias versões para cada arquivo, controle de acesso, detecção de conflitos, etc. Basicamente ele serve como um lugar - preferencialmente remoto - onde todos do grupo podem acessar e lá colocar os arquivos do projeto. Tanto os fontes quanto os binários. O controle de versão, de fato, serve para você garantir um histórico do desenvolvimento e poder desfazer quaisquer erros que apareçam no projeto. E o controle de acesso pode proibir que mais de uma pessoa mexa no mesmo arquivo, afim de não gerar conflitos de versões, e mesmo se estes aconteçam, a ferramenta ainda provê meios de resolvê-los.

Os mais famosos são CVS, SVN e agora o GIT. Os dois primeiros são oferecidos hoje em dia pela maioria dos provedores de hospedagem, nacionais e internacionais, enquanto que o último foi criado por Linus Torvalds para desenvolvimento do kernel do Linux, e ganhou mais divulgação ao ser escolhido pelo  Google para seus projetos mas ainda está buscando um lugar maior ao sol. Contudo, além destes existem alguns outros que possuem pontos fortes e fracos, e que se lhe for interessante basta se informar para avaliar.

A atomicidade dos artefatos é uma questão que está diretamente ligada com a anterior, pois algumas ferramentas costumam organizar seus projetos de forma fechada, não dando acesso a arquivos isolados, de forma que não adianta muita coisa colocá-lo sob controle de versão, se várias pessoas não poderão mexer nele simultaneamente.

Como exemplos destas ferramentas podemos citar o GameMaker, que mantém os scripts e todas as outras informações do projeto dentro de um arquivo GMK. Apenas as imagens ficam em um diretório à parte. Quem também fazia a mesma coisa era a IDE Unity, mas com a versão 2.6 a coisa mudou de figura. Além de se tornar gratuita ela passou a salvar os arquivos JS (JavaScript) separadamente, de forma que várias pessoas possam trabalhar, cada uma delas, em arquivos separados, dentro do mesmo projeto.

Não tanto crucial, mas que poupa um bom trabalho, a definição da estrutura de pastas e arquivos serve para facilitar a troca de informação entre as equipes, pois cada uma delas sabe exatamente onde aquele tipo de arquivo deveria estar, e o nome dele deixa claro a sua função/conteúdo. Coisas como “textura.png”, “textura nova.png” e “Cópia de textura nova.png” não inspiram muita confiança, certo? Assim como encontrar um arquivo de script dentro de uma pasta “docs”, e pior ainda, que continua sendo atualizado diariamente. Evite dores-de-cabeça, pesquise a melhor organização para o seu time e a ponha em prática.

Por fim, mas não menos importante, a geração do executável deve estar acessível a todos do grupo. Ou seja, qualquer um da equipe pode baixar o código do repositório (servidor), e gerar o executável - seja através da mesma ferramenta que o time de desenvolvimento usa ou através de uma simples linha de comando. Esta é mais uma característica que depende da ferramenta escolhida para desenvolvimento.

Finalmente, não deixe a empolgação do início do projeto atrapalhar seu planejamento. Lembre-se, qualquer esforço despendido com planejamento nunca é um desperdício de tempo. Muito pelo contrário.