Prototipagem rápida de gameplay

Cláudio H P Lins – claudio@preloud.comProdutor líderSócio fundador da Preloud Entretenimento Eletrônico Brasil

A Preloud

Existe desde 2002 como projeto pré-incubado e incubado, em 2003 como empresa formalizada.

Esta no porto digital, tem atualmente 8 jogos in box para PC no mercado exterior em mais de 6 paises.

Atualmente conta com 14 membros e esta trabalhando com parceiros no exterior e no Brasil.

Funcionamento padrão de desenvolvimento:ConceitoProposta de projetoProposta de custos/ orçamento Cronograma de milestones/ versõesDesenvolvimento/ Produção clássico/tradicional

(os 5 primeiros jogos seguiram esse padrão)

- Áreas de desenvolvimento isoladasCódigoArteGestãoProduçãoGame design...

- Documentações pré-estabelecidas- Cronogramas fechados no inicio do projeto- Listas e mais listas – “to do list”

FuncionalidadesTexturas...

Principais Problemas encontrados no desenvolvimento clássico.

Provar o que foi feito no milestone a olhos leigos- Muitas vezes uma área anda mais rápido do que outra, dificultando mostrar certos “features”

Atraso de pontos específicos-Quando uma área atrasa as outras sofrem não concluindo assim as metas esperadas.

Mostrar visualmente o que foi feito-Quando não há uma interação entre as áreas é bastante comum ter divergências de pensamentos.

Áreas isoladas trazem problemas de comunicação-Sempre que um erro for encontrado, em qualquer área que seja, será resolvido apenas por ela mesma.

Documentação fixa- Documentação pré-estabelecida de arte, gd ou código.- Documentações fixas independentes.- Game design fixo – seguir cegamente.

Cronograma feito no inicio do projeto- Quando o projeto já esta definido e amarrado com suas “listas” prontas fica complicado conseguir segui-lo de algo der errado.

Dificuldade de inclusão de novos features no projeto- Como todo o cronograma foi estabelecido no inicio do projeto fica difícil a re-locação de recursos na metade do projeto.

Dificuldade de manter o interesse da equipe- Quando as partes trabalham separadas e um dia vão juntar código e arte e virar jogo, é difícil manter o animo de todas as partes se ainda não tem nada “rodando”.

Dificuldade de manter a unidade inicial do projeto e qualidade- Quando se começam as listas torna-se um

trabalho manual, mecânico, e deixa de ser encarado como “arte” – logo vira uma “linha de montagem em partes que um dia será alguma coisa”. (colcha de retalho)

Resultados mais tardios- Demorava bastante para se apresentar as

funcionalidades do projeto funcionando em 100%.

Maior facilidade de erros- Como todas as “peças” foram trabalhadas diferentes não da para garantir que todas irão “encaixar” perfeitamente como mágica.

A experiência

4 demos em 4 semanasJogos que nunca tivéssemos trabalhados antes – tudo do zeroEquipe pequena sempre presente (8 horas por dia 7 dias por semana)Desenvolvimento em seqüência lógica e necessária – “made in na hora”

Desenvolvimento em seqüência lógica e necessária – “made in na hora”

Especificação dos demosDestrinchar exatamente quais as características usadas no processo (60% planejamento 40% desenvolvimento)

Planejar o que vai ser usado na cenaFazer os conceitos que serão usados na cenaProgramar o que será feito na cenaFazer as animações que vai terá na cenaFazer o “design concept” da cena

Inicialmente é necessário ter um “game concept” básico do projeto.

“Modelar” a cena

Destrinchar um cronograma simples com “macro blocos” de “features” específicos.

EX: se uma cena vai ter um soldado atirando será necessário:

O soldadoARTE

O conceito do soldadoO modelo 3DA textura do modelo 3DA animação de atirarOs efeitos especiais da bala para que ele atire

CODIGOColocar o soldado na telaA funcionalidade do soldado atirar

ProduçãoCronograma para saber o tempo que esse “macro bloco” vai ser feito.

Assim o “macro bloco” “soldado atirando” vai ser feito por toda equipe ao mesmo tempo e automaticamente testado e validado por toda a equipe.

Divisão de recursos exata para validar somente o que necessário- Uso da mão-de-obra necessária

Arte em conjunto com código – áreas conjuntas – não há divisão entre a equipe

- Tudo que foi feito em arte foi validado em tempo real. Incluindo modelos, texturas, cenário, animações e mais o que for necessário.- Tudo que é validado automaticamente é testado- Cada novo feature implementado é testado em tempo real junto com toda a equipe responsável pelo feature e logo corrigido se der algum problema. E é finalizado somente quando concuido.-Game design e documentação mutante e assistido por toda a equipe.

Toda a equipe sente o jogo crescer em tempo real.-A responsabilidade de uma tarefa deixa de ser de apenas uma pessoa e começa a ser de toda a equipe envolvida no “feature especifico”

Apresentação do feature, funcionalidade, mais rapidamente.- Como é baseado em macro blocos, cada macro bloco pode ser considerado sub metas que podem ser apresentados muito mais rapidamente.

Testes em tempo real a cada funcionalidade adicionada.

Maior facilidade em mudar o rumo do projeto-Caso alguma funcionalidade não seja como imaginado existe como contornar isso mais facilmente.

Maior facilidade em encontrar gargalos no Cronograma-Como a equipe esta próxima e se cobrado para concluir os macro blocos é mais fácil de detectar os gargalos.

Manter a unidade inicial e qualidade do projeto- Como esta sendo tudo validado em tempo real e toda a equipe esta acompanhando é mais fácil acompanhar a qualidade e adicionar alguma alteração ou ate mesmo nova tecnologia no projeto.

Maior facilidades para incluir novos features- Como tudo que esta no projeto esta “previamente” funcionando, é mais possível incluir novas funcionalidades em cima das já existentes.

www.preloud.comcontact@preloud.com