Tutorial: A equipe do Projeto Parte 1

A idéia inicial quando se trabalha em um projeto, é ter uma equipe composta por pessoas responsáveis e capacitada para determinar funções. Pensando num projeto de games amadores, é de se pensar que uma equipe não é necessária, levando em consideração a abrangência desse tipo de game. Mas é aí justamente que entra o maior erro de todos. Dificilmente alguém entende das quatro vertentes básicas no desenvolvimento de games. Em geral só se é especializado em uma delas. Com o passar do tempo, obviamente essa defasagem vai se evidenciando, desanimando assim seus desenvolvedores. Aí o projeto que era lindo, morre.

Costumo dizer que a cada 50 projetos apenas um chega a ser lançado de forma final. E em geral, esse é um game feito por uma pessoa, ou uma equipe pequena composta de no Maximo três pessoas. Jogos em equipes com mais de três pessoas geralmente falham. Mas quais os motivos que levam a isso?

A primeira vista, se deve deixar bem claro qual é a função de cada um dentro de uma equipe. Deve ficar claro para todos os membros a sua posição dentro do projeto e também que existe uma hierarquia. Sim, a parte polêmica da coisa, a hierarquia.
A hierarquia deve existir dentro de uma equipe. Ela deve ser composta, não apenas por um "chefe", mas sim por toda uma rede de gerencia. Pensando numa equipe de jogos, que segue quase sempre algo que vai sendo feito pelas coxas, parece inviável ou mesmo muito burocrático esse pensamento. Mas ele é necessário. A partir do momento que uma equipe é formada, é necessário eleger lideres para determinadas funções. Pessoas que além de delegar funções, devem centralizar as produções para repassar ao gerente do projeto.

Para ficar mais fácil de entender, vou colocar aqui um esquema de organização de equipe:



Com essa pirâmide, quero mostrar qual a relação entre quantidade de pessoas e grau de hierarquia.

Em geral temos um gerente de projeto, pessoa que faz parte da equipe estratégica, a qual tem a função de ditar os rumos do projeto. Entenda isso como uma definição de coisas macros relacionados do projeto, como por exemplo, temática do projeto versus o estilo gráfico adotado. É nesse nível que se tem a menor quantidade de pessoas. É neste lugar fica o game designer, a grande mente por traz do projeto.

Quando descemos pela pirâmide, o nível das informações tratadas se tornam mais especificas. Neste lugar contamos com as informações gerenciais, ou seja, aglutinações de conteúdos. Todos os Spritesheets do jogo, mapas, textos. É nesse nível que o projeto é definido e concatenado, mas não produzido. Fica em destaque nesse lugar, o level design, o character design, e assim por diante. Estes são submetidos a posto de segundo em comando, e que em geral, são responsáveis por áreas especificas, mas ainda genéricas.

E no ultimo degrau dessa pirâmide, temos a equipe organizacional. Todos os Mappers, Spriters, Programadores, Roteiristas e afins. Esta grande parcela que é submetida aos Gerentes, é responsável pelo real desenvolvimento, o trabalho mais braçal. Desde construções de melodias até os sistemas inclusos, tudo isso é feito aqui, nessa equipe. É o nível mais especializado dentro do desenvolvimento do projeto.
Entendendo essa divisão, da pra perceber que os projetos de games amadores nem sempre adotam esse tipo de organização. Em geral, temos O manda chuva e seus asseclas. A galera do mal. Vou citar um exemplo aqui bem comum:

“RIARIARIARIAR! VOU CREAR UM JOGO USANDO O RPG MAIQUER VX! PUTS FERA COMOFAS PRA COLOCARS UNS CHARS LEGAL?’

- O Ser fala com outro coleguinha que anda com ele no recreio –
“ IAEKRA COMOSETA/ TIOP, TO FAZENDO UM JOGO LEGAL E PANS, ME AJUDA FAZENDO OS PERÇONAJEINS?”

-O ser aceita. Com o passar do tempo, a função que inicialmente era apenas fazer os Personagens acaba assumindo outra idéia:

“FERA COMO ISSO? EU PEDI UM PIRATA E VOSSE FEZ UM CAVALEIRO DAS TREVAS/”
“MAS VEJA, IA FICAR MUITO MAIS MELHOR DE ROX UM CAVALEIRO DAS TREVAS DO QUE UM PIRATA”

“PQPQP##%!$! ACABOU ESSE PROJETO AKI AGORA OK BLS FLW”

E mais um projeto morreu por? Falta de comunicação, defasagem em seguir uma hierarquia. Se desde o inicio ficasse claro o papel de cada um e a sua responsabilidade, o projeto seguiria em frente e não morreria por um assunto tão bobo.

No próximo post continuo falando de equipes e entro já na gerencia do projeto. Ta começando a ficar tenso, eu sei.
Até!

Na verdade o Tutorial do Mitmailou está bem incompleto.
Aquele guia, meio óbvio e simples, não chega a surpreender, mas está longe de ser um guia mal feito.

Olha, com base no estudo que eu tenho, eu acho que essa divisão é errada. Ao meu ver a divisão deveria ser mais detalhada e mais generica. Na série de posts do meu blog e no portal da vila, eu to tratando o post justamente sobre equipe do projeto e de como ela é dividida. Veja o esquema:



Sobre as descrições, enfim, testes só se faz depois de o software pronto. Não tem como testar durante o processo.

No mais, bem simplista, mas valido.

bom tuto kahh, mas, seu post deu uma complementada que tal voce fazer um tuto acho que ficaria melhor não que esse não seja bom mas acho que a sua percepção de "O que é uma EQUIPE?" é melhor e mais favorável a nós makers. se eu estiver querendo muinto min perdoe(^_^) sei que esta muinto ocupada com ERGO xD