View
109
Download
0
Category
Preview:
Citation preview
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.
Recommended